Created attachment 913728 [details] emerge --config gentoo-kernel output When configuring gentoo-kernel (happens also with gentoo-kernel-bin), generated dracut image is not bootable if root is under a NVME device because despite the nvme.ko module is included into the image, it is not automatically modprobed and therefore boot will always fail (or drop to console after all the failed retries (a lot of time)). Additional data: * Version tested: 105-r4 * The kernel cmdline is embedded into image (and marked to override anything else) * Tested with options: add_drivers+=" sha256_ssse3 sha512_ssse3 " force_drivers+=" sha256_ssse3 sha512_ssse3 " hostonly="no" # Also fails with yes i18n_install_all="yes" i18n_vars="/etc/conf.d/keymaps:KEYMAP,EXTENDED_KEYMAPS-EXT_KEYMAPS /etc/conf.d/consolefont:CONSOLEFONT-FONT,CONSOLETRANSLATION-FONT_MAP /etc/rc.conf:UNICODE" early_microcode="yes" do_strip="no" As a workaround, adding force_drivers+=" nvme " makes the image to load correctly (but it takes more than than it should enabling late kayboard leds and taking >5 seconds into /etc/init.d/keymaps)
Created attachment 913729 [details] emerge --info
Not sure if this is the same issue but I could find that on version 100 something similar with similar woraround was found (and fixed later): https://github.com/dracut-ng/dracut-ng/issues/130 Maybe a reintroduced issue?
Not sure if it is relevant but this is a secureboot + modules_sign installation (with signature enforcing checking). Other information is that this started happening "suddenly" after an update, but I don't know what was the last working version
I don't see libkmod.so* and libnss_files* in your initramfs. They should be installed by udev-rules module. Please manually run dracut with --debug option and attach the log. Something like this: /usr/bin/dracut --force --verbose --kernel-image /usr/src/linux-6.12.4-Wesker.Umbrella/arch/x86/boot/bzImage --no-uefi /usr/src/linux-6.12.4-Wesker.Umbrella/arch/x86/boot/initrd 6.12.4-Wesker.Umbrella --debug >/tmp/dracut.log 2>&1
Created attachment 913757 [details] dracut.log.gz
I think one of the relevant lines are: /usr/lib/dracut/dracut-init.sh@675(inst_libdir_file): [[ -e /usr/lib64/libkmod.so* ]] Because libkmod.so is under /usr/lib not under /usr/lib64 (no multilib profile) and at least in my case /usr/lib is not a symlink of /usr/lib64
Ah, it might be related to the funky musl libdir setup. The "normal" libdir for amd64 is lib64, but musl profiles override this. dracut-init.sh detects the presence of the lib64 directory and ignores the lib directory. Also, musl doesn't have a functioning ldconfig, so ldconfig_paths doesn't output anything. I'm mostly wondering how this works for ANY musl user.
(In reply to Mike Gilbert from comment #7) > Ah, it might be related to the funky musl libdir setup. The "normal" libdir > for amd64 is lib64, but musl profiles override this. > > dracut-init.sh detects the presence of the lib64 directory and ignores the > lib directory. > > Also, musl doesn't have a functioning ldconfig, so ldconfig_paths doesn't > output anything. > > I'm mostly wondering how this works for ANY musl user. The funny part is that this is a llvm profile but no musl
Just to add information: equery files kmod (...) /usr/lib /usr/lib/libkmod.so -> libkmod.so.2.5.0 /usr/lib/libkmod.so.2 -> libkmod.so.2.5.0 /usr/lib/libkmod.so.2.5.0 (...)
(In reply to David Carlos Manuelda from comment #8) > The funny part is that this is a llvm profile but no musl Are you using a custom profile? Why is LIBDIR_amd64 set to "lib"?
(In reply to Mike Gilbert from comment #10) > (In reply to David Carlos Manuelda from comment #8) > > The funny part is that this is a llvm profile but no musl > > Are you using a custom profile? Why is LIBDIR_amd64 set to "lib"? This is a thing I have just realized. Yes, I had it set in an old config file somewhere as a leftover. Anyway I think that /usr/lib should not be ignored
Supporting custom profiles with custom libdirs is pretty low on the list of priorities.
Thanks for pointing me into the specific problem, I found my changes on libdirs and dropped them to use the original amd64 profile's default.
