Now that I have my KL base versions of distros released (being KLA-OT2base, KLA-XFCEbase, and KLU-jam-XFCEbase) I have time to play with them(!) and demonstrate some FirstRib initrd 'magic'.
I am currently booted into the new KLU-jam-XFCEbase.1.0 in a normal frugal install made inside directory called /KLU-jam-XFCEbase.
What I first want to demonstrate is how to make a firefox addon from a pristine frugal install that can be used without apt/dpkg database knowing anything about it (so won't be upgraded unless you purposively want that).
One of the powerful features of FirstRib-based boot is that you can use a mix of EITHER NN-numbered sfs addons and/or NN-numbered uncompressed directories as layers in the created overlay, so here is how to create a firefox addon (and optionally make it an sfs to save space). This mechanism should work for any KL FirstRib-based pristine frugal installation:
1. Boot the frugal install distro in save on demand (w_changes=RAM2 mode). As I say I'm using KLU-jam-XFCEbase as an example here.
2. Once into the desktop, connect to the Internet.
3. After an 'apt update' in terminal command window, install firefox browser using 'apt install firefox', or alternatively, if using KLU-jam-XFCEbase, simply run the install script: Main Menu -> Internet -> INSTALL_BROWSER, which will automatically do the apt update and the apt install.
4. Do a save2flash, which will save the installed firefox into save persistence folder upper_changes (along with your Internet connection information).
5. Now open filemanager (thunar) and go to directory /mnt/home and from there into the frugal install directory KLU-jam-XFCEbase where you should see that upper_changes directory.
6. Still in thunar filemanager, go into that upper_changes directory and completely remove the directory named 'var' that is inside it. The point of this is that removing var from upper_changes means that, on next boot, apt/dpk database will no longer 'know' you have a version of firefox installed... Effectively, we are creating a portable KL firefox (though some extra libs may need to be installed on other KL distros depending what is already in them).
7. Now go back out of upper_changes in thunar and rename that upper_changes directory to (for example) 14firefox, which will be used as a new addon layer next time you boot...
8. Reboot. Firefox should remain working even though apt/dpkg database doesn't know it is there (and your Internet connection will be automatically established too). So if you now do an 'apt update' followed by 'apt upgrade', the browser firefox won't be re-installed even if a new version exists. A few files might get held back because apt/dpkg notices old versions are somehow there, so you can just re-install these few components manually (on my system that included apparmor or something like that) and save2flash. Anything new installed will not go into 14firefox (which is fixed and stable) but instead into a brand new upper_changes folder (once save2flash has been done).
OPTIONAL:
9. Anytime you like, you can if you wish turn that uncompressed 14firefox directory into a highly compressed read-only sfs file via, for example, the command:
Code: Select all
mksquashfs 14firefox/ 14firefox.sfs -comp xz -b 524288 -Xdict-size 524288 -Xbcj x86 -noappend(best to do command: sync;sync at that stage just to make sure really finished writing to disk...)
and once 14firefox.sfs has finished being made you can then completely remove directory 14firefox...
One other thing: If you later on really do want to upgrade firefox to a newer version, you can simply open a terminal and use command:
Code: Select all
apt update && apt install firefoxAfter doing that the new firefox will of course be stored inside your main (uncompressed) upper_changes directory (once again saved there via save2flash). Then you can if you wish remove that old 14firefox.sfs
Making a utility (perhaps with a GUI yad or similar frontend) is just a matter of writing a similar script to do the above... I have no such plan at present personally though.
When I am doing such work, and remasters and so on, I actually often prefer just doing it at the commandline like the above since it is easy enough to do when you understand how the NN-based layering system works (and GUI frontends tend to hide the underlying way they work - in a sense that is their point afterall).
Perhaps there will be side-effects I haven't thought of, but worked for me in my experiment trying the above. Time will tell if any workarounds will be needed to perfect this howto...
HOW ABOUT WITH VENTOY?
Some of you may wonder if such addon NN-sfs or NN-uncompressed-dir addons could similarly be used with Ventoy. Well... yes... but you'd need to tell Ventoy grub at the commandline menu stage where to find the extra sfs files. Fortunatly the magic FR initrd has that capability built into it via a grub kernel argument not known thus far by most here: w_altNN
That w_altNN kernel line argument is used to tell the FR initrd to search also in alternative directories ANYWHERE on your system for additional numbered addons (sfs or uncompressed dirs). Actually I first did the above example in practice when I was actually using Ventoy to boot from the main KLU-jam-XFCEbase.1.0.iso. But... I needed to interrupt/edit the final grub menu RAM2 save on demand to 'Ventoy' Sessions stanza during boot to do that - by adding at the end of the grub kernel line the following:
Code: Select all
w_altNN=LABEL=Ventoy=/Sessions/KLU-jam-XFCEbase.1.0You don't need any such manual interruption to grub boot when using normal frugal install, but at least the method does work with Ventoy. Fortunately, I can make the same work without that Ventoy manual intervention being required for next iso release. That will simply be a matter of adding that line to the /boot/grub.cfg file inside the iso; I don't need to modify the main iso contents otherwise to achieve that (i.e. I simply need to tell Ventoy via that grub.cfg to also search in that w_altNN directory for possible addone (if none are there, that's fine...).
Hopefully above example helps enlighten users such that they can best use the significant flexibility of their KL distro in terms of addon layer support (which is especially easy in FirstRib-based boot design since just need to change the 2-digit NN value to say what layer you want your addon loaded - also you can disable any layer simply by renaming the addon such that its first character is non-numeric.
For example, I often disable an addon from being loaded into any layer at boot time by simply prepending a 'D' to the filename or 'NO' or whatever...
Note also that the likes of 07KLU-jam-XFCEbase.1.0.sfs can simply be renamed to 07.sfs and still work as normal; only the first two numeric digits of the addon name are important. Likewise you can move 07xxxxxx.sfs to another layer instead to make space for other addons if you wish (e.g. rename it 08.sfs or whatever...
Of course, you must be careful never to have any addon layer file or directory anywhere with the same layer number!!! FirstRib may seem clever but it does not employ Artificial Intelligence... (not yet anyway)!!