Puppy Linux Discussion Forum

I tried to weedog-boot debian and bunsenlabs. Both failed. For debian, I used the file system of a full-installed debian 10. I don't know whether it was correct to use a full install, so I switched to Bunsenlabs, using the live ISO's squash file instead. I'll lay out the steps with Bunsenlabs ISO, in case some steps were missing:

1. Download wiak's get_WDLskelinitrd400rc1.sh to get initrd_v400rc1.gz & modify_initrd_gz.sh.
2. Run in terminal:

./modify_initrd_gz.sh initrd_v400rc1.gz

3. Open bunsenlabs iso, find /live/filesystem.squashfs, then open filesystem.squashfs, and copy /usr/lib/modules to the decompressed initrd_v400rc1 folder, to overwrite its empty /usr/lib/modules folder.
4. Type exit and hit Return in the terminal from step 2, which generates a new initrd.gz. I rename it to initrd-modules.gz.
5. Find a usb installed with fossapup64, make a directory named weedog-bunsenlabs, copy needed files in there, shown in the below pic. Note that 01filesystem.sfs is copied from bunsenlabs iso. I think it is the only sfs file in the iso.

6. Edit grub.cfg in the puppy usb:

menuentry 'weedog-bunsenlabs' {
	search --no-floppy --fs-uuid --set=root 1F3E-3399
	echo	'loading Linux'
	linux	/weedog-bunsenlabs/vmlinuz-4.19.0-17-amd64 w_bootfrom=UUID=1F3E-3399=/weedog-bunsenlabs
	echo	'loading init'
	initrd	/weedog-bunsenlabs/initrd-modules.gz
}

7. Tried to boot, but got this:

miltonx wrote: Wed Sep 08, 2021 4:22 am

I tried to weedog-boot debian and bunsenlabs. Both failed.

Couldn't at a glance see anything wrong with what you did, though would need more info to see what went wrong.

The boot is failing at the switch_root to 08firstrib_rootfs.sfs stage, which suggests that 01filesystem.sfs has for some reason not been found and mounted earlier in the boot process.

Are you sure that is the correct UUID for the boot device? Is it a Linux-compatible boot partition filesystem (such as ext2 or ext4 for example)?

Could you post result of:

blkid

I believe both the full-install and the bunsen labs sfs-based cases should be able to make working with WDL initrd. If you post the link to the bunsenlabs iso used I may try it later.

wiak wrote: Wed Sep 08, 2021 4:28 am

The boot is failing at the switch_root to 08firstrib_rootfs.sfs stage, which suggests that 08filesystem.sfs has for some reason not been found and mounted earlier in the boot process.

Are you sure that is the correct UUID for the boot device?

Could you post result of:

Code: Select all

blkid

The uuid is correct. Sdb1 is the only usb plugged in the machine. Sdb1 is fat32. It serves as the EFI partition as well as a place to contain multiple puppy boot folders.

blkid /dev/sdb1
/dev/sdb1: LABEL_FATBOOT="VARIOUS" LABEL="VARIOUS" UUID="1F3E-3399" TYPE="vfat" PARTUUID="b150c244-01"

This usb has multiple frugal systems. Others boot Ok. See the grub.cfg. Puppy boot menu has the same uuid, although in its boot options I used lable name instead of uuid.

menuentry "Puppy fossapup64 9.5" {
    insmod fat
    search --no-floppy --fs-uuid --set  1F3E-3399
    echo "Loading vmlinuz"
    linux /fossapup64_9.5/vmlinuz pmedia=usbflash pdrv=VARIOUS psubdir=/fossapup64_9.5 pfix=fsck,fsckp TZ=CST-8
    echo "Loading initrd.gz"
    initrd /fossapup64_9.5/initrd.gz
}

