Re: Dracut fails to boot root-fs

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. 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

I think you could be right that dracut is missing a module, but maybe it 
is more of an issue with udev? Any thoughts?

>
>> 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.