FirstRib initrd RAM modes

FirstRib wiak initrd provides three alternative w_changes RAM modes, as follows:

1. w_changes=RAM0

This mode doesn't use any existing external media upper_changes folder at all. Instead a temporary upper_changes folder is created in RAM at directory /mnt/layers/RAM/upper_changes. Any session changes will appear in there as you work, but all is lost on shutdown (since was just in RAM) though of course you can manually copy or rsync whatever was there out to a new external upper_changes folder for using again some other time, but below w_changes=RAM2 is a more powerful (uses previous sessions) variation of this.

2. w_changes=RAM1

This was just a variation on w_changes=RAM0 above. The only difference is that once the RAM /mnt/layers/RAM/upper_changes is created, any external upper_changes contents are copied into that on boot. Again, any new changes just appear in RAM (the external upper_changes not being used at all after boot), and these new session changes will be lost on shutdown. However, I use a simple rsync script to allow me to copy the whole lot back again to the external upper_changes folder - i.e. this provides persistence. The disadvantage of this mode is that copying in the external upper_changes contents uses up RAM unnecessarily, but in practice the method is actually nice, simple, and reliable if you keep your external upper_changes folder small in size. In fact I preferred this mode for months - but I have a technique when using it:

a. When I first install new system I tend to not put upper_changes in RAM at all but instead fill my external upper_changes directly with all the extra big application programs and any system configurations I want.

b. Then I make a ‘rollback’ upper_changes file by simply renaming the existing external upper_changes directory to something like 50upper_changes (you can leave that as an uncompressed changes rollback folder or use mksquashfs to produce 50upper_changes.sfs). The next time you boot the system that 50upper_changes simply becomes top read-only layer and a fresh empty upper_changes folder becomes the topmost read/write layer. I sometimes repeat that add to system followed by rollback files (e.g. 51upper_changes, 52upper_changes). Thereafter I have usually nothing else much to add so then I alter my grub kernel config to use w_changes=RAM1 mode and often do not bother rsyncing back thereafter (and keep external upper_changes of zero or very small size). I have a reasonably well tested rsync script for this that I'll publish later. You more likely want to use no w_changes RAM modes at all or will prefer w_changes=RAM2 mode below since it saves some RAM used:

3. w_changes=RAM2

However, the third w_changes mode (w_changes=RAM2) provides the more flexible optional save session mode many prefer. Again upper_changes is saved into RAM at /mnt/layers/RAM/upper_changes, but difference with this RAM2 mode is that any external upper_changes folder gets automatically mounted as the topmost read-only layer (so merged as part of the overall overlay merge result). Once again, any changes that occur during a boot session get lost on shutdown OR you run a save-back to the external upper_changes folder script to get full persistence. Note however that /mnt/layers/RAM/upper_changes for this mode only contains that single boots session changes so the save back to external upper_changes script actually needs to MERGE that /mnt/layers/RAM/upper_changes and not simply clobber the external upper_changes.

Complication with this RAM2 scenario is that you have to keep some overlayfs ‘whiteout’ (char device) marker files for layer deletions to be correctly recorded. In practice I actually currently use a probably very imperfect single-line merge-back command (in a script). PLDF's fredx181 told me he did something similar originally in his DD-bullseye OS, but felt there were potential problems of leaving unneeded whiteout markers, in which case my simple script would also need expanded to seek out unwanted whiteouts. Rockedge's KLV-Airedale has a modified version of Fred's save2flash/snapmerge utility in it.

Just to help you understand the save-back-changes process, you can find below the simple one-line rsync script I previously used to use (without any noticed issue). I suspect that is fine for small upper_changes use, but no doubt there are problems for more complex session-save situations and certainly for rollback scenarios. Better now to use the save2flash/snapmerge utility provided in the likes of KLV-Airedale I'd say:

rsync -av /mnt/layers/RAM/upper_changes/ \ /mnt/sda4/FirstRib_distro_foldername/upper_changes

Of course the above /mnt/sda4 example is for my own system. You'd have to change that to match the actual partition you have your savefolder on.

Note it is very important to put a / at the end of /mnt/layers/RAM/upper_changes/, and NOT put a slash at the end of /mnt/sda4/FirstRib_distro_foldername/upper_changes (i.e. the external media upper_changes folder), otherwise rsync makes a new upper_changes folder ‘inside’ the other one on external media upper_changes instead of merging as intended (try it and you will see what I mean…)

4. w_copy2ram

This is a separate and entirely optional RAM mode feature. Putting that argument on your boot loader (e.g. grub.conf) kernel linux line results in all boot files and folders to be first copied into RAM prior to being used during boot. I generally don't recommend its use because it wastes a significant amount of RAM storing these boot files and folders there during use.

If you ever want to see all FirstRib overlayfs layers, simply open your filemanager at /mnt/layers and you will conveniently see their contents…

Direct writes to external media upper_changes savefolder or savefile

Of course, you don't need to use any RAM mode at all. By default FirstRib init will auto-create an external upper_changes folder and auto-use that directly for persistence. Once you have the system built up the way you like it, then certainly you might want to consider using one of these RAM modes since you can then optionally choose not to save a session, and also limit the number of regular write cycles to flash media devices.

5. Also, there is some particularly important and useful related information in blog post: Firstrib booting via UUID and LABEL

Tiny Linux Blog: https://www.tinylinux.info/