On 16/03/2025 20:13, Ben Hutchings wrote:
Control: tag -1 moreinfo unreproducible On Sat, 2025-03-08 at 12:29 +0100, Eric Valette wrote:On Fri, 7 Mar 2025 20:43:08 +0100 Marc Haber <mh+debian-bugs@zugschlus.de> wrote:On Fri, Mar 07, 2025 at 05:44:00PM +0100, Eric Valette wrote:CONFIG_MODULE_DECOMPRESS=ySo the culprit is there. It is not set in my own kernel build (never been so far although config has been created via the official linux-source-6.6) and thus I cannot load compressed modules without user space helpers that probably not exist in initrd busybox version. Of course I can load compressed modules once the pivot_root/switch_root is done.The initramfs is supposed to use modprobe etc. from kmod, not from busybox. So there should be no difference in capabilities from the main Debian system.
But the main system was able to laod compressed modules while the initrd fs was not.
Just ebanbling the CONFIG_MODULE_DECOMPRESS=y made the problem vanish so its shows somehow the module laoder was unable to decompress the modules.
Does your initramfs image include the right version of modprobe? Boot with "break=top" and run "modprobe --version" to check this.
It use wahever is put in. I did not make any chnage.
A second bug is that the initrd does not seems to be compressed while config says it should be with zstd (and the CONFIG_RD_* is ok). I can change to xz.As explained, it is intentional that the modules are not recompressed, while other files are. We made a trade-off between size and speed (of mkinitramfs), and I don't intend to revisit that.
This is not my remark : why not completelly compressing the initrd? Size would be smaller. And then compressing compressed file is not a good idea as shown in the link I have put in one of my message.
[...]Additional note : enabling this compilation flags, cause the signature of external modules to be incorrect as XZ with this flag *must* be used with CRC32 checksum and not the xz default CRC64. I had to add --check=crc32 to my signature scripts for external modules.[...] When does this signature script run?
After I do a dkms. I do not want to put the signature key available directly in the fs.
I built a kernel from Linux 6.6.80 using the cloud-amd64 configuration from linux-config-6.6, and an initramfs using initramfs-tools 0.146. Module loading worked OK, so I don't believe this is a general problem.
I do not use cloud config. Did you check if CONFIG_MODULE_DECOMPRESS=y is set in this config? If yes then the bug goes untoticed as the kernel itself decompress the modules not the module loader.
Ben.
-- Eric Valette