Puppy Linux Discussion Forum

current
The second release of the inOnePup project, 2 Puppy installs where all of Puppy is contained in a single file.

'ffiPup' - Frugal Full Install

'fsiPup' - Frugal Squashfs Install

For details of release and download of 'inOnePup-05.tar', see viewtopic.php?p=112901#p112901

old stuff
Where the "Frugal" in "Frugal Install" relates to the use of disk space,
i.e. it uses just a single directory, not a partition.

Where the "Full" means that in the running Puppy all the files are just there,
there are no ".sfs" files, no "save" mechanisms, and no "whiteout" files.

So FFI is a "Full" install in a single directory, that runs as "pupmode=2".
Here is a screenshot of the "install directory" for JammyPup32:

The "Full" install is in the directory 'upupjj+dfiles'.

How
The 'local-initrd.gz' contains a replacement 'init' script that builds a slightly odd overlayfs stack.
The upper directory is 'upupjj+dfiles', the work directory is 'work', and the lower directory is 'empty'.
Since the 'empty' directory is in fact empty, all files exist in only the RW layer.

Yes, it actually works.

How to replicate

Do a normal frugal install, (I used FrugalPup on JammyPup32-22.04-231221.iso).

Upack the ".sfs" files in reverse order of the normal stack, i.e. starting with zdrv, like:

unsquashfs -f zdrv_upupjj+d_22.04.sfs
unsquashfs -f fdrv_upupjj+d_22.04.sfs
unsquashfs -f puppy_upupjj+d_22.04.sfs
unsquashfs -f adrv_upupjj+d_22.04.sfs

(The ".sfs" files can now be deleted.)

Rename 'squashfs-root' to 'upupjj+dfiles', (${DISTRO_FILE_PREFIX}files).

Download 'local-initrd.gz' and move it to the "install directory".

Download 'rc.shutdown.gz', gunzip it and move it to 'upupjj+dfiles/etc/rc.d/rc.shutdown'.

Create empty directories 'empty' and 'work'.

Reboot.

Note:
This is just a "proof of concept" release.
If this were to be taken seriously, there would need to be an "install" utility,
although most of this should already be present in current "full install" utilities.

I've always ruled out "Full" installs because I've never been prepared to divide my HD into 1 partition per Puppy.
This approach would put it "back on the table", but I just can't think of any circumstance where it would be more attractive that a staright frugal install.

Edit:
Current release:
For current release notes see viewtopic.php?p=110303#p110303
Release files are in:

Sounds reminiscent of the "Pseudo Full Install" possible with Kennel Linux frugal installations. Also using a XXdummy and a work directory.

Any advantages to an uncompressed install?

Is pupmode=2 something old or new?

pupmode2 is the normal way Puppy works as a full install.

From how Puppy works:

This is the absolute simplest configuration. There is no ramdisk, the partition itself is mounted directly on the top "layer".
In fact, if there are no ".sfs" extensions to load then Puppy will not use unionfs at all, so there are no layers.

rockedge wrote: ↑Mon Dec 25, 2023 7:05 pm

Sounds reminiscent of the "Pseudo Full Install" possible with Kennel Linux frugal installations. Also using a XXdummy and a work directory.

Actually, jamesbond pointed out some time back that FatDog had also implemented an arrangement that seemed by his description pretty similar (maybe the same) as what we call pseudo full install. I've only ever booted FatDog to see what it looks like so I don't know if the same exactly, but may well be; I don't think they documented it in a forum thread earlier, or maybe I just missed it long ago when I maybe hadn't even started FirstRib(?); I certainly would have mentioned it otherwise.

ONE. First post of this thread does look like that pseudo full install arrangement we have been using since almost the first days of FirstRib/WeeDog, but only gyrog would know one way or the other - I haven't time to try it sorry.

