KLV-Airedale-beta+ Released, Ready for Download

[wiak]

So despite all the above info, FatDog didn't boot for me either... But maybe my grub.cfg stanza wasn't correct. I browsed around but couldn't find a post on how to boot FatDog but found this stanza on another of my machines:

Code: Select all

menuentry "Start FatDog64" {
    insmod ext2
    search --no-floppy --fs-uuid --set  bbde1e15-c18f-4402-a6e3-cd30f1929b19
    echo "Loading vmlinuz"
	linux /FatDog64/vmlinuz rootfstype=ramfs
	initrd /FatDog64/initrd
	echo Booting ...
}

But... it didn't say anything wrong with vmlinuz signature, instead just hung after saying it was Loading vmlinuz (and I did wait quite a while; having noted it is a huge initrd). Maybe the nvme SSD harddrive issue if they use busybox as part of their boot(?) in which case my related KLV posts above explain the fix (use different busybox than the uclibc one...). I don't know FatDog so not sure how its boot is arranged - late now, might check tomorrow since I'd like to verify it can boot (since vmlinuz signed) and if only busybox issue I could swap to the one I suggested earlier.

EDIT: I cpio uncompressed FatDog initrd but noted its busybox looks like an X86_64 musl one so imagine that would be fine with nvme (so I didn't bother swapping with the other busybox since seems much the same albeit a much older one), but I also looked inside its kernel-modules.sfs and don't see any nvme.ko modules, which I found is needed. I have the same problem with weedogit EndeavourOS (in that case with secure boot disabled) - it also doesn't have nvme.ko and freezes after loading vmlinuz, so may be same missing nvme.ko modules problem? Oh well, this is KLV-Airedale thread and I don't use FatDog so I'll leave it at that - just was interested here because helps work out what is needed for KLV to boot on this machine of mine - I think the answer is a signed kernel and appropriate related cer file to add to the EFI via mokutil. On second thoughts I should try the busybox swap just in case... EDIT2: swapped in the new WDL-used busybox, and recompressed FatDog's cpio initrd, but FatDog still didn't boot on this secure boot nvme SSD system. No time to test further.

[Ramachandra Iyer]

I have installed grub. However grub2 was not properly installed. Hence unable to test KLV on my both HP laptops. Once grub is ready I will test KLV and Weedog.

[Clarity]

EDIT: I opened up the FatDog iso and copied its files into a folder, but I was hoping to see the fatdog cer or similar key so I could try and register it with Mok utils, but I can't for the life of me find it - I don't really want to dd to a usb stick and try booting that first since I don't have a blank usb stick handy... I'm suspecting now that it is in one of these usb boot images provided in FatDog iso... Oh well, later again maybe.

OK, this is offered as a help.

Assuming you have the SG2D USB handy (or even the Ventoy) add FATDOG ISO (i've been using v812 and also a newer one from James) to its /BOOTISOS folder. At boot, when you select the FD ISO, it will display the FD menu. Hitting the enter key, it demands the installation of the key, IIRC. Very interesting how they accomplish it. (Same as shown on the FD HTML you refer).

P.S. I am using the SG2D EFI version AND I use Ventoy USB with the Secureboot option and GPT setup. When they are booted for 1st time on UEFI enabled PCs, it will also demand the installation of its key, IIRC. Ventoy's demand can be reviewed on their webpage, here, look for "GUID for Ventoy with Secure Boot in UEFI"

These boot-assist, like FD, help us see the directions of hardware & OSes (Tovald's Linux is an OS) are doing to secure and identify the PCs being used to boot and run the OS.

Yes, it is not a conspiracy.

This week, I will request an area on the forum for members to share their QEMU stanzas for booting BIOS as well as UEFI vPCs. Thus, they will be able to mimic real firmwares when their boots are moved onto real PCs. The intent is to use kernel's modules for KVM so that tests and results can be quickly seen and responded to prior to an actual, slow, bare-metal test(s). There, I hope contents can be shown, per stanza, as close to the actual bare-metal it is would targeted; no matter if x86-64 or RasPI hardware targeted. These stanzas could be very useful in what this development community does in building their distros by reducing the efforts to address use and resolve problems when they arise without having to take down the physical platforms. There are at least a half-dozen or more developers in the community who quietly use 'specific" stanzas for their specific development; THUS, the idea of a threaded area is to COLLECT as many of these specifics so that any developer can grab and test a stanza for their vPC need(S).

[wiak]

Assuming you have the SG2D USB handy (or even the Ventoy) add FATDOG ISO (i've been using v812 and also a newer one from James) to its /BOOTISOS folder. At boot, when you select the FD ISO, it will display the FD menu. Hitting the enter key, it demands the installation of the key, IIRC. Very interesting how they accomplish it. (Same as shown on the FD HTML you refer).

Thanks Clarity. That would indeed be an easy way to get the key installed, but the way my system was set up it was easier for me just to uncompress the usb...gpt image file from inside the FatDog iso and find the key in there for enrolling with mokutil, which is what I successfully did. Wouldn't be so easy doing it my way for casual users admittedly.

[mikewalsh]

@Clarity :-

.....AND I use Ventoy USB with the Secureboot option and GPT setup. When they are booted for 1st time on UEFI enabled PCs, it will also demand the installation of its key, IIRC....

Gawd.

This isn't me "being funny", or sarcastic, or anything like that. Just a straight-forward question, which just wants a straight-forward answer.

Does going to all the above trouble actually make you feel more "safe" & "secure"..? Seems an awful lot of messing about to me......for comparatively little return.

Mike.

[dogcat]

@Clarity :-

.....AND I use Ventoy USB with the Secureboot option and GPT setup. When they are booted for 1st time on UEFI enabled PCs, it will also demand the installation of its key, IIRC....

Gawd.

This isn't me "being funny", or sarcastic, or anything like that. Just a straight-forward question, which just wants a straight-forward answer.

Does going to all the above trouble actually make you feel more "safe" & "secure"..? Seems an awful lot of messing about to me......for comparatively little return.

Mike.

Its nice that you supply repacks of some programs but you undo all that good by picking at people.

[mikewalsh]

@dogcat :-

Nothing to do with picking at people. I just do NOT understand the obsession this current tech world has with "security"; never have, never will. Perhaps if I ran Windows I would, but I have nothing to worry about where data loss is concerned.....and Puppy 'recovery' is but the work of a few minutes.

As for Clarity, it's a friendly squabble that dates back many years. Both of us know there's no malice in anything the other says. We still respect each other at the end of the day...!

(I'm a blunt Yorkshireman, I'm afraid. I call a spade a spade, and I don't mince my words! In my view, there's "nowt so queer as folk". Never was a truer word spoken...)

(*shrug*)

Mike.

[wiak]

@Clarity :-

.....AND I use Ventoy USB with the Secureboot option and GPT setup. When they are booted for 1st time on UEFI enabled PCs, it will also demand the installation of its key, IIRC....

Gawd.

This isn't me "being funny", or sarcastic, or anything like that. Just a straight-forward question, which just wants a straight-forward answer.

Does going to all the above trouble actually make you feel more "safe" & "secure"..? Seems an awful lot of messing about to me......for comparatively little return.

Mike.

Overall, everything involved with secure boot is indeed a hellavalot of trouble, and very painful (and cost me dozens of lost hours thus far). Personally it doesn't particularly make me feel more secure or safe (though future malware may become more and more dangerous and damaging, and the boot process is major target). However, fact is, it is the way things are going (and sooner rather than later) and since this particular laptop I'm on must run in secure boot enabled mode for various reasons, it simply will not boot any Puppy or KLV without all this trouble. In particular we need signed kernels. I note, by the way, that though current FatDog does come with a signed kernel, unfortunately that one does not play nicely in other ways with my fussy machine, and the later FatDog kernel available from ibiblio isn't signed otherwise I would have tried booting my KLV-Airedale install with that. As I said, KLV will boot from my laptop nvme SSD harddrive now, but only if I turn secure boot off.

[mikewalsh]

@wiak :-

Ah, I reckon you're right, Will. It's probably got so's plenty of devs/maintainers in the Linux eco-sphere have noticed this recent upsurge in Linux vulnerabilities, along with the current spate of malware that is now being actively targeted at Linux machines.

Like as not many of these are trying to be pro-active, with an eye to future "developments" (all credit to them for that).....with the result that Linux systems are soon going to be subjected to previously undreamt of levels of restrictions &/or general "awkwardness", that many never imagined they'd ever see.....

All courtesy of the usual small percentage of lazy bastards who are convinced that the rest of the world owes them a living. Go figure.

Sod's law, ain't it?

Mike.

[rockedge]

I can perhaps compile a version of 5.16.14-klvx with the necessary options enabled that support kernel signing.
Then begin testing how to do it on VirtualBox with virtual UEFI equipment.

@fredx181 Something way more fun.....experimenting with a xlunch menu replacing whisker menu, which will remain as an option.

Screenshot(2).png (197.46 KiB) Viewed 1910 times

Decided to have the icon open xluncher2 that opens to a full desktop which closes after application selection

Screenshot(3).png (198.53 KiB) Viewed 1907 times

[wiak]

@fredx181 Something way more fun.....experimenting with a xlunch menu replacing whisker menu, which will remain as an option.

I haven't tried xlunch (at least I can't remember), but it looks great and possibly more suitable for KLV audience tastes than heavier whisker (though good the choice is there since if not running probably doesn't add much bloat anyway).

[wiak]

I'm currently posting from latest KLV-Airedale beta12 on my tricky HP laptop and with secure boot enabled. Well... not pristine KLV-Airedale since I've swapped in the signed Zorin kernel plus made a 00modules (uncompressed) and 01firmware (uncompressed) from Zorin. Being able to use uncompressed addons makes life so easy sometimes...

The change was reasonably easy to do. I used weedogit to make a WDL_Zorin and then I simply opened up the resulting 08filesystem.sfs of Zorin and extracted the needed parts into 00modules and 00firmware. The only extra complication was that I needed to put zorin's overlayfs module into the initrd so I used modify_initrd.sh for that bit, copied zorin's modules into initrd/usr/lib/modules and then simply deleted all modules there except that one for overlayfs (so the resulting initrd remained small). May sound like a lot of effort but reality was I already had WDL_zorin on the system, which boots fine, so just took a few minutes to swap over the kernel components to my KLV-Airedale64 frugal install (all on the nvme SSD harddrive and, as I say, with secure boot enabled). Also, similar to the way I've scripted weedogit.sh I could easily script the above procedure, which I likely will... (until, that is, we get round to having a signed KLV-specific kernel).

The signed Zorin vmlinuz kernel being the trick of course.

I have to be careful not to damage the Windows installation on this machine (for now), so I simply used xbps to remove ntfs-3g, which turned out to be enough to stop Thunar being able to mount it. One day I'll no doubt remove that already severely shrunk Windows partition altogether since I'm never likely to use it.

[fredx181]

I had secure boot disabled on my new laptop (UEFI boot only, no legacy boot available) and had already done the UEFI setup (see below).
Now, out of curiosity, I enabled secure boot and to my surprise all distros I tried, booted OK (including DebianDog FatDog and KLV-airedale).

On DebianDog Bookworm (has signed kernel) I added module.sig_enforce=1 to the boot kernel line, and booted without problems.
On another DebianDog with an unsigned kernel, booting with module.sig_enforce=1 failed, but without that, it booted OK.

Could be that my setup is different than yours, @wiak , I deleted Windows and partitioned with Gparted.
Here's how I did the setup, info below from jamesbond, sometime ago I asked him for help, which he kindly did:

a) Make a FAT32 partition
b) Put the UEFI boot image files in it.

This is true whether you're booting from harddisk, or USB flash drive.
For an MBR partition, the partition is just normal FAT32 partition.
For a GPT partition, partition needs to be marked as "boot" and "esp" flags (using gparted).
The can be used to store other files too (DebianDog files), it is not necessary to dedicate it only for UEFI files.
..........................
Now the details. The files that goes into the efiboot.img (for ISO) or the UEFI boot partition (for hdd/usb booting) is the same. You can find the files here: http://distro.ibiblio.org/fatdog/other/ ... -puppy.zip

So, I just unzipped EFI-shim-1.33-puppy.zip in my first partition (FAT32) and added grub.cfg at the root of the partition (EFI/boot contains "puppy.cer", perhaps that's the important file for secure boot ).
Also I have these files on my FAT32 partition, the UEFI BIOS setup created them when I chose "export keys" or something.

2022-04-11-103202_241x187_scrot.png (5.38 KiB) Viewed 1822 times

[wiak]

On DebianDog Bookworm (has signed kernel) I added module.sig_enforce=1 to the boot kernel line, and booted without problems.
On another DebianDog with an unsigned kernel, booting with module.sig_enforce=1 failed, but without that, it booted OK.

Could be that my setup is different than yours, @wiak , I deleted Windows and partitioned with Gparted.

I believe it is different. I have both the puppy.cer and the similar key for FatDog already enrolled in machines EFI registry. But the laptop further insists on signed kernel (no module.sig_enforce used at all; I didn't know of that one but I don't see how it will help in my scenario). Using Zorin signed kernel is fine for me at the moment - it is no big deal, but may become an issue for others especially as secure boot requirements seems to becoming stricter over time to match Microsoft demands. I can switch off various levels of security, but then Msoft Windows won't work now.

Having said that, I could be wrong about all this - I don't know much about it. I can't change much on this machine anyway (since has a specific business purpose and I should not be experimenting on it) aside from what I've already done (shrunk the main Windows partition and created an ext4 one for my use).

I will try module.sig_enforce=0, but I expect that won't help here since surely the default anyway.

[fredx181]

I have both the puppy.cer and the similar key for FatDog already enrolled in machines EFI registry.

Also you have these files (in EFI/boot) ? (don't know if included in FatDog or not)

2022-04-11-113101_316x266_scrot.png (20.22 KiB) Viewed 1799 times

I also don't think that adding module.sig_enforce= is going to help you, for me it was just for testing if secure boot with a signed kernel works.

[wiak]

I have both the puppy.cer and the similar key for FatDog already enrolled in machines EFI registry.

Also you have these files (in EFI/boot) ? (don't know if included in FatDog or not)

It is a totally different arrangement to the way you manually set up things via gparted. I did an official full Zorin install and it put grub2 and all needed files on the system and automatically took into account already existing Windows partitions.

Code: Select all

/dev/nvme0n1p2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

In that /boot/efi/EFI/BOOT directory the system has three files:
bootx64.efi, fbx64.efi, and mmx64.efi

/boot/efi/EFI/ actually contains three subdirectories: BOOT, HP, Microsoft, and ubuntu

ubuntu contains: BOOTX64.CSV, grub.cfg, grubx64.efi, mmx64.efi, and shimx64.efi
HP and Microsoft contain all sorts of junk, but don't seem important.

Maybe... I need a new folder for Puppy with puppy.cer and so on in it? Seems unlikely to me, but worth a try. My understanding is that that stuff under ubuntu is what is being used along with whatever key (cer) files have been registered with the EFI. Main issue seems to be that the secure boot is requiring signed kernel (doesn't need to be ubuntu or Zorin - fatdog signed seems to load okay, just its vmlinuz doesn't work well with this system).

[wiak]

I believe the following link, which talks about newer firmware, is pretty much describing the problem (albeit about some error after kernel signing attempt):

https://unix.stackexchange.com/question ... er-signing

They never solved their problem though. Related stuff is common after google vmlinuz kernel invalid signature, such as:
https://gauravsohoni.wordpress.com/2020 ... in-ubuntu/

EDIT: I'm thinking it may also be something to do with me using Zorin's grub2, even though it seems happy to load say FatDog's signed kernel too. But maybe if I create a new partition and configure it Puppy way (per what you described Fred) and somehow or other boot from there instead all will be different. I'm guessing and truthfully I don't like experimenting on this machine... Alas I don't see how to arrange that in practice - seems to need that fat partition - it is being mounted to /boot/efi in Zorin hierarchy so it would be the same grub2 and same issues as far as I can see. Probably is way to re-arrange matters, but I don't know how and probably won't risk trying.

https://askubuntu.com/questions/1081472 ... -signature

Since the most recent GRUB2 update (2.02+dfsg1-5ubuntu1) in Ubuntu, GRUB2 does not load unsigned kernels anymore, as long as Secure Boot is enabled.

[fredx181]

Well, yes you have a different setup and want to keep Windows, so most likely you cannot duplicate the way I setup on your harddisk, but possibly you can on USB .
What I was just trying to say is that with my setup there's no need for signed kernels, as KLV booted fine also that way with secure boot, so that hopefully we don't have to go into the big trouble of a "must have signed kernel".

[wiak]

Well, yes you have a different setup and want to keep Windows, so most likely you cannot duplicate the way I setup on your harddisk, but possibly you can on USB .
What I was just trying to say is that with my setup there's no need for signed kernels, as KLV booted fine also that way with secure boot, so that hopefully we don't have to go into the big trouble of a "must have signed kernel".

Oh I have no problem with boot from usb - that's been working for long time. I already use same setup as you described there - I used Puppy utils to create that usb stick arrangement. My thoughts are more to do with someone new coming along that wants to dual boot with Windows - then they could well face what I am describing (aside from option to use usb stick for Linux).

Personally, at least longer term, it seems to me it would be a good idea to start self-signing kernels since that seems to be sufficient overall anyway (FatDog already doing so for their latest release). But from my personal situation perspective it doesn't matter at all - I am fine with external usb boot, and have other older machine for dev uses anyway, though on this newer machine I do prefer to simply use Zorin's signed kernel with KLV-Airedale (since also using weedogit Zorin variant on same machine).

EDIT: I don't think (from reading further) that it is particularly difficult to generate a new key and enrol it, and thereafter with the openssl generated certificates to sign a kernel to work with the key. Haven't tried yet, but going to.
EDIT2: Fortune favours the bold, but on second thoughts I'm not going to try on this machine at this time:
https://wiki.archlinux.org/title/Unifie ... ating_keys

Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft's key.

But signing kernel doesn't sound risky so maybe can use FatDog openssl stuff/keys to do the signing? No, I don't have these obviously so I think I'll just live with what I have for now. Hopefully temptation won't get the better of me. This stuff is black magic to my brain at the moment and common-sense warns me to avoid it further.

[rockedge]

I tend to agree with @fredx181 on this. Some time ago I set up a friend's laptop to boot Puppy Linux Bionic64 and now recently KLV-Airedale which both boot using the 2 partition method. I used a 512 MiB FAT32 partition and the other much larger as ext3. I actually used Grub4Dos to set up the FAT32 partition and use the menu.lst. Windows 10 was thrown out with only a Bionic64, Fossapup64 and now a KLV-Airedale on the ext3 partition so the user can try all 3 and choose what works for him.

I was at the time unfamiliar with UEFI booting so I added the contents similar to the /boot directory in KLV and Puppy and this machine boots the frugal distro's smoothly in this config. I'll have to look at it again to remember what I stuffed in the FAT32 partition, BUT like fredx181's experience I also could get these 3 distro's to boot with UEFI boot enabled.

Though to keep in mind, the stock Windows 10 I had removed and I re-formatted the entire internal hard drive to the FAT32 - EXT3 partitions then added the Grub4Dos and OS's.

Why it worked at the time I attributed to pure luck.

[fredx181]

@rockedge Perhaps I misunderstand, but you say that you boot with UEFI AND Grub4dos.
I thought grub4dos has no support for UEFI, perhaps I 'm wrong though.

[rockedge]

@fredx181 That's the strange thing. I had no idea at the time how to set up GRUB2 that well. All I knew was I couldn't get it to boot at all. So after fast research I went with this set up and it works. Why exactly I will now have to really look at. I lucked out.

Then before that I had even more luck. I have a 32 bit DELL INSPIRON 1505E that had Windows 7 on it. Well at the time not knowing anything so no fear, I just ran Grub4Dos on the drive and it set itself up and I was off and dual booting. Eventually the machine took a free Windows 10 upgrade and now I have a dual booting Win 10 machine with a Grub4Dos boot loader. No idea why it still works but I just did four sets of yearly taxes on the Windows bit and testing and playing around with that powerhouse VoidPup32 and all of these WeeDogs and DebianDogs all over an external USB HDD that goes well with it. Draw back is the laptop only does 32 bit.

I use a chainload +1 to get to the Windows boot loader.

The 32 bit DELL INSPIRON 1505E does not have UEFI secure boot capabilities

[rockedge]

I might have a machine in the garage that does the full UEFI boot gig. Might be worth seeing if I can really lock it down and get it to boot.

Most of the other machines are pretty old. Though my DELL PowerEdge R210 II has every bell and whistle when it comes to UEFI secure boot. But it allows turning it all off and goes with a reasonable legacy BIOS boot.

I have sort been afraid of turning on all of the UEFI stuff on it. Maybe it's time (soon) to begin working with it in the secure boot mode?

Somebody ought to write again a step by step instructions on how to install Grub2 using a Puppy, Dog, KLV or WDL
I never have done it from scratch. Like how to do it without destroying anything.

[rockedge]

I went to the last steps to sign a kernel and modules on a QEMU machine but my QEMU does not support UEFI enough and told me so.

I installed MOKUTILS and just kind followed along some steps

Code: Select all

mkdir -p  /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=YOUR_NAME/"
[...]
chmod 600 MOK.priv

but this showed the my QEMU was not ready ->

Code: Select all

mokutil --import /root/module-signing/MOK.der

The VirtualBox I use though does have UEFI virtual hardware so another way to go there.

[fredx181]

@rockedge Perhaps you are mixing things up a little ?
From what I know, UEFI machines can have option "legacy boot" (same as old BIOS), but also "secure boot".
Switching to "legacy boot", grub4dos can be used AFAIK. Secure boot needs the extra treatment as we are discussing.
All new for me too, very recently I used a laptop from 2007, no UEFI inside, perhaps someone else with more knowledge can jump in ?

[rockedge]

@fredx181 I think you are correct. There must be a difference between the UEFI / Legacy BIOS boot and Secure boot. These laptops I have I will look over carefully. I know the blade server has Secure boot.

I just don't have access to a very new machine to try anything on.

[fredx181]

More about "signed" here:viewtopic.php?p=54678#p54678

[rockedge]

Experiments with signing kernels and KLV still on going.

@wiak the new initrd.gz is functioning very well and will be standard going forward.

@fredx181 xlunch is working great and I like it personally over whisker menu. This xlunch will also go in any KLV JWM - Rox desktops as well.

I have been running different OS's through VirtualBox with EFI hardware enabled. Not much success but getting more practice breaking things.

KLV is running so very nicely in QEMU with Fossapup64 as host that I've been using it in a full screen mode and one can not tell by the way it operates that it's a virtual machine.

[Grey]

and one can not tell by the way it operates that it's a virtual machine.

Externally, yes. But you can check in the command line whether the kernel module qemu_fw_cfg is loaded. It's even easier to look it up in HardInfo.

Previously, on ZX Spectrum, the authors of commercial games and programs (in the countries of the ex-USSR) tried to come up with a way to prevent a program or game from starting in the emulator. At first, there were discrepancies with the real machine in the emulators and it was possible to "declassify" the emulator and reset it at the very beginning of the program start. But then the emulation became perfect. The last interesting case that I remember (it was done in Kharkiv, Ukraine) is a program for the ZX Spectrum, which, after running in an ZX emulator on an Amiga computer, caused the Amiga to reset ( not the emulator, but Amiga itself )

It seems Puppy is not going to get on commercial rails and we will not fight the launch in Qemu

[wiak]

Currently back to using my old, 2008, 12" screened HP elitebook 2530p core2duo 4GB Ram laptop. However, I finally got round to creating some hard disk space on it by deleting the old Windows 7 partition and reformatting that to ext4. Previously I only had a couple of 8GB linux partitions, which were constantly overflowing, but now I have a 143GB partition with 123GB free... I'm also now booting on it using grub2, which I prefer nowadays, rather than grub4dos. Not using UEFI though (this old machine does have some kind of UEFI ability if set in BIOS, but I think it is pretty old/imperfect variation and certainly doesn't have secure boot at all.

I'm probably going to re-partition that larger area though since I want to experiment with using overlayfs with full installed distro (zorin probably, since I'm used to it now, or mayby endeavourOS silnce I really like Arch-base for more uptodate packages). However, now I can also install KLV-airedale without needing to modify it to use zorin signed kernel first.

The reason I want to experiment with full installed distros is that I want to see if I can narrow the gap in terms of the flexibility provided by frugal installs versus a full install. With the initrd used in KLV-Airedale the difference is a bit grey in that you can put the whole uncompressed main rootfilesystem into upper_changes for a behaviour that is similar in many ways to a full install but with full frugal overlayfs functionality still in operation. What I'd like to try is to use an overlayfs alongside a proper full install to see if I can achieve some of the save2flash functionality of a frugal install but with a full install.

On the whole, a frugal install is more convenient to work with when tinkering and trying out new ideas since no need to commit changes between boots. But there is the issue that the upper_changes folder, which is uncompressed, can become very large when upgrading the distro packages (such that the original rootfilesystem.sfs become a waste of dead space). The 'pseudo frugal install', where whole root filesystem is contained in the upper_changes, gets round that issue since then the old package versions get overwritten in that read/write upper_changes. There remains the disadvantage that (like a full install) the uncompressed upper_changes takes up a lot of space, but nowadays that's often not much of a problem since storage space generally high.

But the process of fully upgrading a distro, and keeping it up to date, does tend to be easier and more-convenient with full installs though also relatively easy with the frugal 'pseudo full install' approach. But there is the problem that with frugal installed distros the initrd needs to be upgraded too in order to work with updated kernel/modules (though huge kernel use helps alleviate that problem). Assuming the total upgrade of a frugal installed distro is successfully achieved without breaking things, a remaster afterwards makes sense since the original rootfilesystem sfs file ends up pretty much all overlaid anyway. Overall, a frugal install can actually end up taking up more space than a full install, funnily enough, unless such remasters are made, and frugal can also take up more precious RAM depending how it is designed or used (e.g. copying sfs files into RAM prior to use - personally I prefer to avoid that mechanism; on old machines there is already too little RAM without wasting some of it to hold copies of sfs files, and on new machines external storage is fast and everything gets cached anyway).