On Sun, 2025-03-16 at 20:21 +0100, Eric Valette wrote: > On 16/03/2025 20:13, Ben Hutchings wrote: [...]
> > 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.
And yet module loading is going wrong in a way that can't be reproduced
elsewhere. So please check.
[...]
> > > 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.
Yes, that's a sensible policy.
I was wondering whether the modules installed in the main system are
properly signed but due to some mis-ordering the modules copied into the
initramfs are not.
Can you unpack the initramfs (with unmkinitramfs) and check that the
modules have the same contents as those installed in the main system?
(With the current version of unmkinitramfs, they will be unpacked under
a cpio<n> subdirectory.)
> >
> > 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.
It is not set.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.
signature.asc
Description: This is a digitally signed message part
