Bug#1059518: initramfs-tools-core: mkinitramfs with `MODULES=most` doesn't correctly identify dependent modules, caused BIOS-installed system to fail booting on btrfs rootfs with xxhash checksum

[h***@murena.io]

Package: initramfs-tools-core
Version: 0.142
Severity: important

mkinitramfs fails to detect that kernel module `xxhash_generic` should be
installed to init ramdisk, when the rootfs is on a btrfs filesystem with
checksum algorithm xxhash, and the disk partition table is msdos. This resulted
in the system being unbootable because the init ramdisk lacks kernel xxhash
support:

BTRFS info (device sda2): first mount of filesystem fs-uuid
BTRFS error (device sda2): error allocating xxhash64 hash for checksum
BTRFS error (device sda2): open_ctree failed
mount: mounting /dev/sda2 on /root failed: No such file or directory
Failed to mount /dev/sda2 as root filesystem.

Busybox v1.35.0 (Debian 1:1.35.0-4+b3) built-in shell (ash)
(Omitted)

After I added `xxhash_generic` to `/etc/initramfs-tools/modules` and
regenerated the init ramdisk the system booted without issue.

UEFI-installed system is unaffected (in fact I have been using btrfs rootfs
with xxhash as checksum alg on UEFI-only machines for almost a year so this
came as a big surprise when I found that it doesn't even boot), probably due to
xxhash module being marked as a dependency of another thing?

I would also like to propose that we add a (debug) option to include all
available kernel modules in init ramdisk, which may help debug issues like this
in the future.


For the debugging process I went through see:
https://paste.debian.net/1302284/
if anyone is interested.


-- System Information:
Debian Release: 12.4
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages initramfs-tools-core depends on:
ii coreutils 9.1-1
ii cpio 2.13+dfsg-7.1
ii e2fsprogs 1.47.0-2
ii klibc-utils 2.0.12-1
ii kmod 30+20221128-1
ii logsave 1.47.0-2
ii udev 252.19-1~deb12u1

Versions of packages initramfs-tools-core recommends:
ii busybox-static [busybox] 1:1.35.0-4+b3
ii zstd 1.5.4+dfsg2-5

Versions of packages initramfs-tools-core suggests:
pn bash-completion <none>

-- no debconf information

[Ben Hutchings]

Control: reassign -1 src:kmod 30+20221128-1
Control: found -1 33+20240816-2
Control: affects -1 initramfs-tools-core
Control: retitle -1 kmod: modprobe --show-depends may not show all softdeps

Post by h***@murena.io
Package: initramfs-tools-core
Version: 0.142
Severity: important
mkinitramfs fails to detect that kernel module `xxhash_generic` should be
installed to init ramdisk, when the rootfs is on a btrfs filesystem with
checksum algorithm xxhash, and the disk partition table is msdos. This resulted
in the system being unbootable because the init ramdisk lacks kernel xxhash

[...]

initramfs-tools uses modprobe to find the dependencies of each module it
installs.

The modinfo for btrfs includes:

softdep: pre: blake2b-256
softdep: pre: sha256
softdep: pre: xxhash64
softdep: pre: crypto-crc32c

But when we run:

version=$(uname -r)
/sbin/modprobe --all --set-version="${version}" --quiet --show-depends btrfs

the results are:

insmod /lib/modules/6.1.0-31-amd64/kernel/arch/x86/crypto/crc32c-intel.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/crypto/crc32c_generic.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/lib/libcrc32c.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/lib/zstd/zstd_compress.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/lib/raid6/raid6_pq.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/crypto/xor.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/crypto/blake2b_generic.ko
insmod /lib/modules/6.1.0-31-amd64/kernel/fs/btrfs/btrfs.ko

It seems like only the first softdep is being processed. (libcrc32c is
a regular dependency so I don't think the crc32c modules are being found
via the softdep on crypto-crc32c.)

Ben.