However, could alternatively be similar or same to one of the other KL modes we have documented and used (though doesn't read like it is - definitely seems like simple pseudo frugal install type of arrangement, which is a bit tricky to implement for Puppy Linux since Puppy relies on several sfs files whereas KL distros only ever 'need' the main firstrib_rootfs and that, and any addon layer can be in uncompressed or sfs form). But here are two other KL modes we use specially with actual full installed underlying filesystems (different and in many ways more flexible/powerful than standard KL pseudo full install these ones):

TWO. Because FR initrd can use either sfs layers or uncompressed layers, some year back I explained how I often almost instantly changed my normally used full install of Zorin lite OS into a quick FR frugal (still using same Zorin lite install). For that I simply created a new empty directory alongside my Zorin full install and then simply used move command (or file manager) to almost immediately copy the whole of Zorin filesystem into that new directory, which I could then use straight away as a firstrib_rootfs. I could equally almost instantly switch it back to normal Zorin full install simply by moving the filesystem out of that new subdirectory back to top of partition; takes no time or actual moving of files since on same partition, so instant... I can't at this moment (busy) find the post where I explained that methodology though. (NOTE that you can also use standard KL pseudo full install mechanism arrangement with this too if you wish, you always can... - which per usual is useful for ease of updates and upgrades).

However, more recently, about around June/July 2023 I documented a much more powerful facility I don't think anyone has come up with before:

THREE.

wiak wrote: ↑Wed Jul 26, 2023 11:22 am

KL_full2frugal (KL_full2fr in short)

Embracing what some see as the 'Other' distros and making them part of KL; a new era and in that an attempt to broaden/widespread forum appeal: bringing in the 'Others' as part of the forum audience.

Scenario:

You have a full installed distro such as Linux Mint (I used XFCE) or Zorin, Manjaro or Endeavour or whatever (I've only tried it with Linux Mint XFCE and Zorin OS lite XFCE so far, but should work with many - only thing that might go wrong would be if script can't find the full install vmlinuz - just extract that manually if that proves to be a problem).
You love its power and ease of upgrade, but miss all the forum layered OS functionality (and particularly no persistence and/or save on demand modes and sfs addons).

Needed the slightest of tweaks to FR initrd back then (but a permanent addition). That was a huge improvement of TWO. above, since it didn't require moving the original full installed distro at all and could be used with pretty much any already full installed distro (such as Linux Mint, Zorin and so on). The process was automated using a simple script, which I documented as "KL full to frugal".

FOUR. KL multi-instance is an addition to all of the different KL install types. Really great thing about KL full to frugal (or any of the others above) is that I later found that it also worked fine with KL multi-instance distro creations. So end result was you had not only a normal full install of some distro or other, but still using that exact same installation of files you could have a 'frugal' (in own folder) version of it, which optionally could include sfs addons and save folder if you wanted that extra, but also could use the KL-multi methodology so could have unlimited number of parallel frugal installs (each with their own optional sfs addons and/or savefolder or in pseudo full install arrangement, but able to also access the whole caboodle of addons/save-folder of any other one of the multis... all just with a few kilo-bytes extra storage space per multi-instance.

But yes, none of the above need to use sfs files or save-folders at all (the pseudo full install directory being the save folder in actual fact...). KL mechanisms TWO and THREE use actual full installs and simply allow them to be run from subdirectory as frugal install, but multi-instance is the best one of all whether used with normal frugal installs or with KL full to frugal arrangement.

No worries anyway, what others develop is up to themselves and useful overall to everyone and the community, but it's true, I feel, that is always good that research/development tries to also refer to previous similar methodologies, give credit whenever due, and/or state the advantages in the new introduction - I was thus remiss in not noting that FatDog had long ago provided a similar (apparently - again I've not checked) technique to KL pseudo full install mode, but I 'think' FatDog haven't implemented anything like KL_full to frugal, but you never know... they are a pretty good and active dev team (maybe best on here, experience-wise and team-size overall but most of their documentation is off-forum, and thus better documented than Puppy or KL really, but not thus quite so 'directly' instantly accessible as in threads posted to this forum venue therefore). Also KL multi doesn't seem to be replicated, except that I provided a version of that for Puppy too, though I've never heard of anyone using it with Puppy (aside from myself)..., but anyone who has used multi-instance with KL will realise what a powerful facility it provides so I'd highly recommend it being used with Puppy too. I documented and scripted how to do that:
viewtopic.php?p=99318#p99318
which refers to:
viewtopic.php?p=99334#p99334
viewtopic.php?p=99154#p99154

Anyway, though not exactly off-topic, these related mechanisms aren't to do with gyrog's implementation of whatever this thread is about exactly - just mentioning for others in case they want to try any part of the overall combination and to encourage similar developments for Puppy if considered useful.

provided a version of that for Puppy too, though I've never heard of anyone using it with Puppy (aside from myself)...

I have, and will get deeper into it after the holidays.

@gyrog glad you have this project up and going. Interesting avenues to explore with the Puppy Linux structures and possibilities.

I was not aware of the "pseudo full installation" in either FatDog or KL, but it does seem to be the same thing.

But the question for me is, does such a facility have enough usefulness to warrant a "proper" implementation in Puppy?
And if so, should it be offered as an alternate to a "partition full install", or as a replacement?

I'm still not convinced that the concept is worth the effort.
So, it would be helpful if folk who have found "pseudo full installation" to be useful, could briefly explain the circumstances where it proved to be useful.

gyrog wrote: ↑Wed Dec 27, 2023 12:10 pm

So, it would be helpful if folk who have found "pseudo full installation" to be useful, could briefly explain the circumstances where it proved to be useful.

I usually run in "save on demand" or pupmode 13, but try to make changes directly after booting in order to avoid making changes after going online, but, I often times need online resources to effectively accomplish the changes, so reboots need to be planned....

being able to directly edit pseudo eliminates the need to make changes by running a save operation or snapmergepuppy

that said, one can decompress the sfs, make manual changes, and recompress, so pseudo just saves a few steps

Pseudo full is very useful in KL for those that want to keep their main root filesystem continually up to date (without having to do any manual remastering) since anything added or updated goes straight into the uncompressed root filesystem.

That is particularly useful with KL since it is using upstream package managers such as xbps from Void, or pacman from Arch, or apt/dpkg from Debian-based distros and that, of course, has a package manager database that needs to be accurately maintained when updating/upgrading to latest packages. Because of the way KL can work with uncompressed layers anyway, using pseudo is hardly any difference to arrange than a normal KL install. Its only disadvantage really is that running with root filesystem uncompressed takes up more on-disk storage space.

Since Puppy does things differently, the pseudo full facility may not be so useful. Also since Puppy is originally not built as a single main root filesystem, but rather as several parts in sfs form that are normally layered together (e.g. adrv, ydrv, puppy sfs), it seems that the read/write Puppy root filesystem you need to construct for your pseudo full arrangement would need to be pre-merged such that any additions that might effect either of adrv, ydrv, and puppy parts are all taken into account correctly (?). Because of that relatively major change it wouldn't seem so useful for the Puppy case, but maybe I'm wrong about that since I haven't been able to study how this Puppy Full Frugal Install is being done in detail.

So, it would be helpful if folk who have found "pseudo full installation" to be useful, could briefly explain the circumstances where it proved to be useful.

With capability to run the system's rootfs uncompressed and write to it as the merged read-write layer one can totally configure and customize the system then simply squash the the upper layer as the rootfs SFS and create a very accurate Re-mastered complete rootfs SFS which can then be the foundation for an ISO of the system or replace the rootfs of an existing ISO and repackage it.

Overall I find the feature very useful in the KLV-Airedale, KLV-Spectr systems and @geo_c has quite a bit of experience using a PFI (Pseudo Full Install) in KLV's to perform remastering complete systems to read only squash based ones.

Though as @wiak points out, we might have to try it out and see what happens and if any usefulness is produced.

rockedge wrote: ↑Wed Dec 27, 2023 9:20 pm

Overall I find the feature very useful in the KLV-Airedale, KLV-Spectr systems and @geo_c has quite a bit of experience using a PFI (Pseudo Full Install) in KLV's to perform remastering complete systems to read only squash based ones.

What @rockedge said. It's a much simpler and fail safe method of remastering a system, at least in the firstrib environment. I haven't tried it with a puppy.

Basically to do this psuedo full install, it's simply a matter of unpacking the rootfs, renaming to upper_changes, and then creating an empty dummy rootfs, that's so the first rib init functions correctly and everything gets written in the upper_changes containing the whole system. Then at whatever point it's called finished, resquashing the upper_changes back to a file named 07rootfs is all that it takes to have a remaster. Nothing will be missing, and anything deleted or uninstalled in the process will be gone.

If it works in the puppy environment, I personally think it's a much easier way to remaster than using complicated tools. I've done remasters using the tools availble in pups in the past, and the results have been hit or miss, usually miss.

Using psuedo full install I've been able to build rock solid custom variants like the one I'm posting from now.

Thankyou for all those responses concerning "pseudo full install".
I do think that my "frugal full install" is the same thing but implemented in Puppy.
(It works for me.)

We now have some Puppies that use the native upstream packagge manager, i.e. dpup and voidpup.
So it could be useful to users of those Puppies.

The remaster idea might also work, if the resultant single ".sfs" file is named appropriately as "puppy_....sfs", all the other ".sfs" files are optional.

So I intend to revisit this with a view to producing code that can be merged into Puppy, i.e. an enhanced 'sbin/init_full_install' script,
and a utility to install it.

Now, for the other question, how to integrate the install utility?
My current thinking is a separate utility, that can be another item in the Puppy install wizard.
An alternative approach would be add this facility to FrugalPup, but I think that confuses FrugalPup's niche.

gyrog wrote: ↑Thu Dec 28, 2023 2:01 am

Now, for the other question, how to integrate the install utility?
My current thinking is a separate utility, that can be another item in the Puppy install wizard.
An alternative approach would be add this facility to FrugalPup, but I think that confuses FrugalPup's niche.

Yes, initial install utilities more generally is an area KL has lagged a bit in. The original build is automatically installed correctly along with correctly provided grub stanzas, but when we want to do relatively simple re-arrangements, such as for pseudo full install everyone thus far tends to just do it manually. Similarly with merge rollback upper_changes layers, though some effort has been made recently to automate some of the tricks rather than always just using manual rearrangements to suit our needs. Puppy is very different in that way since from its beginnings it tended to provide very helpful usage utils that could be used without much thought (or even sometimes much understanding of how they work). But I'd agree that separate utilities is a good idea - one utility for one job philosophy since the result can be combined into a overall general utility GUI frontend anyway. An easy to set up pseudo full facility would be extremely useful in Puppy IMO, for all the simple but important reasons others and myself mentioned.

I accept that my "Frugal Full Install" already exists as "Pseudo Full Install".

This is the first release of an implementation that can integrate it into woof-ce Puppies.
It also contains CLI setup utilities.

Files:

'pfiPup' is a CLI utility to setup a "Pseudo Full Install" directory from either an ISO or a normal frugal install.
Run "pfiPup -h" for usage information.

'pfiBoot' is a CLI utility to generate a grub2 boot entry for a "Pseudo Full Install" directory.
It writes to STDOUT so it can easily be redirected to append to a 'grub.cfg' file.
Run "pfiBoot -h" for usage information.

'local-initrd.gz' contains an enhanced version of the '/sbin/init_full_install' script in 'initrd.gz'.
This means that 'fullinstall' must be included as a boot parameter in the grub2 boot entry.

'rc.shutdown' is patched to remount everything "rw" to "ro", this ensures a clean shutdown.
'etc/rc.d/rc.shutdown' in "${DISTRO_FILE_PREFIX}files/" should be replaced with this file.

A JammyPup32 example:

./pfiPup /nobak/downloads/JammyPup32-22.04-231221.iso /initrd/mnt/sdc2/tpups/upupjj+dFull
mv -f ./local-initrd.gz /initrd/mnt/sdc2/tpups/upupjj+dFull/local-initrd.gz
mv -f ./rc.shutdown /initrd/mnt/sdc2/tpups/upupjj+dFull/upupjj+dfiles/etc/rc.d/rc.shutdown
./pfiBoot /initrd/mnt/sdc2/tpups/upupjj+dFull >> /mnt/sdb1/grub.cfg

Reboot, selecting "Puppy JammyPup32 22.04 (PFI) (xxx)" in the grub2 menu.

Replacements for files in first post.

My current thinking is a separate utility, that can be another item in the Puppy install wizard.

I like the separate utility approach as well. This feature I believe is a really positive enhancement of Puppy Linux and I will be experimenting with the scripts beginning today.

@rockedge, thanks for testing.

This is the release of a utility to setup a 'puppy_....sfs' from a "Pseudo Full Install".
It is supposed to be useful to create a "re-mastered" Puppy, by directly modifying a "Pseudo Full Install", and then running this script.
Similarly, use the native package manager to upgrade a "Pseudo Full Install", and then run this script.

Files:

'pfiSfs' is the CLI utility.
It takes the path of a "Pseudo Full Install" directory as a parameter.
A 'mksquashfs' of "${DISTRO_FILE_PREFIX}files/" is written to the install directory, as "puppy${DISTRO_FILE_PREFIX}${DISTRO_VERSION}.sfs".
It also creates an 'AUTOSAVE' flag file in this install directory.
If the install directory is then booted without "fullinstall" as a boot parameter, it will run as a normal frugal install, with only 1 ".sfs" file.
Run "pfiSfs -h" for usage information.

'pfi-sfs-exclude.lst' is an optional text file containing a list of files to exclude from the ".sfs" file.
If it is present in the same directory as 'pfiSfs' the specified files will be excluded from the 'mksquashfs'.
Otherwise all files in "${DISTRO_FILE_PREFIX}files/" are included in the ".sfs" file.

A JammyPup32 example:

./pfiSfs /initrd/mnt/sdc2/tpups/upupjj+dFull

Edit 'grub.cfg' so you can boot the same install directory without "fullinstall" in the grub2 "linux" line.
Replace "fullinstall" with "punionfs=overlay" to use overlayfs.

You can still boot the same install directory with "fullinstall" in the grub2 "linux" line to run as a "Pseudo Full Install".

So if I install a Puppy as a "Pseudo Full Install",
uninstall any software I will never use, and install the software I do use, that is not included in the release,
and then produce a frugal install from it via 'pfiSfs',
I will end up with a frugal install with all my software in the single sfs, and none in the savefolder.

Further, if I do all software upgrades in the "Pseudo Full Install", and then replace the sfs file in my frugal install,
I will never have any software in my savefolder.

This would imply that I can forget applications in sfs files, just use pets (or apt etc...) in the "Pseudo Full Install".
Plus "protable apps" that are "activated" in the "Pseudo Full Install".
("activated" means, add ".desktop" file, icon file, and symbolic link to 'AppRun/LAUNCH' somewhere in PATH.)

Hmm.., could be worth consideration.

@gyrog Yes that's one of the features really useful. In KLV-Airedale in the early stages of developing it we thought about some small configurations that would be really useful if already setup for a default state coming OOTB when KLV-Airedale is booted. We found setting up the XFCE4 desktop while in a "Pseudo Full Install" was really nice and was "you get what you see" type of situation. We could boot the KLV in the "Pseudo Full Install" setup work on customization's (like selecting a wallpaper) and then while still in the "Pseudo Full Install" state delete unnecessary cache contents and clear the Bash history contents then squash the rootfs again to have the SFS read-only rootfs and as small as possible. Then we produced an ISO, which when started will have the custom wallpaper in place, as an example.

So like remastering in a sense, just a slightly different method. Very powerful stuff when used with some imagination and experimentation.

I just did a test with "dpup Bookwork64":
I installed it as a "Pseudo Full Install" using the method I outlined previously.

I then removed firefox by deleting all the files listed in '/var/packages/builtin_files/firefox'.
(Should be able to write a script to delete the listed files for a selected "package".)
And then pruned the '/usr/lib/firmware' directory to just the firmware needed by my computer.
Then created a "frugal" install with the 'pfiSfs' utility.

Then ran 'FrugalPup' to install the "Pseudo Full Install" directory on a fat32 partition as a normal frugal install.
The result runs well in "pupmode=66", because the RW layer remains small.

The concept seems to work well, and I can see me using it, but can it be made "smooth" enough for "user-users"?

The other question is, should we be releasing Puppy with a single 'puppy_...sfs' as produced by this process?
If the various "sfs" files are there to enable "fiddlers" to swap them in and out, could "fiddlers" be convinced to use this process instead?

Note: The result of this process is still a fully functional normal frugal install, it's just that it has only 1 Puppy sfs file.

gyrog wrote: ↑Mon Jan 01, 2024 5:22 am

IThe other question is, should we be releasing Puppy with a single 'puppy_...sfs' as produced by this process?
If the various "sfs" files are there to enable "fiddlers" to swap them in and out, could "fiddlers" be convinced to use this process instead?

Note: The result of this process is still a fully functional normal frugal install, it's just that it has only 1 Puppy sfs file.

From your most recent test, it seems that you are including the firmware in the puppy.sfs. If your arrangement could be tweaked like KL so that the firmware and modules are separate sfs layers, then this would still allow the flexibility to swap kernels and/or firmware in and out of the install, which is how KL is arranged and has proved handy for me as recently as two days ago, when a very recent release of KLV-airedale contained firmware that didn't play with my machine.

For a personalized tweaked file system, including everything inside one sfs could be convenient, but for those doing a fresh boot and testing on specific machines, it would probably be best to keep the modularized layers and have the Psuedo Full Install only contain the "puppy.sfs".

Whether these methods will be for the "user-user" is tricky, because it does take a good base of knowledge to understand what's being done here, but it's certainly advantageous for an advanced user of pup OS's like myself. I'm not a coder, but have a long history with puppies and can make use of these techniques.

@gyrog I agree with @geo_c that keeping this type of Puppy modular for the kernel components (zdrv, fdrv, vmlinuz) is an important part of the features.

Also running the other SFS files as uncompressed directories would be very interesting as well. In KL we can boot and run a system with all the SFS files uncompressed. Any directory with a 2 digit prefix (00modules, 01firmwate, 07rootfs, 16gtkdialog-filemnt) will be loaded into the merged file system. Any SFS file with the 2 digit prefix will be loaded at boot into the merged file system. From 0 - 99 can be used. One can mix the 2 file system structures with some SFS and some uncompressed.

Using the PFI mode one can read and write to the uncompressed components directly making modifications and customization with immediate effects on a running system. Really great for experimentation and testing. Later one can then squash any of those directories again for the read-only advantage.

So if we can run Puppy Linux in a PFI mode and leave the kernel components unaltered or choose to include them on demand we would be in some pretty cool territory as far as very advanced "frugal installation" goes.

Other than FatDog I don't think many OS's can do this.

I was thinking suddenly big and am wondering how cool it would be to have a feature like KL-multi actually built into one of the Puppy Linux installer scripts.

If the KL-multi concept also works for Puppy Linux (I think it will) and it can be easily setup/managed from a GUI....... we'd be on the way to Mars while everyone else is going to the Moon.

I know some people think it is less important than I do, but I think you need a way to keep the stuff that's hooked up to the package manager separate from the stuff that isn't, or at least keep track of what is being upgraded automatically and what isn't.

rockedge wrote: ↑Mon Jan 01, 2024 4:00 pm

I was thinking suddenly big and am wondering how cool it would be to have a feature like KL-multi actually built into one of the Puppy Linux installer scripts.

If the KL-multi concept also works for Puppy Linux (I think it will)

KL-multi does work fine with standard Puppy per this link: viewtopic.php?p=99318#p99318

Including that functionality in any installer would be fantastic of course since it opens up usage power most people wouldn't think of or realise how useful it is - also it is huge extra power with pretty much no cost at all in terms of resource usage.

dancytron wrote: ↑Mon Jan 01, 2024 10:29 pm

I know some people think it is less important than I do, but I think you need a way to keep the stuff that's hooked up to the package manager separate from the stuff that isn't, or at least keep track of what is being upgraded automatically and what isn't.

If you're referring to the Psuedo-Full Install technique, it shouldn't change the package manager database as far as my experience goes. Now if we're talking about adding extra layers and removing them, that does come into play.

I have frugally installed to HDD 4 separate F96-CE_4 fully functional systems using KL_muti script. I am using Grub4Dos so I copied an already existing boot stanza then modified the directory names.

Results in /mnt/home/Testpup/F96-CE_4 after running KL_multi

A look at /mnt/home/Testpup/F96-CE_4/instance0 which is the main base frugal installation which is 538 M->

Inside /mnt/home/Testpup/F96-CE_4/instance0 with a size of 1907 B

geo_c wrote: ↑Mon Jan 01, 2024 2:23 pm

From your most recent test, it seems that you are including the firmware in the puppy.sfs. If your arrangement could be tweaked like KL so that the firmware and modules are separate sfs layers, then this would still allow the flexibility to swap kernels and/or firmware in and out of the install, which is how KL is arranged and has proved handy for me as recently as two days ago, when a very recent release of KLV-airedale contained firmware that didn't play with my machine.

I'm not buying it.
To my mind a "Frugal Full Install" effectively has no layers, that's the point, there never is, and never can be, any whiteout files, no matter what you do. What I'm trying to do is have the only difference in function between a real "Full" install and a "Frugal Full" install as the latter using only a directory, rather than a partition.

For 'pfiSfs' to separate the "Frugal Full Install" into a number of sfs files, just complicates it, a lot.
It muddies the waters of a "Sort it out in the 'Frugal Full Install' and then generate a corresponding frugal 'puppy_...sfs'" concept.

As to testing firmware or kernels in the frugal install, you can still apply kernel sfs files, just add them to the stack above the 'puppy_...sfs' file. Then when you've got it sorted, go back and do it "right".

Updating the kernel in a "Frugal Full Install":

Experiment 1:
Run a few Puppies with the "fdrv" and the "zdrv" at the top of the stack instead of at the bottom.
This worked fine.
I suspect that they are position agnostic because their contents are unique; position in the stack only matters when 2 layers contain files with the same path/name.

Experiment 2:
Emulate experiment 1 while updating the kernel in my Bookworm64 "pfi" install.
unsquashfs 'kernel-modules-6.1.69-kernel-kit.sfs' into 'dpupbw64files'.
unsquashfs 'fdrv-6.1.69-kernel-kit.sfs' into 'dpupbw64files'.
unsquashfs 'kbuild-6.1.69.sfs' into 'dpupbw64files'.
replace 'vmlinuz' with 'vmlinuz-6.1.69-kernel-kit'.

Cleanup 'dpupbw64files':

rm dpupbw64files/usr/lib/modules/6.1.67
rm dpupbw64files/usr/src/kbuild-6.1.67
rm dpupbw64files/etc/modules/*6.1.67*

Remove un-needed files from 'dpupbw64files/usr/lib/firmware/'

Boot the "pfi" install.

run 'pfiSfs' to create a new 'puppy_dpupbw64_10.0.4.sfs'.
Replace the 'puppy_dpupbw64_10.0.4.sfs' in my frugal install with the new one.
Replace the 'vmlinuz' in my frugal install with the new one.

Boot the frugal install.

All this works fine for me.
The only part that would not be implemented in a "kernelKit2pffi' utility is the purge of the firmware, which is peculiar to my computer.
So why not use this thing for kernel changes??