FR frugal of my Linux Mint full install - weird but 'working'

[wiak]

So, I moved from Zorin lite to Linux Mint XFCE for our business Linux system. All good, including setting up tigervncserver/clients via ssh tunnels to each others machines.

I actually prefer full install for such purposes (and running as non-root desktop) since makes upgrading trivially easy. However I do miss save on demand functionality since I like to experiment and don't always want to save.

Previously I have simply temporarily moved the full install into its own directory and then used FR initrd capability to load that as the 07layer to create a frugal install with save on demand and easy/quick to get back to full install simply by moving that directory contents up one level (back to /).

However, since overlayfs has that big advantage over aufs of being able to 're-use' layers that were already used in other overlay stack, I decided to try a frugal install using FR initrd inside / (i.e. not bothering to move the full install Mint into a subdirectory). I've done much the same a few years ago when I showed how to use a sfs with a full installed distro via overlayfs layer with first layer being / (wiak Aug2019): https://oldforum.puppylinux.com/viewtopic.php?t=115915)

But... I did realise the potential problem that if this worked as a straight frugal boot then upper_changes and work would be written into /, and I indeed wondered how that would effect matters since they would not just be part of the first layer, but also used for the top read-write layer... Well, to try this, all I needed to do was put the initrd (modified to include Mint boot modules) into / along with copy of vmlinuz of Mint along with external w_init. Then all I needed to do was quick one line tweak-addition to that external w_init (i.e customised it to use that bootfromdir as lower overlay layer, and booted. It worked...

All I added to w_init was one line (EDITED to include colon at front so sfs addons work too):

Code: Select all

bottom=":${bootfromdir}" #wiak full install to frugal experiment

placed just before the main mount of the overlays. No other change was needed - all relevant mounting was already correctly handled by current FRinitrd anyway. So the directory being booted from instantly becomes the lowest layer of the overlay as a result, which happens to be the root directory of the full install of my Linux Mint in this arrangement. I'm not currently using any numbered sfs files or directories at all, though these should work per normal as overlay layers in this arrangement too (I'll try including 10gtkdialog___.sfs and will report back here - should work fine - CHECKED OK with above colon fix in bottom=...).

So at boot time I now have menu choice to either go into Linux Mint as its normal full install (how it was installed), or, via FR initrd as a frugal install. But... the weirdness is that thunar will not let me look at Filesystem / directory because of that upper_changes/work situation that results in 'too many symlinks' somehow as far as overlayfs is concerned. But whole thing works fine otherwise. Interesting test was:

In that frugal install mode, I used apt upgrade && apt install geany (geany not in Linux Mint by default). That worked fine. Then I rebooted into normal full install mode and geany was no longer seen on the system or in apt/dpkg databases at all; why? well because that was all in upper_changes of course... So rebooting back to frugal (which is simply a grub config menu entry and needs no moving of the Linux Mint full install at all), geany is back again and fine. But pity about the weird upper_changes symlinks situation, when in that particular frugal install arrangement, though I can actually still open thunar at any directory on the system other than /, /upper_changes, or /work. So for example, I can use thunar to view /mnt/home or whatever... Also I can still get to / in a terminal, but not into /upper_changes which is simply not directly readable (but being used fine).

I believe I know how to fix this to work completely though. I just need to use the FR initrd facility (grub options) of being able to store upper_changes and work on different partition - then all should be fine (except needs use of that extra partition... and fine as it is anyway if I ignore the /, /upper_dir, /work visibility restriction...). That will be perfect for my needs since when experimenting I'll just use an external usb stick with upper_changes on it... But even without RAM2 mode use I'm now able to experiment without polluting my actual full install so I can just delete upper_changes thereafter...

Later I will document this mechanism more completely (probably with simply script so just a matter of running that script to install the FR components); might well be useful to many others who do have some mainstream distro full installed but would like save on demand FRinit frugal install capability.

I'm actually not yet using RAM2 mode save-on-demand (I'd have to add the scripts to main system). So geany was being written directly to upper_changes, and of course I could rsync that upper_changes back to the full install once in an other distro or back booted into the full install probably.

