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-b...@zugschlus.de> wrote:
On Fri, Mar 07, 2025 at 05:44:00PM +0100, Eric Valette wrote:
CONFIG_MODULE_DECOMPRESS=y
So 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
