KLP concept testing

[rockedge]

Using rootfs from F96-CE_4 and re-squashed as 07firstrib_rootfs.sfs and attempting to boot a system built around it using the skeleton initrd.gz and the huge RT kernel

Getting to a console but problems starting the X11 server in these very early attempts. Though encouraged that it booted to a running console. Can't do much in QEMU but running the firstrib_rootfs in Xnest gets the JWM window manager and ROx pinboard going.

In QEMU virtual machine:

Screenshot(44).jpg (17.89 KiB) Viewed 738 times

using mount_chroot scripts and Xnest:

Screenshot(43).jpg (12.28 KiB) Viewed 733 times

[rockedge]

@wiak I did it. Booted a F96-CE_4 rootfs without ydrv.sfs using the full real time kernel 6.1.38-rt13 using the magic skeleton initrd.gz

system before making the ISO:

Screenshot(48).jpg (21.75 KiB) Viewed 724 times

QEMU virtual machine. Mouse is not responding though the keyboard seem to be recognized.
Update: to get the mouse to work on the QEMU command line add -usb -usbdevice tablet

Screenshot(47).jpg (23.3 KiB) Viewed 724 times

[geo_c]

Wow, I knew this was coming. If you can firstrib a pup, you can firstrib anything.

Next do Windows XP.

[rockedge]

Using this frugal directory to create a boot-able ISO using the puppy_fossapup64_9.6.sfs from F96-CE_4.

Can't get a network device to be recognized...yet

Screenshot(52).jpg (23.91 KiB) Viewed 704 times

This is with 03ydrv_fossapup64_9.6.sfs loading during boot cycle

Screenshot(50).jpg (24.63 KiB) Viewed 704 times

Screenshot(53).jpg (32.99 KiB) Viewed 697 times

[geo_c]

So you're running fossapup, but rather than using a savefile, instead it's dogged with upper_changes.

And because of that, the alphabet drv method is not necessary? Now there can be 99 layers.

[rockedge]

So you're running fossapup, but rather than using a savefile, instead it's dogged with upper_changes.

And because of that, the alphabet drv method is not necessary? Now there can be 99 layers.

Yes. Exactly.

System is according to htop using at the moment 140 M of RAM

If any one wants to test KLP-fossa it would be helpful with reports on if the network device is detected and the system can connect to a LAN
It's here -> KLP-Fossapup64.iso 726 M

Remember this system is totally experimental and a proof of concept. Use it at your own risk

[rockedge]

For a further test I added 3 extra SFS packages prepared for KLV-Airedale and KLV-Spectr and runs well it seems in KLP-fossa-RT (protosys-B)
But still no eth0 or any network device is being detected

Screenshot(56).jpg (31.28 KiB) Viewed 684 times

Screenshot(54).jpg (41.12 KiB) Viewed 684 times

Another problem has become apparent, I can't shutdown the system! It will write to the save file/save folder but cycles back to a console prompt.

Needed to run fixmenus upon first system boot to add the SFS packages to the menus

[rockedge]

This time went a step further and added in @wiak's addon APT SFS for Fossapup64 and the special adrv_fossapup64_9.5.sfs that accompanies it:

The frugal file system:

Screenshot(59).jpg (34.28 KiB) Viewed 660 times

and what KLP-RT looks like running on a QEMU virtual machine:

Screenshot(61).jpg (30.78 KiB) Viewed 660 times

I feel like Fossa64-Mid and Fossa64-Less might be good candidates for type of modular Lego like assembly. Using layers of SFS files that make advanced systems by adding just the package / program groups that are needed for a particular set up.

All three package managers display version:

Screenshot(64).jpg (43.94 KiB) Viewed 654 times

Still trouble with discovery of the network device(s)

[rockedge]

@geo_c The pseudo full install (from now on and moving forward known as, PFI mode), will work the same way with KLP as it does in the other KL's. So remastering is complete and precise in easy steps working on an uncompressed rootfs in /upper_changes

I took a save folder called fossapup64save-A from a current F96-CE_4 and squashed it to 20fossapup64save-A.sfs and added in the file to the KLP-RT file system.

Booted up and it worked. There are a few things that might be wobbly....further testing needed!

