Duprate wrote: Mon Feb 01, 2021 9:46 pm
Hello, Fred! A question: Since the DebianDog initrd is based on the Porteus initrd, why is there a need to have /lib/modules/5.xx.x the kernel modules if this folder is already inside the 02-kernel-5 module. xx.x.squashfs? I noticed that in the Porteus initrd there isn't, being much smaller. Does Debian require this? 
Hi Duprate, not sure, but I think your question is why the porteus-boot initrd1.xz from DebianDog is so much bigger than the initrd.xz from official Porteus distro (tell me if I understood wrong).
Well, my knowledge is limited about these things, but I think the initrd.xz from official Porteus has much more builtin modules, just enough to start booting (e.g. find devices, load squashfs, aufs or overlay etc...)
For info, what I do mostly:
Basically I use nowadays "mkinitramfs" to built initrd1.xz from Debian stock kernel, e.g.
Code: Select all
mkinitramfs -k -o /dev/null 5.10.0-1-amd64
("-o /dev/null" makes it only create the directory in /var/tmp, no initrd)
Then from /var/tmp/mkinitramfs_* I copy the contents of lib/modules to the porteus-boot skeleton and compress it.
Can be configured in '/etc/initramfs-tools/initramfs.conf', default is MODULES=most and I kept that.
In the past I've experimented with other methods than mkinitramfs and got a much smaller initrd1.xz (5M), it booted fine with several hardware but not all, (Bill did some tests back then, I have little hardware to test on) So it seemed best to me to use mkinitramfs (with MODULES=most) to be on the safe side (at the cost of a bigger ISO).
Hopefully this answers your question.
Fred