KLP_firstribit.sh script to use Puppy with FR initrd

[wiak]

To allow focused work/discussion on it, moved script exemplar here from rockedge KLP discussion thread: viewtopic.php?p=97175#p97175
Simplified the originally posted script:
CHANGES 28Aug2023: Removed some old weedogit code that wasn't necessary for this variant.

Attached single build script. It auto downloads the relevant Fossa Puppy iso and completely builds the system and includes save2flash (w_changes=RAM2) capability and tells you exactly what to put in your grub stanza including the w_00modules=lib argument - just copy and paste that into your grub config...

Remember to click Puppy StartMenu > FixMenus once in to get the wd_save2flash icon under StartMenu > Systems

Of course old Puppy remaster utilities are useless here since not for FR initrd overlayfs facilities. Instead use KL/FR utilities and enjoy FR up to 99 addon 2-digit-numbered layers (which can be compressed sfs or normal uncompressed directories).

Old Fossapup64 build is also included. I was too lazy to try it, but unless I made a coding mistake in its build section it should also work fine since used to work via previous old weedogit script.

As I said above, ignore the X not shutdown cleanly junk - fixing that message just needs new shutdown routine relevant to FR initrd operation. For now just employing ultra-simply text-based shutdown generated by ultra-basic /usr/local/bin/wd_exit script.

Attached image is booted Fossa64-Mid, which booted fine but didn't supply enough firmware to connect on my quite modern HP system, but that's a small easy matter to fix. I made the attached image via Fossa64-Mid mtpaint snapshot and then used save2flash so could fetch it later on my Linux Mint system from the KLP upper_changes/root folder... Had it provided sufficient firmware could have posted the image straight from Fossa64-Mid of course.

After removing the dummy tar and making the script executable with chmod +x simply put the script in an empty build directory of your choice (on Linux formatted partition) such as /KLP_whatever and build the immediately bootable system via command:

Code: Select all

./KLP_firstribit-latest.sh