EDIT: Interestingly enough, when in FR frugal Linux Mint boot, if I install pcmanfm, that can be used to go to / directory without issues. It doesn't allow me into /upper_changes but just writes a big ? over its icon since obviously not usable from there. I can however get into upper_changes via /mnt/... directory. Once again, pcmanfm proves to not be installed once I boot back into full install Linux Mint (again that since it is in the upper_changes directory, which is only loaded in frugal mode). All in all, this is perfectly usable as is it seems and very handy mechanism for not being destructive to the actual full install for the dev experiments I habitually do. Only end result of using frugal boot sometimes is all kept inside that upper_changes directory which full install doesn't use anyway - I'll also try out save2flash with that too in case I stay in frugal boot and also want save on demand to that upper_changes too. But more generally I can just delete that upper_changes anytime so as back to whatever the full install situation is.

I'm actually posting from that FRinitrd frugal install boot of my Linux Mint full install right now. I'll keep using it like that tonight to see if any issues, but I am confident it will work fine as is. Resource usage (RAM/CPU) remains good as usual.

[wiak]

So with normal Linux Mint full install (and using its grub2 to boot everything on my nvme SSD drive) and FR initrd/w_init arrangement, can also boot the distro as a frugal install (boot time choice of full install or as frugal install).

I'm included 10gtkdialog sfs from KLV-Airedale at / of the Linux Mint full install partition and that gets loaded per usual when booting with FR initrd so gives me gtkdialog and filemnt for example even though I'm using Linux Mint.

The w_init code has that one "bottom=" addition per below (which gives lower layer of the overlayfs being the Linux Mint full install filesystem):

Code: Select all

bottom=":${bootfromdir}" #wiak full install to frugal experiment
mount -t overlay -o lowerdir=${uc_ro}${middle}${lower}${modules00}${bottom},"${upper_work}" overlay_result merged

