Unable to remove boot media

[Mikie]

My boot media (USB stick) has two partitions: FAT32 with the whole system and ext4 for the changes.
I am using the following cheat codes:
APPEND nocd noauto changes=EXIT:/dev/sdb2 copy2ram changes-ro
The FAT32 is sdb1, the ext4 is sdb2.
I want to remove the boot media. I am able to unmount the sdb1, but I am not able to unmount the sdb2, although the system should run fully from RAM and there are no changes to be written, since the session is read-only.

What am I doing wrong?

[Ed_P]

The system has no way of knowing when you will reboot and will use your changes=EXIT:/dev/sdb2 drive, thus the drive has to be available for when or if you reboot.

If you save changes to a save.dat file, on your sdb1 drive your sdb2 drive will be removable.

I want to remove the boot media.

For that to happen save your changes to a module. Or if using a save.dat file copy the save.dat file and rename it save.dat.xzm and use that file as a module. And drop the changes=EXIT: option.

[Mikie]

1)

The system has no way of knowing when you will reboot

Exactly. I know when I will reboot and therefore I know when the sdb2 has to be mounted.
I am more than happy to remount sdb2 before reboot.
But this is relevant only in the case that there are changes to be written.
However:

2) When I boot with 'changes-ro' there will be no changes written to sdb2 at all and the system knows that.
So I don't understand why sdb2 has to be mounted.

EDIT:
Apparently there are other people having similar problems:
No capability to remove boot media with a savefile

So is there anybody who understands reasonably in-depth the workings of "changes="?

[Ed_P]

So is there anybody who understands reasonably in-depth the workings of "changes="?

Yes, Cheatcodes and removing USB, and there are people who know how to work around it and have given you ways to do it. Simply have 2 boot options, one with changes, one without.

I actually have 4 boot options, one with changes=, one without and with my changes module, one without and without my changes but with modules I am testing, and one without changes or any modules in always fresh mode.

[Mikie]

there are people who know how to work around it and have given you ways to do it.

Well, I understand that there are workarounds and I thank you for pointing me to these.
But I would like to understand WHY 'changes=' does not behave as I (and apparently at least some other people) expect.
Maybe it will turn out that something is not as it should be, be it the implementation and/or the documentation, and by fixing it we could make Porteus better.

[beny]

hello, fstab in porteus regenerates every time you boot, if you change the usb slot the name of the usb stick also changes, you can try to use UUID for your stick for sure even if you change the slot the device code doesn't change but I could be wrong , you can test it with fdisk -l in konsole

[Ed_P]

I would like to understand WHY 'changes=' does not behave as I (and apparently at least some other people) expect.

I think it's a question of why do people use changes= with changes-ro. rather than simply not using changes= in a read only mode.

[beny]

hi Ed_P if you use changes-ro you can't write but maybe are loaded so the device is busy,so you can't umount it...
copy2ram and always fresh mode are different the first load all the modules,the second only the base directory.

[Ed_P]

Ed_P if you use changes-ro you can't write

And if you use the changes=EXIT cheatcode beny you can when you shutdown to reboot (or go to bed ). So basically the cheatcode edit needs to abort booting when the cheatcodes are conflicting. Should be easy enough to do.

[beny]

maybe or maybe not:if you don't use this, all the changes in EXIT mode are lost
While you are running a session with changes=EXIT, you can use the
'dump-session' command (run as root from the command line) to move all
of your changes from RAM to your storage media. This will reduce the
risk of data loss and free up your RAM.

[Ed_P]

But when you're running in read-only mode there are no changes: no bookmarks, no browser cache files, no browser storage files, no crash reports, no thumbnails, large or small, no trash files, no messages, no syslog, etc. At least that is what some people believe.

[Rava]

But when you're running in read-only mode there are no changes: no bookmarks, no browser cache files, no browser storage files, no crash reports, no thumbnails, large or small, no trash files, no messages, no syslog, etc. At least that is what some people believe.

And to clear that up, some folks might misinterpret Ed_P's post

When you use a browser, there are new bookmarks, browser cache files, browser storage files. The old ones from saved session are not loaded, but new ones are created during the browser operations, and depending on how you setup your cheatcodes, are saved or not saved.
Same with the other examples, e.g. new thumbnails are created when your DE file browser is set up doing so (by default it is)

So basically the cheatcode edit needs to abort booting when the cheatcodes are conflicting.

It would be nice when we had one thread on here listing all threads about user issues because of conflicting cheatcodes. And explaining that handling conflicting cheatcodes is not that trivial and easy to determine how to be handled by the system.