FirstRib initrd easy changes rollback

Rolling back to a previous boot session state

The following can be used with either a non-pseudo-full-install (i.e. a FirstRib typical normal frugal install) or with a FirstRib pseudo-full-install.

Because standard FirstRib initrd allows up to 100 layers in its overlay filesystem (by default, but easily increased to say 1000 by one NNN codeline modification) it becomes simplicity itself to implement rollback to a previous boot session state. Here is how:

Once you have updated and added whatever you wish to have installed at a certain date and time, you can then simply put a two digit number in front of the upper_changes savefolder name, which will make it load at that layer position read-only on next reboot.

Actually it is possible to do the same with savefiles (instead of savefolders) in FirstRib though you'd then need to make a new upper_changes savefile for future changes. You'd also need to convert the original .ucimg to either a normal directory or a squashed filesystem prior to making it a NNrollback. Can't use uncompressed directories on vfat or ntfs partitions of course, since symlinks and permissions only work properly on Linux format, so use sfs rollbacks on such partitions.

For example (with upper_changes savefolder), rename upper_changes to 50upper_changes

I just chose numeric 50 to allow plenty of room for future rollback upper_changes since they would come immediately after each other in the layering structure up to 99upper_changes, which is the top layer number allowed by default.

At this stage, if you wish to save space on your persistence media device you optionally can convert the 50upper_changes directory into a squashfs (known in FirstRib by extension sfs) via command:

mksquashfs 50upper_changes/ 50changes.sfs

Note in the above that only the double-digit numeric is important to FirstRib, the rest of the name can be anything you like, so even 50 as a directory name alone or 50.sfs would work.

That optional conversion is fine, if you want it, because FirstRib initrd has that innovative feature that it doesn't care whether addon layers are uncompressed directories, squashed filesystem (sfs) files, or a mixture of both. It is your choice…

Then on reboot a brand new empty upper_changes savefolder will be created automatically by FirstRib initrd (if using savefiles instead, you need to make an empty Linux-formatted one yourself for FirstRib to use as the top read-write save persistence layer, calling it <any_name.ucimg>).

Later, should you wish to make a new date/time rollback, just repeat the above steps, but using higher rollback double-digit (NN) filename. For example, 51upper_changes or, if you wish 51<any_name>, and again you can optionally make an sfs file out of that. The double-digit NN numbers don't need to be consecutive, as long as they get progressively higher as you make more rollbacks.

Of course you would be advised to normally avoid ever putting any other layer inbetween changes rollback layers since the merged result may mess up matters between rollbacks… though it is possible to do so with care. Not messing up package manager databases is the main issue you want to avoid; because of that importance to maintain package manager database consistency you should only ever remove top-most rollback layer (or simply disable it by making first two characters non-numeric; I myself usually disable simply by adding a ‘D’ to the front of the filename). Removing some in-between rollback NNfilesystem would almost certainly corrupt the package manager database, so be warned…

Note that FirstRib initrd does not itself provide any utility to merge such rollback NNfilesystems together - that's a user utility someone would write (actually one such was written in the past by rufwoof of PLDF). Merging the rollback files into one is basically a remaster, though, I think an actual live-whilst-running remaster utility, for a being used FirstRib-based system, has also been written by someone (fredx181 of PLDF?). I will not be covering such utilities here though, nor probably producing any myself since these are user-utilities and I concentrate on the build system components only, which doesn't mean I won't ever write versions of such myself.

My audience here, by the way - well, I don't know… but this blog was written and produced for my children.

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