The mount -t overlay line remains unaltered (I already had provision for ${bottom} in the usual skeleton initrd, but I include the Linux Mint /usr/modules in the FRinitrd of course so it can boot frugal.

I used wd_grubconfig to get the grub menu entry per usual (though had to remove some extra // symbols since wasn't designed for this full install scenario). Fixed result as below (that UUID is of my system's nvme partition 9, which I have the Linux Mint full install on):

Code: Select all

menuentry "/" {
  insmod ext2
  search --no-floppy --fs-uuid --set 3b0c0247-f820-4a21-a726-094d10bdd7e1
  linux /vmlinuz w_bootfrom=UUID=3b0c0247-f820-4a21-a726-094d10bdd7e1=/
  initrd /initrd.gz
}

And once booted, I find gtkdialog in /usr/local/bin as expected from the 10gtkdialog sfs addon:

Code: Select all

mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ gtkdialog --version
gtkdialog version 0.8.4 release (C) 2003-2007 Laszlo Pere, 2011-2012 Thunor
Built with support for: GTK+ 3, VTE.
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$ which gtkdialog
/usr/local/bin/gtkdialog
mcewanw@mcewanw-HP-ProBook-430-G8-Notebook-PC:~$

So plan is (sometime after March 2024) to include similar into firstribit (was weedogit) build utility choices along with save2flash RAM2 scripts. Result of that is very different from original weedogit since also for normal full install running as FRinitrd frugal. Previous weedogit simply used the sfs root filesystem of the upstream distros whereas up above I am using already uncompressed/full-installed Linux Mint and then running that as frugal install with FRinitrd (if you see what I mean...). Will arrange for both methods (maybe two firstribit script types). Above description/info should be enough for others to try this already though assuming they understand FRinitrd operation well enough. i.e. if you already have a full install of something like Linux Mint, above is how to (optionally) run it instead as a frugal install with all the usual advantages that brings.

EDIT: Further tests convince me I won't be able to use RAM2 save on demand as well with this particular frugal arrangement. Since system can't access the physical upper_changes once its containing Linux Mind root filesystem is mounted as part of the overlay, upper_changes can't then be remounted for RAM2 save on demand use - something to do with overlayfs and sees it all as too many symlinks... Nevertheless the current arrangement is best for my own quick experimental needs. Moreover, I expect I can also use RAM2 save on demand mode if I first re-organise upper_changes and work directories to be written to a different partition (e.g. a plugged in usb) - I will try that later. Meanwhile the current frugal arrangement is simple and nice for testing new ideas before simply deleting the upper_changes folder to revert matters to what they were... the main use for me really.

[wiak]

So yes, arranging for upper_changes to be stored in different partition fixes all issues (though previous arrangement remains useful too since doesn't need separate partition). To move upper_changes to different partition just required me changing the grub2 linux (kernel) line:

from:

linux /vmlinuz w_bootfrom=UUID=3b0c0247-f820-4a21-a726-094d10bdd7e1=/

to:

linux /vmlinuz w_bootfrom=UUID=3b0c0247-f820-4a21-a726-094d10bdd7e1=/ w_changes=UUID=424d8f42-e835-4111-9053-dd086b3d38e8=/sessions

and now the upper_changes folder is being written into that folder I named 'sessions' on that different (UUID) partition on my system. Didn't need to call it sessions - any name would do.

And now, if I want RAM2 save on demand arrangement I just need to change that grub2 entry to:

linux /vmlinuz w_bootfrom=UUID=3b0c0247-f820-4a21-a726-094d10bdd7e1=/ w_changes=UUID=424d8f42-e835-4111-9053-dd086b3d38e8=/sessions w_changes1=RAM2

All working fine and Linux Mint full install itself is unaffected - just an extra grub2 menu choice to allow me to use it as a frugal install via the FR initrd...

There is one restriction: won't work if you are using encrypted partitions; I haven't added support for that into the FR initrd. Maybe one day.

[geo_c]

Wow, this seems fairly amazing to me. In a nutshell, from a quick skim of your lengthy posts, it seems that you have a frugal install without any read-only layers, that doubles as a full install. The upper changes can be stored on a different partition, and if I understand correctly changes are not affecting the read/write full install when booted frugally. So you can effectively experiment in a frugal boot, if you like the changes, boot back into full and duplicate it.

Or is it simply a matter at that point of merging the frugal upper_changes into the full install?

[rockedge]

Or is it simply a matter at that point of merging the frugal upper_changes into the full install?

I think using rsync it is possible to merge the upper_changes into the full install.........

I'm actually not yet using RAM2 mode save-on-demand (I'd have to add the scripts to main system). So geany was being written directly to upper_changes, and of course I could rsync that upper_changes back to the full install once in an other distro or back booted into the full install probably.

[wiak]

Wow, this seems fairly amazing to me. In a nutshell, from a quick skim of your lengthy posts, it seems that you have a frugal install without any read-only layers, that doubles as a full install. The upper changes can be stored on a different partition, and if I understand correctly changes are not affecting the read/write full install when booted frugally. So you can effectively experiment in a frugal boot, if you like the changes, boot back into full and duplicate it.

Or is it simply a matter at that point of merging the frugal upper_changes into the full install?

Yes, was long post... because I was writing about how to do it whilst actually still in the middle of the experiment!

Indeed, the upper_changes are best stored on different partition to the boot-from partition (though RAM0 mode can be used instead since that puts upper_changes into RAM only when save on demand is not required).
And yes, doesn't affect the read/write full install so that you have the choice to use that as normal or to use this FRinitrd-based frugal install of same when you want to experiment (and use RAM0 or RAM2 save on demand mode and so on) such that you can take back roll back changes you made.
When running in frugal mode the full install filesystem should generally be treated as a read-only layer per kernel-team-documented overlayfs restrictions though. Whether you also include numbered addon layers (such as 10gtkdialog I used) is entirely optional (but useful as always) - the bottom full filesystem layer isn't numbered.
So yes, with this arrangement "you can effectively experiment in a frugal boot, if you like the changes, boot back into full and duplicate it" or, as rockedge suggests, it would be possible to write a routine that could rsync back to the full-install hierarchy from upper_changes such that they are there next time you boot into full install mode.

By the way, I can likely improve the arrangement by better organisation of the FR-related files: I should be able to put them all into their own subfolder along with the likes of addon sfs files when wanted (such as that 10gtkdialog sfs). Will need a slight 'tweak' to the w_init then since bottom layer would no longer be "bootfromdir" but rather "/mnt/bootpartition" of where the full install is.

The reason I did this is because I already had that full install of Linux Mint (which as I said also provided grub2 for dual install of Windows and everything else on my system), so I use that a lot but wanted FR frugal capability when using it as an option. It becomes possible to now write a single utility that will do all this configuration automatically (even could include a user-friendly gtkdialog frontend). So scenario would be: user has a full install of say Linux Mint (though could be other mainstream distro) - little utility could then be run to add a FR folder that provides this optional frugal install of that mainstream distro. To make it even easier to achieve (though pretty easy right now anyway) I will modify future skeleton FRinitrd to accept grub2 kernel-line option for that lowest "bottom" layer - that's a tiny mod.

[geo_c]

So scenario would be: user has a full install of say Linux Mint (though could be other mainstream distro) - little utility could then be run to add a FR folder that provides this optional frugal install of that mainstream distro. To make it even easier to achieve (though pretty easy right now anyway) I will modify future skeleton FRinitrd to accept grub2 kernel-line option for that lowest "bottom" layer - that's a tiny mod.

Seems to me upon thinking about it a little, that you would need to merge the frugal upper_changes into the full install before changing or updating the full install and running frugal again with those same upper_changes. Otherwise the updates would be written over by older files in the frugal upper_changes and possibly break things.

[wiak]

Seems to me upon thinking about it a little, that you would need to merge the frugal upper_changes into the full install before changing or updating the full install and running frugal again with those same upper_changes. Otherwise the updates would be written over by older files in the frugal upper_changes and possibly break things.

Yes, you are perfectly correct about that; user has to be careful to keep package manager database foremost in mind so as not to merge when doing so would break that. We can't control e.g. apt/dpkg needs but there are usage patterns that will merge changes fine.

Problem case is where user uses frugal, keeps upper_changes, but doesn't merge back into full install hierarchy, and then reboots into normal full install and installs something new with package manager. Result is that the previous upper_changes package database will no longer be compatible for merging.

So scheme works fine if:
1. Always deleting upper_changes after use, or
2. Always merging back new frugal session, or
3. Making sure NEVER to merge back old upper_changes (or any numbered rollback files) after using package manager whilst in full install mode.

So, yes, scheme is very useful but requires user to take care per above use restrictions. Great for single session experiment work when optionally wanting to either delete or merge back immediately.

[wiak]

Deleting previous FRfrugal subdirectory arrangement post since after further work I can't get it to work again... I'll repost once I find what is going on... However I'm using too much time so will may be a while till I get back to this. Earlier posts in this thread definitely worked though... c'est la vie

I suspect the new line: bottom=":/mnt/${bootpartition}" isn't correct afterall (and I had made a mistake in most recent test with the grub2.conf. I have to check that bootpartition variable to see if it is valid (I was just working from memory when I used it). Oh well, will get there eventually.

[wiak]

To cut a becoming longer story short, it is all working now with the key FirstRib components in own /FRfrugal subfolder of the full installed Linux Mint root filesystem.

Somehow or other (my brain is frazzled today) I had accidentally deleted the bottom=":/mnt/${bootpartition}" line, which turns out to be the correct code afterall...
I also had the grub2 RAM2 save on demand stanza wrong, now it is correctly:

Code: Select all

menuentry "FRfrugal" {
  insmod ext2
  search --no-floppy --fs-uuid --set 3b0c0247-f820-4a21-a726-094d10bdd7e1
  linux /FRfrugal/vmlinuz w_bootfrom=UUID=3b0c0247-f820-4a21-a726-094d10bdd7e1=/FRfrugal w_changes=UUID=424d8f42-e835-4111-9053-dd086b3d38e8=/sessions w_changes1=RAM2
  initrd /FRfrugal/initrd.gz
}

I also put save2flash and snapmergepuppy into /usr/bin and snap-ex into /usr/local/bin (personally I'd prefer them all in /usr/local/bin but sticking to KLV arrangement to keep scripts the same as there). Created a few test files whilst in that RAM2 mode and did a save2flash and all saved back into the /sessions/upper_changes folder on that other partition and all was still there on reboot. i.e. save on demand (RAM2 mode) working fine with this arrangement with underlying full install of Linux Mint. Quite wonderful really. I do think I could make it save2flash (maybe) to an upper_changes on same partition as the Linux Mint installation but I don't trust that so much and don't need it. I'll leave things as they are since works perfectly without any mod to the w_init , via some additional w_init mods apart from that single additional code line: bottom=":/mnt/${bootpartition}" immediately before the existing code line:
mount -t overlay -o lowerdir=${uc_ro}${middle}${lower}${modules00}${bottom},"${upper_work}" overlay_result merged
which doesn't need altered at all.

Below images shows the RAM2 mode /mnt/layers/RAM/upper_changes, the contents of which get merged back into that /mnt/layers/uc_ro, which is the mounted persistent media upper_changes folder, by save2flash routines (in this save on demand RAM2 mode, external media upper_changes is, actually mounted read/write to that uc_ro mount directory - the somewhat confusing uc_ro name is from another RAM mode use).

[wiak]

Posting from Linux Mint booted via FRinitrd in RAM0 no persistence mode.

I also have grub2 menu option for same with RAM2 save on demand mode, but I find in practice that I probably prefer RAM0 most of the time which leaves underlying Linux Mint untouched. Means that anytime I actually want to install something or re-configure something (other than what I experiment with in RAM0 mode) I can simply boot the Linux Mint in its full install mode, specially when wanting apt update, and avoid any apt/dpkg issues. RAM2 save on demand mode certainly works though so I could choose to always run Linux Mint as a frugal install with save on demand persistence.

The 'mount' command shows the following as the overlayfs arrangement I'm currently using:

overlay_result on /mnt/layers/merged type overlay (rw,relatime,lowerdir=12:/mnt/nvme0n1p9,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work,xino=off)

The lowerdir=12:/mnt/nvme0n1p9 indicates two lower layers.
The lowest is /mnt/nvme0n1p9, which is the partition on my internal SSD drive where I have a normal full install of current Linux Mint XFCE.
The 12 is an sfs addon I'm using (its full name is 12KL_gtkdialogGTL3filemnt64). That sfs contains most of what is in the 10gtkdialog sfs addon from KLV-Airedale (including filemnt), but 12 also contains wex and precord and a few other forum-related bits and pieces I wanted available to me whilst running Linux Mint in FR frugal mode.

Whilst I have no time for development work at this time still, the above came about because I needed Linux Mint installation for our family business sooner rather than later so I took the opportunity to make it a more robust install (from my experimenter point of view) by including FR frugal capability. Since I'm probably going to put same KL_full2fr frugal capability on another couple of computers, to actually save me some further time now I decided to work on a scripted version of the installation, which I'll release ready-to-go once I'm happy with it. This will likely be a single script the user simply needs to put in a separate empty folder on the / directory of their full installed Linux Mint and then run the script to download/configure the FR frugal components (all in that same directory so doesn't touch underlying Linux Mint at all).

Once that 'install done', like in weedogit the install utility outputs a correct grub2 stanza for adding to the underlying Linux Mint grub2 (or any other) via the likes of its /etc/grub.d/40_custom file (followed by running update-grub on that full install of Linux Mint). Will be simple as pie to do in other words.

I almost have it ready. I'm just fine tuning where and how I store the component parts prior to putting the relevant wget lines into the installation script. Taking a little bit of precious time over that to make my own maintenance life of this easier in the future. I must say, I'm really enjoying using the result since I feel no longer in danger of wrecking my important business full install of Linux Mint any more since using either RAM0 or RAM2 modes and generally leaving Linux Mint full install on /mnt/nvme0n1p9 alone. That's actually a great time-saver; the countless hours (many solid days of work) I lost on previous Zorin lite XFCE full install for family business because of me not being able to resist doing KL/FirstRib dev work on that, and inevitably eventually breaking the whole install... at least now I can break things in a non-persistent or easily fixed save on demand persistence way.

[rockedge]

not being able to resist doing KL/FirstRib dev work on that, and inevitably eventually breaking the whole install... at least now I can break things in a non-persistent or easily fixed save on demand persistence way.

Really cool stuff. Makes having the full install like having two versions of the same base OS. Of course in the best Kennel Linux tradition, we'll be borrowing some technology to stick into one.....like I think we need wex and precord in KLV-Spectr and I am also toying with the idea to shift the installations of those programs (wex and precord + others) to an expanded 10gtkdialogGTK3_filemnt64.sfs to more of one like 12KL_gtkdialogGTL3filemnt64.sfs and some other rearrangement of the utilities to provide more of a modular approach. But KLV works well so that is a lower priority project.

[wiak]

I have something for you to try (usual disclaimers - this is really alpha/beta, but may be fine...).

It is the w_init that will (once tested and debugged where necessary) be in FR skeleton initrd version 8.0.0 rcX. In practice, that means if you backup your current external w_init and replace it with the one attached (and renamed simply to w_init) then your system should continue to work as normal (well... in theory and with some luck - all going well...). Hmmm... in other words I don't guarantee anything so best to work on a KL-frugal-installed distro backup unless you are reckless like me...

This attached w_init contains only a little bit extra code, but quite a fundamental development in that alteration. The reason I worked on this 'so soon' is because of this full2frugal scheme I'm using with my Linux Mint full install - however the new facility described below is also for normal KL distros.

In my previous full2frugal working simple hack, I thought about the fact that since Linux Mint full install was the lowest layer I had the limitation that I couldn't put any addon underneath that layer even if I wanted to (well could do maybe but only as a very ugly hack). Not a major issue since we generally put the likes of 10gtkdialog (or 12KL_gtkdialog in my full2frugal set up) anyway and that works fine. But I feel that there is an advantage to sometimes putting an addon in lower layer than main root filesystem since then an older library in the addon can be overwritten layer-wise by the main rootfilesystem (I was particularly wanting giblib1 in my 12 sfs addon since wex needs it, but wanted to use official version in Linux Mint when and if that was installed). Yes I know if main root filesystem is at say layer 07 then you can put addons in lower numeric layers, but I'm talking here about not being easy to put addon at lower than current layer 00, which is mainly useful for full2frugal case admittedly... but will also work in normal KL distro frugal set ups I hope... per the below:

Long story short again: I have created a whole new numeric underneath layer directory... If it exists, it will provide the 2-digit numbered layers (compressed or sfs) UNDERNEATH 00modules and so on. Again in numeric order with highest number nearest to say 00modules and so on.

So that new facility should also be able to be used with normal KL frugal install distros such as KLV, which is why I'd be happy for some testing since I have only had time to test a few modes so may well be bugs I don't know about yet.

Usage: In your main frugal bootfrom dir, put in the new (attached w_init) and to test the 'under-layers' make a directory named '_' (i.e. the name is simply the underscore character). Then, for example, if you say move 10gtkdialog____.sfs from the bootfrom dir and put it in _ directory instead it should still work but end up in lower layer than 00modules. SImilarly you can put a whole host of addons into _ (as well as a whole host into normal bootfrom dir). It doesn't matter if the 2-digit numbers are the same - the under-layers directory can also hold any addons numbered from 01 up to 99 (though Linux system no doubt won't allow 199 layers, being 99 possible above-layers and now also 99 possible underneath layers, but that's not a big deal, the numbers are certainly available).

Summary, this new w_init (leading to new FR initrd soon) is for normal frugal install KL distros as well as for my special full install Linux Mint scenario.

With full install scenario there is a restriction. Since Linux Mint full install is being mounted uncompressed, you cannot also use uncompressed addons stored inside that Linux Mint hierarchy as addon layers... (similar to, as I said previously, you cannot have upper_changes inside that same full install Linux Mint hierarchy). However, you can have sfs addons inside Linux Mint and also use them as addons both above 00modules and underneath stored in dir _.

But as I say, this w_init and the under-layers directory named with the underscore (_) character should also work with normal KL type frugal installed distros, and there are no restrictions for that (you can use compressed or uncompressed addons per the usual KL functionality). This is NEW, so no guarantees it will even boot without kernel freakout, but working for me.

So if it works you can simply move addons above or below main root filesystem with ease simply by dragging/dropping in or out of dir '_' (from other booted distro or RAM0 mode) prior to rebooting.

NOTE that there are no drawbacks to this new facility. Doesn't slow down the system or complicate or otherwise change its usage in any way or use more resources. It's actually a 'fix' for a nice algorithm I had devised but wasn't using in a general purpose enough way - fixed that and now this new possibility results from that fix (still not perfect but closer). Avoiding restrictions on numbered ranges and compressed or squashed addon types is the FirstRib secret for providing increased functionality - so this fix just makes the FR initrd even more general purpose in the way it operates on layers (and particularly useful for my full2frugal install special situation).

It's actually just an expansion of the existing _addlayers algorithm to include the 'bottom' (directory _) subdirectory-included addons. If you are interested in coding the way _addlayers worked was described here: viewtopic.php?p=21859#p21859
Prior to this new addition, I had added 'bottom' to the overlay (in previous initrd) but had just roughly hacked some details to make things work (per usual KL system setups) rather than correctly integrating these matters into the _addlayers function: that's what I've addressed now.

[rockedge]

Hmmm... in other words I don't guarantee anything so best to work on a KL-frugal-installed distro backup unless you are reckless like me...

True words of wisdom. I am that reckless when it looks like it's going to work...........but I just recommended to @geo_c not to try the huge type full real time kernel quite yet on a solid working installation of KLV-Airedale but on a new, fresh experimental install and copy the XXupper_changes to it.

Symlinks might work with the /XXupper_changes.......

[rockedge]

@wiak I have the wd_init-800rc installed and the system is using it. I took a brand new KLV-Airedale-sr2 and named it KLV-Airedale-sr2X. It is the standard distro with the exception that this change. I amde and ISO out of it and also have it running in a QEMU VM.

So far I am experiencing odd network drop outs and certs issues (it seems) in the QEMU VM instance. Needs more testing!

[wiak]

@wiak I have the wd_init-800rc installed and the system is using it. I took a brand new KLV-Airedale-sr2 and named it KLV-Airedale-sr2X. It is the standard distro with the exception that this change. I amde and ISO out of it and also have it running in a QEMU VM.

So far I am experiencing odd network drop outs and certs issues (it seems) in the QEMU VM instance. Needs more testing!

Yes, w_init-800rc1 currently alpha or beta so best to only try on pristine KL install that user is willing to risk, like in all experiment testing. It shouldn't have anything to with networking/certs though - all it does really is just calls FR _addlayer routine again to add new directory of numbered addons so just incorporating some new layers in the overlay. Only issue that might occur would be some RAM modes perhaps not working if I forgot to modify certain variables here or there. I've only concentrated with RAM0 no persistence mode in first tests, but hopefully no issue will be discovered in other modes. In practice I'm arranging that most of the new code isn't used at all unless that directory _ is present so shouldn't effect overall distro operation one way or the other be that in VM or not.

Still working on the single script KL_full2frugal script that will allow user to convert their existing full install of Linux Mint to a KL-frugal (as a grub menu option). Not much left to do there but need to find time to finish it off, which I will do. It certainly works fine and will use the new w_init-800rc1 with it both as further tests and because that is potentially more useful there. I won't be releasing new FR initrd more generally right now though since current one works fine and is known to be stable.

[rockedge]

I found the issue was an expired cert for the https: so I had a new fresh one issued. Problem fixed and KLV sr2X is working well!

running with experimental initrd.gz:

Screenshot(1).jpg (33.2 KiB) Viewed 1305 times

[wiak]

I found the issue was an expired cert for the https: so I had a new fresh one issued. Problem fixed and KLV sr2X is working well!

running with experimental initrd.gz:
Screenshot(1).jpg

I'd be obliged if you could mkdir '_' in the frugal bootfrom directory and see if moving 10gtkdialog sfs into there followed by a reboot works. The result should be that then appearing in overlay layer below 00modules. Not saying that lower layer is necessarily best for that one but just seeking confirmation the subdir _ facility works as intended.

[rockedge]

@wiak worked as expected!

Screenshot(2).jpg (34.01 KiB) Viewed 1278 times