Re: Dracut fails to boot root-fs

On 13/04/26 at 01:33, Michael wrote:
>On Sunday, 12 April 2026 23:40:30 British Summer Time Carsten Hauck
>wrote:
>> On 12/04/26 at 01:01, Michael wrote:
>> >On Sunday, 12 April 2026 11:43:04 British Summer Time Carsten Hauck
>> >wrote:
>> >> On 11/04/26 at 12:49, Michael wrote:
>> >> >On Saturday, 11 April 2026 00:49:56 British Summer Time Carsten
>> >> >Hauck wrote:
>> >[snip ...]
>> >
>> >> >> It states:
>> >> >> dracut Warning: Could not boot.
>> >> >> dracut Warning: /dev/disk/by-uuid/73afXXX does not exist
>> >> >
>> >> >Did you install 'sys-fs/cryptsetup' before creating the initramfs
>> >> >with dracut?
>> >> >
>> >> >What modules have you added in /etc/dracut.conf?
>> >>
>> >> Hi Michael, thanks for the answer.
>> >> Yes, cryptsetup is installed and it obviously works. After dropping
>> >> to the shell I can mount and access /dev/mapper/cryptroot without
>> >> any further actions requiered.
>> >
>> >It works manually, but not from within your initramfs.  The wiki
>> >mentions you should install cryptsetup once you chroot into the new
>> >system and *before* you run dracut.
>> >
>> >I wonder if dracut is missing some module, e.g. crypt, dm (and
>> >crypt-gpg if you use gpg encryption for the luks key) which would
>> >allow it to run cryptsetup and create /dev/mapper/cryptroot.
>>
>> I don't think cryptsetup is the issue. I did install it before
>> creating the initramfs.
>
>OK, good.
>
>> In fact dracut was run several times since,
>> automatically while updating the chroot and also manually. After
>> loading the kernel I am prompted for the passphrase for
>> /dev/nvme0n1p4 as expected. After dropping to the dracut-shell the
>> LUKS-device is already decrypted and /dev/mapper/cryptroot is
>> present. Also in the dracut-shell I obviously only have the tools
>> that are included in the initramfs.
>>
>> What makes me wonder: In /dev/disk/by-uuid and /dev/disk/by-label I
>> find the devices that are present before the LUKS-device is
>> decrypted, but no reference to LABEL="root" and UUID=73afXXX
>
>There should be a /dev/dm-0 and symlinks to it.  From what you mention
>it means the dm-crypt mapping has not taken place.  Try 'dmsetup status'
>or 'dmsetup info' to confirm.  Then 'dmsetup mknodes' to see if the
>decrypted device becomes mapped and listed correctly.
>
>
>> I think you could be right that dracut is missing a module, but maybe
>> it is more of an issue with udev? Any thoughts?
>
>I don't think this is a udev generated error.  You can check your logs
>for kernel's uevent errors after your chroot (/var/log/dmesg).  It would
>complain it can't find a block device.  Anyway, here's some options to
>try out:
>
>You can check the UUIDs in your fstab and UUIDs or PARTUUIDs in grub
>config are all correct.  Then you could try adding this in your
>dracut.conf:
>
>omit_dracutmodules+=" udev-rules "
>
>and recreating your initramfs with '--add-fstab /etc/fstab' to help
>overcome any dynamic udev glitch.
>
>Alternatively, when boot fails because of slow block devices, I have
>used e.g.:
>
>rootdelay=3 rootwait
>
>when booting from a USB spinning drive to give it enough time to spin up
>and settle before the kernel gives up on it.  Or you could add perhaps
>rd.retry=100
>
>
>> >> The modules I expect to need are all included by default, so at the
>> >> moment I have no further modules added. I wonder if udev should
>> >> scan the decrypted LUKS-device again?
>> >>
>> >> >> I can mount and access the root filesystem
>> >> >> (/dev/mapper/cryptroot)
>> >> >> without problem but even after mounting it on /sysroot and
>> >> >> exiting
>> >> >> the shell it fails to boot and drops me right back into the
>> >> >> shell.
>> >> >>
>> >> >> dracut:/# blkid
>> >> >> /dev/nvme0n1p3: UUID="66b9XXX" TYPE="swap" PARTUUID="7f17XXX"
>> >> >> /dev/nvme0n1p1: UUID="C900XXX" BLOCK_SIZE="512" TYPE="vfat"
>> >> >> PARTUUID="9f76XXX"
>> >> >> /dev/nvme0n1p4: UUID="332dXXX" TYPE="crypto_LUKS"
>> >> >> PARTUUID="52a0XXX"
>> >> >> /dev/nvme0n1p2: LABEL:"boot" UUID="aef0XXX" BLOCK_SIZE="4096"
>> >> >> TYPE="ext2" PARTUUID="c457XXX"
>> >> >> /dev/mapper/cryptroot: LABEL="root" UUID"73afXXX"
>> >> >> BLOCK_SIZE="512"
>> >> >> TYPE="xfs"
>> >> >>
>> >> >> dracut:/# cat /proc/cmdline
>> >> >> BOOT_IMAGE=/vmlinuz-6.18.18-gentoo-dist root=UUID=73afXXX ro
>> >> >> rd.lang=de rd.vconsole.keymap=de-latin1
>> >> >> rd.luks.name=332dXXX=cryptroot
>> >> >>
>> >> >> I tried to modifie the GRUB commandline to access the root
>> >> >> filesystem
>> >> >> by LABEL or by /dev/mapper/cryptroot with the same effect.
>> >
>> >I tend to stick to rd.luks.uuid and once it works as intended I add
>> >LABEL if desired.  'lsblk -o name,LABEL,uuid /dev/nvme0n1' will show
>> >what IDs you can use.
>>
>> My thinking was, if it can't find the partition by UUID, maybe I can
>> force it to find it by name? Only editing the GRUB-commandline in that
>> respect didn't change the result.
>
>From what you posted your initramfs cannot find the decrypted block
>device because it has not been mapped by dm-crypt.  It seems the
>cryptsetup command fails for some reason.
>
>I know you have re-installed your system, which should not be necessary
>to fix this problem, but if the above suggestions won't help you could
>retrace your steps again as per:
>
>https://wiki.gentoo.org/wiki/Rootfs_encryption
>
>in case there's something else you have missed or is not immediately
>obvious without sharing all your setup information in detail.
>
>PS. Instead of LVM you could also use btrfs with subvolumes, all of them
>sharing a large encrypted partition.
>
>PPS. You can keep swap encrypted with dm-crypt and a random key thrown
>away each time, rather than luks.  I haven't looked to check if this
>will work without additional configuration when swap is used for
>hibernation, so YMMV.

Thanks a lot for the input! That's some homework to try. I may need a 
couple of days to find the time to experiment but I will report back.  
Thanks again!