menuentry 'weedog-bunsenlabs' {
	search --no-floppy --fs-uuid --set=root 1F3E-3399
	echo	'loading Linux'
	linux	/weedog-bunsenlabs/vmlinuz-4.19.0-17-amd64 w_bootfrom=UUID=1F3E-3399=/weedog-bunsenlabs
	echo	'loading init'
	initrd	/weedog-bunsenlabs/initrd-modules.gz
}

wiak wrote: Wed Sep 08, 2021 4:28 am

I believe both the full-install and the bunsen labs sfs-based cases should be able to make working with WDL initrd. If you post the link to the bunsenlabs iso used I may try it later.

This bunsenlabs download links is: https://ddl.bunsenlabs.org/ddl/lithium- ... hybrid.iso
Found on this page: https://www.bunsenlabs.org/installation.html

miltonx wrote: Wed Sep 08, 2021 4:43 am

wiak wrote: Wed Sep 08, 2021 4:28 am

I believe both the full-install and the bunsen labs sfs-based cases should be able to make working with WDL initrd. If you post the link to the bunsenlabs iso used I may try it later.

This bunsenlabs download links is: https://ddl.bunsenlabs.org/ddl/lithium- ... hybrid.iso
Found on this page: https://www.bunsenlabs.org/installation.html

Okay, downloading lithium iso right now to see if works okay on my system. I've never used fat filesystem - that won't work with save folder persistence but can't see why it wouldn't generally work/boot and can have upper_changes held in RAM only anyway. Shouldn't be too difficult for me to find the issue, since been
there ("Kernel panic") before...

