Hello:

Yes.
I suppose that is as long as I do not reboot or enable presistence. (?)

Yes, that's the idea.

Generate a new live *.iso starting off from yes another (in this case Alien-OS) which has most of what I need and then modify it to incorporate what it does not.

Thanks.
I'll have to see about how that works later.
I still have to get persistence working.  =-/

Thanks for your input.
Best,

A.

Hello:

No ...
Not refracta errors at all.

I'm sorry, my command of the english language is rather lacking.  =-/

I am referring to my own *trial and error* process, where I need to/want to change things one way or another till I get it all working as I want.

I'd like to avoid having to make a snap-shot -> mount it -> change it -> make another snap-shot -> and so on ...

Am I making sense here?
Thanks for your input.

A.

Hello:

Same here.

It has to match exacly.
Seemed won't do. 

Just pulling your leg ...   =-D

In my limited experience, the first check you do is on the *.iso file you downloaded.

Then you do a check on ther file burned on the CD/DVD or USB.

I found a way to do this here:
https://askubuntu.com/questions/547332/ … -boot-disk

The third and final step is to boot the installaiton *.iso and run a check on the installation media itself with the tool available in the menu.
Although, as we have seen in this thread, it can sometimes give a false positive.

Cheers,

A.

Hello:

Maybe not the easy way out.
It probably slipped past them.

Now it has to get fixed, somehow.

Has it been the same with previous versions?

Indeed ...  8^* !

That with respect to the 2.0.0 *.isos.

But with respect to the 2.1 *.isos, if the 2.1_amd64 version is supposed to be the same (?) as the 2.1_i386 version, why are they different? (ie: produce different md5sums)
ie: I'm assuming that they are the *exact* same file because they are not arch specific, as fsmithred pointed out earlier.

This would imply (?) that whatever happened to the original source file was affected differently when going through the process of compiling the respective *.iso.
Am I making sense here?

The plot seems to thicken ... 

---
Edit:

This is the data I have wrt some ascii 2.0.0 isos I have in storage:

ascii_2.0.0_i386_netinst.iso

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
b6838c8e3c68b64b813cfab7ea0a200e  isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$

devuan_ascii_2.0.0_i386_minimal-live.iso

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
f03d6ecc57dad4524a0cab76b7afab41  isolinux.bin
groucho@devuan:~/virtual-drives/2/isolinux$

devuan_ascii_2.0.0_i386_dvd-1.iso

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
4709734ad535226a10bef3ece43ed9d4  isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$

devuan_ascii_2.0.0_i386_desktop-live.iso

groucho@devuan:~/virtual-drives/1/isolinux$ md5sum isolinux.bin
4709734ad535226a10bef3ece43ed9d4  isolinux.bin
groucho@devuan:~/virtual-drives/1/isolinux$

Note that devuan_ascii_2.0.0_i386_dvd-1.iso and devuan_ascii_2.0.0_i386_desktop-live.iso
seem to share the same isolinux.bin file.

---

Best,

A.

Hello:

I have seen this in the ascii 2.1 netinstall *.iso files only.
The ascii 2.0.0 netinstall *.iso files don't seem to have this problem.

ie: media verification using the tool available within the 2.0.0 netinstall media does not fail and the isolinux.bin file produces the correct md5sum.

Best,

A.

Hello:

Has anything else happened with this Derivative?

It looks really great (reminds me of my favourite # !) but to be a switchblade OS it needs to have a fully functional file manager (or at least MC installed) and some sort of auto network configuration or scripts to get things running.

Otherwise it's sort of crippled.

Any news?

Thanks in advance,

O.

Hello:

I'm running the last available Devuan 4.9.0.11-686-pae SMP Debian 4.9.189-3+deb9u1 (2089-09-20) i686 and the problem subsists.

Will this ever get fixed or will it end up as part of the 'won't fix' crud that ends up accumulating inside the code because it is not considered worth correcting?

A.

Hello:

No ...
That's not it.

What I need/want (and opine that any FM should have) is the function MS had/has in Windows Explorer: the Right Click -> Send To -> Any Folder action.

You can select either Copy or Move and then Browse, where you get another window to quickly find where you wanted the file to go.
You can then easily repeat the same action faster as the different destinations stay cached and show up in a drop down box.

Cheers,

A.

Hello:

Indeed, which is more or less what I want to do.

Just check out that it is nothing that looks out of the ordinary/expected, so to speak.
If it were, I'd then go on to check the usual files in /var/log to see what was going on.

Yes, you are quite right there.  =-)

But unless my rig's configuration has gone astray, I do not really expect unusual stuff.
What got me asking about this is that the process, which I expect is BackInTime or TimeShift related, is not getting shown in conky (don't know why).

It happened this morning about an hour past my boot-time and I ran iotop to see what was working.
In this particular case it was BackInTime cleaning up excess/older snapsots (actually it was rsync).

Thnaks a lot for your input.

Best,

A.

Hello:

Thanks, but I'm afraid it won't do.

What I need is to be able to look at my screen (eg: conky) and see something similar to what this does but for disc access/activity.
It gives me data on the top 5 processes and the % CPU time they take up.

Unfortunately, for some reason backintime and timeshift do not show up and maybe some other activity does not either. 
And I'd really like to know what is writing to my drives when more than usual activity is heard.

TOP 5 PROCESSES
${hr 2}
$processes processes ($running_processes running)
${alignr}${top_mem 1} %
${top_mem name 2}${alignr}${top mem 2} %
${top_mem name 3}${alignr}${top mem 3} %
${top_mem name 4}${alignr}${top mem 4} %
${top_mem name 5}${alignr}${top mem 5} %
${top_mem name 6}${alignr}${top mem 6} %

I don't need to check anything but who (process/programme) and where (disk drive/partition).
So if I hear unusual drive activity, this will give show me if it is something I want/need (eg: backintime/timeshift) or something else I should be aware of.

Most utilities I have found are benchmark oriented, designed to check if there are bottlenecks and such but I've not found anything security oriented (?) like my use would seem to be.

Maybe iotop might do but I cannot get it to run in conky nor have I found an example online.

Thanks for your input.

A.

Hello:

Thanks, it could be what I need.

It seems more like a disk performance monitor but the data I need could probably be obtained from the output ...

TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND 

... using data from just TID/PID, USER and COMMAND.

The best idea would be to pipe it to Conky so when I hear the drives I can just look at the display and see who is writing to disk.
I've looked around but have not been able to find an example of Conky using iotop and just a couple of posts from long ago asking.

Would you have one?

Thanks in advance,

A.