Cheat code to copy changes.dat to RAM

[bark-woof-fetch]

Sorry if I missed this one somewhere but I can't find a cheat code to copy changes.dat to RAM and the searches brings up just about every post about grub4dos ever.

Is this possible:

1. copy2ram and [cheat code to copy changes.dat to RAM]

2. post boot unmount media

3. end of session mount media again

4. sync changes.dat from RAM to media

5. or abort sync if the session became a sandbox instead

I'll promise to keep changes.dat at a reasonable size vs. total RAM capacity.
2 and 3 aren't necessary, just nice in some cases.

I believe I've done it in antiX/MX (but that might have produced 2 diff. persistent homes depending on persistence cheat code IIRC, quite messy)

Another persistence question: are changes.dat or .../live/changes/ always uncompressed?

antiX/MX compresses into a homefs file but maybe that's only done to preserve disk space at rest?

[SparkyBonsai]

Compressing critical changes in squashfs to load to ram on boot-up and save the new ones on exit doesn't work?

[bark-woof-fetch]

Compressing critical changes in squashfs to load to ram on boot-up and save the new ones on exit doesn't work?

Didn't think of that, so you convert the .dat to .sfs and boot as any other module?

And any changes are contained inside the sessions .dat or ../live/change/ folder?

I'll read up on AppImages to see if they are storing something writable inside them.

They can hardly be smaller in (uncompressed) use no matter how they're loaded right? Or does compression method also matter when loaded to RAM due to some clever temp tasking magic...?

[SparkyBonsai]

1. Make and save all your critical changes you want to restore in every boot (configurations, drivers, extra installed apps etc).
2. Use DebianDog's tool "Create Module from changes", save them in a file, i.e. "03-mychanges.squashfs" and copy it in /live/optional folder.
3. Check if your changes are loading as expected using cheatcode "load=03-mychanges.squashfs" without loading the changes file i.e. data.dat.
4. If yes, make permanent those changes by copying your 03-mychanges.squashfs in /live and clear changes from your dat file.
5. Boot with "copy2ram" so it will be loaded in ram. Put the cheatcode "changes=EXIT:/live/data.dat so any new change will be stored in ram until you terminate (with reboot or shutdown) your session.
That's it. Every change will be loaded in ram and stored in data.dat on termination.

Note: If your new file "03-mychanges.squashfs" will be loaded permanently, uncheck "Disable dpkg configuration" in "create modules from changes". Or apt will ignore any packet installed in it. If there is a dependency of a future-installed packet in it, apt will re-install it. Porteus construction is made for slackware, debian's apt system is more complicated.

[bark-woof-fetch]

as far as I understand https://docs.appimage.org/user-guide/portable-mode.html the next question is then which AppImageKit DebianDog uses and if it can create its own contained .home and .config

Using portable mode

This mode allows for bundling an application’s data next to the application’s AppImage.

Normally the application contained inside an AppImage will store its configuration files wherever it always stores them (most frequently somewhere inside $HOME). In other words, the fact that an application is contained inside an AppImage normally does not change where the application stores its data.

However, there is functionality in newer AppImages that can make the application’s data travel along with the application, if certain directories are present next to the AppImage file.

If you invoke an AppImage built with a recent version of AppImageKit and have one of these special directories in place, then the configuration files will be stored alongside the AppImage. This can be useful for portable use cases, e.g., carrying an AppImage on a USB stick, along with its data.

If there is a directory with the same name as the AppImage plus .home, then $HOME will automatically be set to it before executing the payload application

If there is a directory with the same name as the AppImage plus .config, then $XDG_CONFIG_HOME will automatically be set to it before executing the payload application

[SparkyBonsai]

I wouldn't trust appimages (yet), i think sfs are more stable. Anyway, it's your choice.

[bark-woof-fetch]

I wouldn't trust appimages (yet), i think sfs are more stable. Anyway, it's your choice.

The drill is about how to keep the /changes/ for each sfs separated. If both firefox.squashfs and thunderbird.squashfs are loaded f.ex. and write some changes during usage those /changes/ are now inside a third location where the session hosts them. AFAIK.

Then there are password and encryption details also, haven't figured that out yet either.

[dancytron]

You need to be aware of where the dpkg data is when you uncheck "Disable dpkg configuration" (or if you don't).

You'll have three layers.

the 01-filesystem layer will have the oldest dpkg data

the 03-changes layer will have the version on the date you made it

the /changes.dat or changes folder will ahve the latest version.

For it to work and not break, they always have to be loaded in that order.

[bark-woof-fetch]

1. Make and save all your critical changes you want to restore in every boot (configurations, drivers, extra installed apps etc).
2. Use DebianDog's tool "Create Module from changes", save them in a file, i.e. "03-mychanges.squashfs" and copy it in /live/optional folder.
3. Check if your changes are loading as expected using cheatcode "load=03-mychanges.squashfs" without loading the changes file i.e. data.dat.
4. If yes, make permanent those changes by copying your 03-mychanges.squashfs in /live and clear changes from your dat file.
5. Boot with "copy2ram" so it will be loaded in ram. Put the cheatcode "changes=EXIT:/live/data.dat so any new change will be stored in ram until you terminate (with reboot or shutdown) your session.
That's it. Every change will be loaded in ram and stored in data.dat on termination.

Note: If your new file "03-mychanges.squashfs" will be loaded permanently, uncheck "Disable dpkg configuration" in "create modules from changes". Or apt will ignore any packet installed in it. If there is a dependency of a future-installed packet in it, apt will re-install it. Porteus construction is made for slackware, debian's apt system is more complicated.

thanks a lot, somehow missed that reply yesterday while looking at AppImages.

I'll try it soon, Create Module from changes was the missing squash link. My Thunderbird profile is pretty large so that better get its own also.

Going ahead, to avoid having future changes from e.g. thunderbird.squashfs, ferdi.squashfs, firefox.squashfs merged together in the same .dat might involve some mid session saving (alt ctrl S in Dogs) and then saying no at EXIT:save prompt for whatever else happened during session afterwards. Could be messy. OTOH force better email and SoMe (ferdi) discipline.

[bark-woof-fetch]

Slight iteration:

Firefox and https://getferdi.com/ just need a one time sync sign in, afterwards they're pulling server data into a session. No offline usage hence no need to save cache inside the squash or in savefolder/ or .dat.

Thunderbird profile data remains tricky. Will try the AppImage suggested approach. Maybe a profile partition on its own with a launch script that prompts for password is better. If either could get along with https://portableapps.com/apps/internet/ ... d_portable it'll be golden. Atm. I'm not really using Thunderbird offline but that day could easily come and all of my accounts and RSS feeds are collected there.

There are probably tons of ideas from way back hidden in forum threads. TBC.