The very first 'large' distro filesystem I ever booted via generic WDL initrd was of a full-install Void Linux, by the way (a couple of years ago) - I simply moved the folder into suitable subfolder and named it 01firstrib_rootfs and so on (didn't bother to make it into a squashed filesystem).

EDIT: Unfortunately I have rural broadband only so will take a while to download the iso, though it isn't particularly big. Maybe have the answer within the hour.

wiak wrote: Wed Sep 08, 2021 4:47 am

The very first 'large' distro filesystem I ever booted via generic WDL initrd was of a full-install Void Linux, by the way (a couple of years ago) - I simply moved the folder into suitable subfolder and named it 01firstrib_rootfs and so on (didn't bother to make it into a squashed filesystem).

One of puppy and other frugal installs' major attractions to me is a squashed system that strongly cures file system break paranoia

Thanks for all the work, wiak!

Did you try with the insmod fat
in your grub.cfg entry (I see the Pups you use had that)?

wiak wrote: Wed Sep 08, 2021 5:17 am

Did you try with the insmod fat
in your grub.cfg entry (I see the Pups you use had that)?

Just tried it. Same result.

menuentry 'weedog-bunsenlabs insmod' {
    insmod fat
    search --no-floppy --fs-uuid --set  1F3E-3399
	echo	'loading Linux'
	linux	/weedog-bunsenlabs/vmlinuz w_bootfrom=UUID=1F3E-3399=/weedog-bunsenlabs
	echo	'loading init'
	initrd /weedog-bunsenlabs/initrd-modules.gz
}

All booted fine for me using pretty much the layout and filenames you have. However, that was on my ext4 hard disk, so haven't tried from a vfat formatted usb stick yet and, also, my old dev laptop here (HP Elitebook 2530p) boots via old grub4dos install so a menu.lst as here:

title weedog-bunsenlabs (but wasn't on a usb flash stick - will try later)
find --set-root uuid () b812c597-8099-4bee-9bb3-8b9c10f1e902
kernel /weedog-bunsenlabs/vmlinuz-4.19.0-17-amd64 w_bootfrom=UUID=b812c597-8099-4bee-9bb3-8b9c10f1e902=/weedog-bunsenlabs
initrd /weedog-bunsenlabs/initrd-modules.gz

I'd post the screenshot but I wasn't able to exactly log in on first boot because I hadn't visited bunsenlab site to see what the login user/password was. Will check that now.

I think unlikely to have issues with this nice bunsenlabs distro as long as you are sure you copied the modules subdirectory correctly to:
initrd-modules_decompressed/usr/lib/modules/4.19.0-17-amd64

... just read your last post.

I haven't a clue what is wrong thus far. But it all certainly works on ext4 boot here. Maybe a module needs loading for fat in the initrd - I will experiment with that and come report back about it. I may well have missed that since as I say I don't use fat installs.

Here is an added screenshot which was displayed very shortly before the one I attached in the starting post.
It was very fast, so this time I had to video shoot it and then get that screen .

Hmmm. It is finding 01filesystem.sfs okay. Not sure off the top of my head why the overlayfs merge is failing for you - again, could be that initrd isn't finding the overlay module so you'd have to check you have these modules inside the initrd in dir usr/lib/modules.

One other thing lets try putting changes folder in RAM (since won't work correctly on a fat filesystem anyway). To do that, put this at the end of your grub.cfg kernel line:

w_changes=RAM0

i.e.

linux	/weedog-bunsenlabs/vmlinuz w_bootfrom=UUID=1F3E-3399=/weedog-bunsenlabs w_changes=RAM0

EDIT: I'm just about to try booting from a vfat formatted usbstick, with option w_changes=RAM0

Booted without issue for me from vfat formatted usb stick (using w_changes=RAM0 at end of linux (kernel) line.

I still haven't figured out the login password though... I tried user/live

I might need to manually change password inside the 01filesystem.sfs if bunsenlab site doesn't enlighten me. This seems to be a very nice and straighforward case for WeeDogLinux initrd boot - only one sfs file so overlay is just that and the in RAM upper_changes folder. Suggests to me you haven't copied the modules correctly into the appropriate place in the initrd/usr/lib/modules/<kernel_version_number_subfolder>

If you have then it is a bit of a mystery since the root filesystem has nothing to do with overlayfs merge working at that stage of your boot process and clearly the boot directory is being found since your video screenshot shows layer 01 detected and mounted.

There is a debug facility that may work with this one. I'll guide you with that if all else fails for you. Meanwhile I have to find (or remake) the login user/password combination to actually login! I've looked inside the 01filesystem.sfs and there certainly is no login user called 'user' in /etc/passwd, so must be added in there differently during conventional boot. I will however be able to use a WDL script called mount_chroot-latest.sh (and its sister umount....) to add new user or change root passwd if I can't find alternative login combination. But your issue is different - first you need to be able to boot it!

Unfortunately, though I (or rockedge) can reasonably easily provide root user with a password, or add a new user, this is not going to be an easy case for someone new to this (not that it is too difficult, but some work involved). I can only imagine that the normal initrd/init of bunsenlabs linux also includes some portion that sets up the login user as user/live, but that is not unfortunately set up already in filesystem.squashfs itself, so we have to do it ourselves (via first unsquashing that file and then chroot into it) in order to login... so, no, that is not for beginner attempt really. I can't even try that myself at the moment because I do not have sufficient space left on my laptop to unsquash that file, and it has to be done on a Linux formatted partition. Then again, maybe I've just missed something simple - but I did look inside filesystem.squashfs and there is no user 'user' in /etc/passwd and bunsenlabs have not suggested any root user password to use.

I copied the weedog-bunsenlabs folder to sda3 (ext4 hard drive partition), and added a boot menu entry directing to that partition. Successfully booted to login screen. Neither did I manage to login with the "user" - "live" password.

Then I tried the w_changes=RAM0 option on the previous boot entry which directed to the usb partition (sdb1). This time the booting process went ahead and looked nice ... until it got stuck here:

[OK] Started User Manager for UID 108.
[OK] Started Session c1 of user lightdm.

Then the cursor kept flashing indefinitely without proceeding to the login GUI.

Note: the weedog-bunsenlabs folders on sda3 and sdb1 have identical contents.
However, sda is SSD and sdb is a slow 30mb/s flash. Not sure it that caused the failure to reach the login GUI?

I also tried the debian sfs, which was based on a full-install. Copeid the boot folder to sda3 (ssd ext4 partition). Added a boot menu entry directing there. Again failed just like the very beginning.

miltonx wrote: Wed Sep 08, 2021 7:06 am

I copied the weedog-bunsenlabs folder to sda3 (ext4 hard drive partition), and added a boot menu entry directing to that partition. Successfully booted to login screen. Neither did I manage to login with the "user" - "live" password.

Then I tried the w_changes=RAM0 option on the previous boot entry which directed to the usb partition (sdb1). This time the booting process went ahead and looked nice ... until it got stuck here:

Code: Select all

[OK] Started User Manager for UID 108.
[OK] Started Session c1 of user lightdm.

Then the cursor kept flashing indefinitely without proceeding to the login GUI.

Note: the weedog-bunsenlabs folders on sda3 and sdb1 have identical contents.
However, sda is SSD and sdb is a slow 30mb/s flash. Not sure it that caused the failure to reach the login GUI?

Okay, we won't bother with the full debian - that is too big a job. We'll concentrate on getting the passwd and using the hard disk version you have reached login prompt with (I have no idea why your usb hasn't booted to same stage successfully - should have on same system). I'll get back to you on how to do the passwd change for root (if it works in my test). Be prepared... there are a few steps invovled...

wiak wrote: Wed Sep 08, 2021 6:29 am

... I can't even try that myself at the moment because I do not have sufficient space left on my laptop to unsquash that file, and it has to be done on a Linux formatted partition. Then again, maybe I've just missed something simple - but I did look inside filesystem.squashfs and there is no user 'user' in /etc/passwd and bunsenlabs have not suggested any root user password to use.

You do not need to do that. It's too tedious and does not really add value since your focus is on the weedog init process that is meant to work for almost all distros rather than fixing a particular disto to fit weedog. There are so many distros and you never know what weird mechanisms they use on their live iso.

I guess the bunsenlabs live iso, when booted live, runs some script on the fly to add the user and password, rather than pre-configuring it in the squash file. That's why I much prefer to make a linux sfs from a full install, which has most basic configs done by myself before squashing it up.

So, why that full-installed debian sfs does not boot is an even more confusing mystery to me now.

wiak wrote: Wed Sep 08, 2021 7:23 am

... We'll concentrate on getting the passwd and using the hard disk version you have reached login prompt with (I have no idea why your usb hasn't booted to same stage successfully - should have on same system). I'll get back to you on how to do the passwd change for root (if it works in my test). Be prepared... there are a few steps invovled...

Wiak, it's very nice of you to offer that help. But with due repect, let me make clear that getting a particular bunsenlabs distro to work on WDL is not really interesting to me. Maybe the chroot and user adding how-to could be useful for other forum members, though.

I did all these experiments to find a generic frugal install tool just as you want WDL to be. But probably there are some more kinks to work out to make it truly agnostically effective. When it comes to full-install based squash files, it may also be complicated as full-install systems have all kinds of config / log / tmp files that could catch WDL on surprise and fail to boot. WDL is very interesting. I will keep following your progress and sincerely appreciate your work.

miltonx wrote: Wed Sep 08, 2021 7:38 am

wiak wrote: Wed Sep 08, 2021 7:23 am

... We'll concentrate on getting the passwd and using the hard disk version you have reached login prompt with (I have no idea why your usb hasn't booted to same stage successfully - should have on same system). I'll get back to you on how to do the passwd change for root (if it works in my test). Be prepared... there are a few steps invovled...

Wiak, it's very nice of you to offer that help. But with due repect, let me make clear that getting a particular bunsenlabs distro to work on WDL is not really interesting to me. Maybe the chroot and user adding how-to could be useful for other forum members, though.

I did all these experiments to find a generic frugal install tool just as you want WDL to be. But probably there are some more kinks to work out to make it truly agnostically effective. When it comes to full-install based squash files, it may also be complicated as full-install systems have all kinds of config / log / tmp files that could catch WDL on surprise and fail to boot. WDL is very interesting. I will keep following your progress and sincerely appreciate your work.

The issues are nothing to do with the WDL initrd milton. That much is generic and will boot either of these items you described. However, you do sometimes have to work with the underlying rootfilesystem - obviously if no user/password is automatically available there is no alternative but to create such, but again that's not anything to do with WDL initrd itself, which is the core overlayfs control system.

But yes, it is not probably worth doing this one right now. I have made it work for myself, and rockedge could also do this with ease since he is used to adding passwords into filesystems, but explaining it to a newuser - that takes a lot of time. So we'll leave it for now, but there will be posts again explaining such mods (been covered before but not well-documented, sorry).

As a teaser, in the meantime, here is a screenshot of the final result (after I set root:password via mount_chroot-latest.sh script to root:root.

At least we know it does work. So would full debian install by the way, but of course there is quite a bit prep work to do for that too.

That bunsenlabs distro contains tons of stuff in its small sfs by the way and I even managed to connect to wifi once I found where the weird connect app was! WDL save persistence also working fine with it so thanks for the heads up - I rather like the distro - it boots extremely fast.

I'm not myself trying to make WDL into a generic frugal install tool on purpose, by the way. It was however designed as a generic initrd, which it is and why, it is usually relatively easy to boot most distro root filesystems with it. Bunsenlabs case was not difficult - just needed that password to get in once booted. We have to set that even in WDL own rootfilesystem builds hence done these steps many times as has rockedge (specially when we forget to set passwords in initial build ...

Cheers, wiak

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

Whilst I won't write a clear howto set its password right now, because I'm short of time. I'll list the main steps briefly to remind those who have done this in the past:

1. unsquashfs the root-filesystem and rename the resulting squashed-root folder to firstrib_rootfs (must be in a Linux formatted partition)

2. Run the WDL script:

./mount_chroot-latest.sh

That auto-chroots into the filesystem. You can now run the command:

3. passwd root

and give root a password (I usually just enter root as the password).

4. Type exit, to enter out of the chroot back to previous terminal prompt.

5. Run the WDL script:

./umount_choort-latest.sh

That just cleans up the mounts involved in the step 2 chroot. You don't need to understand chroot to do any of this - script does it for you.

6. Finallly, re-squash the firstrib_rootfs/ directory using:

mksquashfs firstrib_rootfs/ 08firstrib_rootfs.sfs

or whatever you want to call the numbered sfs, and you are ready to go!!!

NOTE that in WDL you don't even need to turn it back into a squashed filesystem if you like leaving it more accessible. Simply rename the firstrib_rootfs uncompressed directory to, say, 08firstrib_rootfs/

cheers, wiak

wiak wrote: Wed Sep 08, 2021 8:20 am

Whilst I won't write a clear howto set its password right now, because I'm short of time. I'll list the main steps briefly to remind those who have done this in the past:
...

This is detailed enough, and the attached mount/umount_chroot tools are very handy, not only for this particular case but also for future tinkering elsewhere. I eagerly saved it.

Since this thread has helped me figure out the weedog-bunsenlabs process and I was strongly curious about how to make it work, now it being solved, I will no longer fiddle with bunsenlabs anymore, although I used to like this distro some time ago. But again, your detailed post is very helpful for me and others, and that's very nice.

And an update about the full-installed debian. My fault, I put a wrong modules folder in the initird. When I reexamined initrd, I noticed that modules size was too small. Redid it, and successfully booted. Both on ssd(ext4) and usb(fat32), the latter requiring the w_changes=RAM0 option.

By the way, is there any document about all the boot parameters?

wiak wrote: Wed Sep 08, 2021 8:06 am

I'm not myself trying to make WDL into a generic frugal install tool on purpose, by the way. It was however designed as a generic initrd, , which it is and why, it is usually relatively easy to boot most distro root filesystems with it.

Yeah, a generic initrd which boots most distros, as well as alllows a frugal install of most distros. That's what I meant.

Talking of initrd, I'm reminded of another curious idea. Since Puppy has pretty good modules to support most machines, can I just extract puppy's initrd modules and put it in the weedog initrd, so that I can use it for most distros, rather than reapeat the decompress-copy-recompress work for each distro I want to weedog-boot?

Edit:
I just tried expanding Fossapup64_9.5's initrd, and surprisingly, it doesn't contain modules! So puppy loads external modules when booting?

And then follows another question. For a weedog-someDistro, after copying that someDistro's modules into weedog's initrd, is it safe to remove those modules from the sfs file?

miltonx wrote: Wed Sep 08, 2021 9:28 am

Talking of initrd, I'm reminded of another curious idea. Since Puppy has pretty good modules to support most machines, can I just extract puppy's initrd modules and put it in the weedog initrd, so that I can use it for most distros, rather than reapeat the decompress-copy-recompress work for each distro I want to weedog-boot?

Edit:
I just tried expanding Fossapup64_9.5's initrd, and surprisingly, it doesn't contain modules! So puppy loads external modules when booting?

And then follows another question. For a weedog-someDistro, after copying that someDistro's modules into weedog's initrd, is it safe to remove those modules from the sfs file?

miltonx wrote: Wed Sep 08, 2021 9:28 am

Yeah, a generic initrd which boots most distros, as well as alllows a frugal install of most distros. That's what I meant.

And WDL initrd allows exactly that. It is impossible for it to be a simple push a button convert every distro to work solution of course! When I said I'm not really myself trying to publish a boot every distro solution via WDL - I am actually just designing a distro for my own family business needs and had to think very carefully indeed about publishing further because that involves far more work and I as I've said many a time I don't mind if anyone uses any part of it at all. But... rockedge was very encouraging from the very first (FirstRib) creation so I appreciate his work and support it via these releases - that's all really. Most of me wants to 'retire' from further computing - I prefer drinking coffee nowadays!

Re: your related modules questions:

Puppy Linux uses what is called a 'huge kernel' which has been specially compiled to include all the drivers needed to see the boot media and thus not need modules inserted into the initrd. Unfortunately, one exception to that is the overlayfs module, which is not typically built directly into Puppy linux kernel because, aside from some recent experimental ones, Puppy uses aufs as its layering method.

Problem with Puppy's approach, is that aufs is not official supported by Linux kernel developers so Puppy has to build specially patched kernels rather than just being able to use the official kernels from upstream repos such as Debian or Ubuntu. The other problem is that most upstream distros such as Ubuntu do not provide huge kernels. Instead their official repo kernels depend on module support from their initrd at boot time. In designing WeeDog I elected to use official kernel supported overlayfs and to use official upstream repo kernels rather than trust my various builds to self-compiled/patched kernels; WDL initrd thus typically needs modules to be inserted into it.

However, being a longterm member of Puppy forum, I added a special feature to WDL initrd that allows it to use modules provided in an external sfs module (such as is used in Puppy) along with the related Puppy kernel; that needed the solution however to Puppy huge kernel not including overlayfs internally so the WDL initrd can pick up that one extra module from a specially prepared 00module.sfs addon layer.

It is generally possible using that unique but rather odd arrangement (Puppy huge kernel and extracted modules sfs) with other distro's rootfilesystem. Rockedge has experimented with that more than I have (though I designed the code in initrd to allow it) and particularly in some of his WDL_Void. In other words he sometimes boots the Void Linux based firstrib_rootfs with a Puppy huge kernel and a 00modules.sfs extracted from the Puppy-distro's typical zdrv (or fdrv) sfs, which contains Puppy's modules.

The Puppy huge kernel only contains sufficient driver modules to boot but it still needs full module set provided in main layered filesystem. As I said these are usually stored in Puppy's zdrv and fdrv sfs files. You can't remove them no - they are needed to work with all the various bits of the computer's systems hardware.

Sorry I can't explain more for now. Very busy here, but others can likely help you if you want to try any of these things later.

wiak

I found out experimenting with running WeeDog-Void in a chroot'ed environment hosted by Puppy Linux (using wiak's mount / umount scripts) that it ran very well sharing the Puppy Linux kernels. So early on I was using a Puppy Linux's huge kernel a lot with the first versions of the WeeDog-Void desktop before using the Void Linux kernels. It is not too complicated to do this when using the script wiak provided that converted the zdrv.sfs squash file into the proper form and once the kernel module file is ready and numbered and named just copied in the vmlinuz that matches the zdrv.sfs.

At some point I had a Firstrib system using both AUFS and overlay but I can't seem to locate it now as I type this.

I noticed that in Wiak's initrd, the /lib directory is a link to /usr/lib, in which resides the modules directory. But in some distros, /lib is a regular directory instead of a link, and modules is right in /lib instead of /usr/lib/. In this case , do I need to modify the initrd file structure by deleting the /lib link and make a regular /lib folder and copy modules in there?

@miltonx Yes I think that will work. In Void Linux /lib is a symlink to /usr/lib as well.

miltonx wrote: Thu Sep 09, 2021 2:52 am

I noticed that in Wiak's initrd, the /lib directory is a link to /usr/lib, in which resides the modules directory. But in some distros, /lib is a regular directory instead of a link, and modules is right in /lib instead of /usr/lib/. In this case , do I need to modify the initrd file structure by deleting the /lib link and make a regular /lib folder and copy modules in there?

Sorry, missed your post milton.

The answer is that you should NOT modify the WDL initrd structure, which is indeed based on Void Linux, but that doesn't matter. If you are copying modules from any distro rootfilesystem into the initrd they should ALWAYS be put in initrd location /usr/lib/modules. It doesn't matter that the main distro sometimes (distro-dependent) stores them in its /lib/modules directory - after the intrd does its switch_root to the main distro rootfilesystem that rootfilesystem's modules will be correctly found by the system files of that rootfilesystem so you don't need to worry about that. Repeat: Do not modify the initrd structure (do not modify the main distro rootfilesystem structure either); any modules you copy from wherever they are in the main distro rootfilesystem into the WDL initrd should always be put in WDL initrd /usr/lib/modules location.

NOTE: that it is a different matter if you are NOT copying modules into WDL initrd, but instead using an external 00modules.sfs file (which can only be used when the kernel being used is a huge kernel, meaning that the kernel itself has all the disk drivers needed to find the boot files actually compiled into it) - in that case the 00modules.sfs file is best arranged to have the modules inside its /lib/module location (remember I am talking here about a special 00modules.sfs addon rather than about WDL intird itself. You still should not change WDL initrd structure). The reason for that special 00modules.sfs situation is that it was designed specifically for anyone wanting to use Puppy zdrv for modules and, traditionally, most, perhaps all, Puppy systems stored their modules in /lib/modules hence the internal code of recent WDL initrd is written to account for that difference but without changing WDL intird's own internal structure (for older WDL initrd it used to be necessary to use zdrv_convert to fix things, but that is not needed for modules conversions any longer, though turns out to be useful for firmware, but that's another matter discussed elsewhere). I suspect Debian will later move to using /usr/lib/modules arrangement (like Arch Linux and Void Linux) too, in which case Puppy is likely to follow that lead, and if so I'll tweak the operation of WDL initrd such that 00modules.sfs still works without conversion with Puppy zdrv addon). However, milton's question does not involve using Puppy modules in 00modules.sfs so the first paragraph above is the answer to that question.

wiak

After reading the post again, I will say I agree with wiak.

Thanks for the detailed explanation, Wiak. Good to know that the structure of initrd is not supposed to change. It saves a lot of extra work.