Groups | Search | Server Info | Login | Register


Groups > linux.gentoo.user > #116183

Re: [gentoo-user] Dracut fails to boot root-fs

From Michael <confabulate@kintzios.com>
Newsgroups linux.gentoo.user
Subject Re: [gentoo-user] Dracut fails to boot root-fs
Date 2026-04-13 14:40 +0200
Message-ID <MJoK6-ePA9-5@gated-at.bofh.it> (permalink)
References <MJoK6-ePA9-7@gated-at.bofh.it> <MIFah-ek7C-9@gated-at.bofh.it> <MJ1Nv-ezXB-5@gated-at.bofh.it> <MJoK6-ePA9-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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.

Back to linux.gentoo.user | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: [gentoo-user] Dracut fails to boot root-fs Michael <confabulate@kintzios.com> - 2026-04-11 14:00 +0200
  Re: [gentoo-user] Dracut fails to boot root-fs Michael <confabulate@kintzios.com> - 2026-04-12 14:10 +0200
    Re: [gentoo-user] Dracut fails to boot root-fs Michael <confabulate@kintzios.com> - 2026-04-13 14:40 +0200
      Re: [gentoo-user] Dracut fails to boot root-fs Dale <rdalek1967@gmail.com> - 2026-05-11 04:40 +0200

csiph-web