Re: Dracut fails to boot root-fs

On 13/04/26 at 10:46, Carsten Hauck wrote:
>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!

So it took me much longer than I hoped to find a couple of hours to sit 
down and experiment. My approach was chaotic and fruitless, I probably 
messed up the combination of dracut and grub configs.
Thank you for bringin  https://wiki.gentoo.org/wiki/Rootfs_encryption to 
my attention again. I finally cheated and did what I should have done 
some months ago. I abandoned dracut for ugRD. It was a matter of 
recompiling sys-kernel/installkernel with changed USE-flags and doing an 
emerge --config *dist-kernel* in the chroot. After rebooting I could log 
into my new system without a problem. So there is a bit of hurt pride 
that I didn't manage to beat dracut into submission, but I am quit happy 
with my working laptop now.  I am still convinced that I did a tiny and 
stupid mistake in configuring dracut, I might never find out.