At the end of the build, as I said, the script outputs exact working grub stanzas that can boot it. I recommend using the last of the provided stanzas (the one for grub2 using the UUID it provides. Once you've added that to your grub configuration, simply reboot and try it. Yeah, needs work to make more FR/KL compatible, but not a lot really. Internet connection should work fine as long as the Puppy iso has sufficient modules/firmware to meet your system needs.

FORGOT: If you already have a copy of the relevant iso, and put it in the build directory it will be used without re-downloading. Saves a lot of time... BUT... NOTE WELL the name of the iso must be kept identical to that given in the script (per script lines 17, 18, and 19):
1. F96-CE_4.iso
2. fossapup64-9.5.iso
or
3. fossapup64-9.5-mid-2.iso

You can change say URL02 if you want to attempt to FirstRib/KL some other Puppy iso. No guarantees with others though since depends how parts are arranged in them and recent Vdpups seem to have included code that makes them very far from generic root filesystems (even more tightly tied in to Puppy's own initrd and related distro spec config files/modes and so on) so moving away from being easily firstribbed... Not worth bothering with these later ones in that case - better then to use actual KL designs or variants of mainstream provided root filesystems that also work straight away with the magic FR initrd. Anyway, I don't consider these demonstrations important - just for fun and purely for experimenters who want to play with Puppy filesystem but in KL/FR flexible compressed or uncompressed 99 numbered layer overlayfs frugal installs.

CHANGES 28Aug2023: Removed some old weedogit code that wasn't necessary for this variant.

[rockedge]

I ran a build successfully with the previous build script and have it booted in QEMU and running nicely. The build was a little noisy with warnings but finished with a working distro. Using layers of SFS's for testing out the ability to have lots of modular pieces tacked on to the base system. Testing in QEMU and most everything seems to work. Devx loaded as a layer.

Screenshot(69).jpg (20.67 KiB) Viewed 903 times

Going in for round 2 with this build script version...and it has cleanly built a system that is in a frugal directory.

Screenshot(70).jpg (42.09 KiB) Viewed 895 times

[rockedge]

I have Zoneminder running on a QEMU virtual machine running KLP-fossa64. Installed with 2 scripts I made for installing Zoneminder into Fossapup64-9.5 and both scripts have proven to work well. Some small adjustments need to be made on the 2nd script to ensure that an added php7.4-intl gets installed and configured.

Screenshot(77).jpg (27.84 KiB) Viewed 824 times

Screenshot(80).jpg (33.88 KiB) Viewed 823 times

[wiak]

you may notice that 09FR_fork_vdpup.sfs

That simple sfs addon was originally developed for use with old weedogit script for same procedure with older version of Vanilla Dpup; I did it at that time mainly because didn't like the vdpup limited functionality C-coded 'frugalify' script, which intenally nevertheless did use algorithm like in FR initrd to use multiple sfs addon files (via first converting the alphabetic pup sfs addons to numeric named format). But more recent Vanilla Dpups have some internal code that make them difficult to use with FR initrd.

If you look inside 09FR_fork_vdpup.sfs you will see it is very simple. Just sets a necessary PUPMODE variable so some internal puppy system scripts work, and also overwrite the Pup /usr/sbin/poweroff script with a, for now, via a very simple
(needing improved) shutdown/reboot script /usr/local/bin/wd_exit

If you 'really' want to use FR initrd to more perfectly boot those Pups that can still easily be booted with it, I suggest the best way to do that is not to alter the internals of FR initrd at all (which is designed to not be root filesystem origin specific) but rather to remove the 'Puppyisms' in Puppy's own system control scripts. After all what Puppy really is is a simple mainly single (root) user system that uses a very simplistic sysVinit structure - basically just using /bin/busybox init which per usual sysVinit practice then looks in /etc/inittab to see what script to run next. Puppy doesn't bother about sysVinit complicated run-levels but, via inittab first runs script /etc/rc.d/rc.sysinit, which thereafter runs /etc/profile script, and so on...

Once that part is done, per /etc/inittab, Puppy then calls the very Puppy-specific /bin/plogin script and so on and so forth till X desktop is up and running.

So the problem/work-required overall is that of either providing workaround scripts to overwrite Puppy scripts, or much much better to create new versions of the Puppy scripts themselves that do not have Puppyisms inside them. In the likes of 09FR_fork_vdpup.sfs, these alternative Puppy system scripts are put in higher layer than puppy sfs to overwrite the old ones

For example, many existing Puppy system scripts refer to possibly Puppy's own initrd-generated special mounts/locations such as "/initrd${PUP_HOME}" or "/initrd/pup_rw/". That means that unlike most mainstream available root filesystems, that of Puppy is tightly tied to Puppy's own initrd, which means the rootfs isn't very usable in a generic sort of way by the generic-capable FR initrd as it stands. It is kind of like the programming issue where data processing is not kept separate from the user interface or GUI code - Puppy rootfs is tightly integrated with its initrd so not very open to modularisation really.

The way out of that is not to thus make a special version of FR initrd that 'talks' in a more integrated way to the Puppy rootfs expectations - that would simply be another not very generic/modular initrd and specific only for booting Puppy. Better is to remove all Puppyisms from Puppy shell scripts (if possible) such that Puppy root filesystem becomes 'friendly' to being booted by alternative initrd schemes. It is amazing really that older Pups actually can, in the current circumstances, be booted by FR initrd, but as time goes on, Puppy scripts seem to becoming more tightly integrated with Puppy own initrd (mount point naming conventions, distrospecs, Pupmodes, and so on), and for some reason or another becoming difficult to boot at all using FR initrd. FirstRib's initrd, on the otherhand does not require the root filesystem used to know anything about the mount points and so on provided by FR initrd; user scripts for the likes of doing save2flash do, but not the core init system scripts, which is why FR initrd can boot so many mainstream root filesystems so perfectly; just not Puppy... well, not perfectly without a lot of patching/workarounds.

Of course, this KLP/firstribit is just a hobby experiment/demo for fun, and not important; traditional Puppy works as it is, via its own Puppy initrd with its adrv, fdrv, zdrv, puppy, ydrv and so on - best to just live with its own tightly integrated initrd/rootfs design probably, though certainly would have been nice if, like mainstream root filesystems, it happily accepted alternative generic initrd layering systems to boot it. But easier just to build small frugally installable FR-based KL distros, which can be smaller and more functional than pretty much any other distro if you so wish.

I don't myself therefore see any future for KLP distro-type constructions or any need for them, but maybe I'm wrong about that; certainly could (and can) be done.

[rockedge]

@wiak I feel the same way. The logical approach would be removing puppyisms rather than create work-around hacks to bypass the tight integration. I was experimenting as well on finding the right PUPSTATE configuration, declaring overlayfs instead of aufs and it became clear that removing all these flags and variables that are very Puppy Linux specific is the proper way to go.

My "big" test is the Zoneminder installation and the levels of difficulty of getting it running smoothly and how much manual vs. automatic installation procedures played a role.

As I said earlier, KLP is pure proof of concept and experimental operating system. A good way of discovering the Linux operating systems inner workings so to say. What could be attractive is the amount of useful tools and utilities jammed into the Puppy Linux rootfs.

Next I will test for possible integration into KLV-Spectr pup-volume-monitor so I will be returning to that project. Although it is fun playing around with KLP and does point to a possible fork in the road in the future, for now there probably is very little interest in making it a project.

[dimkr]

These Puppy-isms make Puppy hard to maintain and introduce various kinds of incompatibility. Many are gone in the simplified fork of woof-CE I'm working on, https://github.com/vanilla-dpup/woof-CE ... pup-11.0.x. Userspace is Debian installed using debootstrap plus some packages compiled from source, the kernel is a recompiled Debian kernel, and initrd is very different (less boot codes, auto-loads SFSs in deterministic order) but backward-compatible with Puppy in most use cases.

Puppy files that may override the parent distro files (things like /sbin/poweroff) are moved to /usr/local (PATH prefers them so no need to replace system files). Also, init is not replaced with wrappers around busybox init: instead, initrd runs /usr/local/sbin/init (https://github.com/vanilla-dpup/woof-CE ... nit/init.c) and not /sbin/init, which can be systemd, sysvinit or anything else.

If you boot with another initrd that runs /sbin/init, it should mostly behave like a normal Debian system, but you'll need to implement auto-login somehow, and tools like save2flash expect the Puppy mount point structure, things like /initrd/pup_rw.

If you're interested in trying this out as a base for "KLP" instead of a "traditional" Puppy, you can find prebuilt builds in:

https://github.com/dimkr/darls/releases
https://github.com/vanilla-dpup/unstable/releases (slightly behind because build is currently broken due to Debian testing transitions in progress)

[rockedge]

Testing a KLP constructed with the rootfs of F96-CE_4 booted from a 4 G ScanDisk flash drive, frugally booted on a DELL VOSTRO 1500 with 10+ years of life living in a preschool classroom behind it. With a single core Celeron 540 CPU and an increase in RAM to 4 G, this laptop runs KLV-Airedale-sr2 and KLV-Spectr-beta2 surprisingly well but can struggle under the weight of many open tabs on any of the big browsers.

And KLP is running fairly well on it. There are some wobbly moments and a few things don't work at the moment but overall not too bad.

I took @dimkr's suggestion and assembled an ISO to boot with a stock skeleton initrd.gz. It is assembled as shown below:

Screenshot(81).jpg (29.01 KiB) Viewed 806 times

Which booted first try to a console but not much to do with it yet. Good indicator though on the speed it booted to a console for an idea on how it will run a graphical desktop.

Screenshot(83).jpg (65 KiB) Viewed 804 times

Screenshot(84).jpg (93.98 KiB) Viewed 804 times

[dimkr]

I took @dimkr's suggestion and assembled an ISO to boot with a stock skeleton initrd.gz. It is assembled as shown below:

Vanilla Dpup 10.0.x is still mostly a traditional Puppy, it's 11.0.x that's interesting for experimentation with FR. The latter is much closer to Debian and free from most of Puppy's quirks

(EDIT: DARLS uses 10.0.x version numbers although it's built using the 11.0.x build system and this can be confusing)