For sure it will take a tweak or 2 to polish a KLP-fossa-RT into something useful.

[rockedge]

Still no network device like eth0 being recognized:

Screenshot(65).jpg (25.63 KiB) Viewed 637 times

[wiak]

I had a quick look in sfs of that fossapup version you are using. Notice /tmp is a symlink, which is not how I remember it.
Check using lsmod if whatever/any eth module required is loaded maybe? Old weedogit had conversion for Vanilla Dpup, and fudge method to make shutdown work that I commented could do with improvement. I don't believe weedogit would work right now cos various url's of needed FR files have changed. Was changed to firstribit, but I never finished that, but will sometime.

From weedogit previous:
# The following are needed for "KL_anypup (e.g. KL_fossapup)" experimental weedogged builds
# Change Puppy iso URL01 and subdirectory01 name to suit Puppy being weedogged
# For example, could use the following two lines for building WDL fossapup:
## URL01="https://distro.ibiblio.org/puppylinux/p ... 64-9.5.iso"
## distro01="WeeDog'd fossapup (experimental)"; subdirectory01="KL_fossapup64"; mvpoweroff=true # since fossa stores poweroff in /sbin not in /usr/sbin
# But default Pup is Vdpup64, with auto URL detect (in case statement 01)

[wiak]

I've made it via a modified mini-firstribit script

Also works with old Fossapup64 (slightly easier and pretty much as done in old weedogit script) and probably therefore Fossa64-Mid and so on...

I'll post the mini-firstribit soon script, once I've made minor modes to it and tested other Fossa's so you can try the build it makes.

Note that I don't have ethernet cable so posting with it right now via wifi. I am sure ethernet would be working though. The key is to use the zdrv module provided by Fossapup and renaming it to 00zdrv and fdrv to 01fdrv as you do, but long time back I added special functionality to FR initrd to sort out the arrangement usrlib or simply lib so what you are probably missing in your attempts is the extra grub kernel line parameter:

Code: Select all

w_00modules=lib

since fossapup stored modules in /lib and not in /usr/lib

With that in place you get all the correct modules and firmware loaded so ethernet should work like my wifi does. My firstribit implementation (as in old weedogit) also includes a simplistic shutdown/restart utility, but that could easily be improved. Most all else working fine apparently.

[wiak]

I included a small 20KL_save2flash.sfs addon so w_changes=RAM2 also works (you'll need to take Puppy Menu choice Fixmenus to get the wd_save2flash desktop icon to appear under System start menu). Seems to work fine - even successfully saved my wifi configs.

Only tried with F96-CE thus far. About to try the Fossa64-Mid release shortly. I expect that will work and w_changes modes all work with that too.

One thing to realize of course is that many many of the provided Puppy utils won't work because they are written usually for aufs maybe or rely on various Puppy specs likes Pupmodes or Distrospec or all that other stuff which is irrelevant to FirstRib initrd operation. The layering is totally different and not just cos always overlayfs, but also no alphabetic layers, but instead tons of usable addon layers up to 99...

I'll post the KLP_firstribit script after final tests. Oh, Puppy complains... sigh... says X not shut down correctly. Just ignore that; the reason is we would have to write some shutdown routine to avoid that error since system isn't using Puppy shutdown mechanism at all since that would also involve Puppy-type layering and modes and so on rather than FR initrd modes, so doesn't apply and would some work to polish the result... But system works fine aside from such quirks.

Now, please understand, as far as I am concerned this is just a fun experiment. I see no point to it. Puppy, unlike most all other distros out their has underneath system files that rely on Pupmodes, Distrospecs and other pieces of code such that it isn't ever designed to be supplemented by the likes of FR initrd. Most other distros are very generic in operation and work perfectly with component parts from each other - Puppy doesn't have that share parts flexibility... I thus do not consider this project worth much, and I believe some more recent Pups already contain code that makes them even less compatible for running with FR initrd to the extent it may already be so difficult to achieve it is not worth trying.

[wiak]

To allow focused work/discussion on it, moved KLP_firstribit.sh script exemplar to own thread at: viewtopic.php?p=97340#p97340
Simplified the originally posted script:
CHANGES 28Aug2023: Removed some old weedogit code that wasn't necessary for this variant.