Failed to start systemd-cryptsetup@<uuid>.service

[Neurognostic]

This is an issue with the master branch version on Arch Linux.

I was looking to try out a new feature (secure boot signing), but unfortunately I am seeing this weird error printed on top of where I type my LUKS password. The same exact dracut.conf(5) and dracut.cmdline(7) used on v49 works without issue (except missing features).

The strange thing is I can still type in my password and successfully decrypt and mount root without issue.

dracut-initqueue[518]: Failed to start systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service: Unit systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service: Unit systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service not found.

I ran with rd.debug parameter and did not see anything additional that would help, just this same error. It did appear to be looping the same debug output while I typed my password, which I have not seen when running in debug mode on v49.

Here is the full debug log for the initramfs minus kernel messages: dracut-master.debug.log.zip

How to reproduce:

# /etc/dracut.conf.d/myconf.conf
hostonly="yes"
hostonly_cmdline="yes"
compress="lz4"
show_modules="yes"
add_drivers+="lz4 lz4_compress"
uefi_stub="/usr/lib/systemd/boot/efi/linuxx64.efi.stub"
uefi_secureboot_cert="/etc/efi-keys/db.crt"
uefi_secureboot_key="/etc/efi-keys/db.key"
LINUX_CMDLINE=(
#       rw.info
#       rd.shell
#       rd.debug
       rw
#       rd.cmdline=ask
       rd.luks.timeout=60
       rd.luks.crypttab=0
       rd.luks.uuid=$(cryptsetup luksUUID /dev/disk/by-partlabel/cryptsystem)
       root=UUID=$(blkid -o value -s UUID /dev/disk/by-label/system)
)
kernel_cmdline="${LINUX_CMDLINE[*]}"
unset LINUX_CMDLINE

dracut --force --verbose --uefi --kver 5.5.3-arch1-1 /efi/initramfs-linux-unified.efi.signed

Any idea what is going on here?

[Neurognostic]

Even specifying the LUKS device with kernel parameter rd.luks.name=<<UUID>>=aname instead of rd.luks.uuid I still see the error saying that the service systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service was not found.

It should not even be trying to load that service, the systemd-cryptsetup-generator should only be working with [email protected] in that case.

And like before, I can still mount the LUKS volume despite the error and the Device Mapper name will indeed be aname and not luks-* something.

[Neurognostic]

I also tried using crypttab file in the initramfs. Same error message.

[Neurognostic]

Using --no-hostonly-cmdline or --no-hostonly resolves this issue because, with those options, dracut(8) does not create etc/cmdline.d/90crypt.conf. When it does create this file it essentially creates duplicate kernel parameters for decrypting the root LUKS volume (i.e. rd.luks.uuid=<UUID>), when they are, in fact, already specified elsewhere. Such as in the boot loader configuration or in dracut.conf(5)'s kernel_cmdline option.

[diabonas]

This should hopefully be fixed by #794, could you test whether applying that patch removes the

dracut-initqueue[518]: Failed to start systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service: Unit systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service: Unit systemd-cryptsetup@luksx2d<<CRYPT-UUID>>.service not found.

error?

[ghost]

Using --no-host-only-cmdline or --host-only does not solve the issue for me, I have exactly same distro with luks on root partition and using secure boot signing feature except I don't use bootloader.

[swsnr]

I have the same or perhaps just a similar issue with --host-only; I see the same message as the original poster, only that I do not have any other LUKS-related cmdline flags, and instead rely on systemd to discover the root partition automatically according to DISCOVERABLE_PARTITIONS.

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

[DGatere]

I have the same issue, it seems like a harmless error message since everything works as expected but I require hostonly_cmdline which is what produces the error on my setup with discoverable partitions. Otherwise my rootflags for btrfs are not persisted

[T35R6braPwgDJKq]

related: https://github.com/dracutdevs/dracut/issues/1754

[kjkent]

For what it's worth, I have a similar-sounding issue. Running Arch (btrfs on LUKS, unencrypted boot, no UKI) & had some difficulty getting grub, dracut, and systemd-gpt-auto-generator to work together.

In the script /etc/grub.d/10_linux, grub forces root=..., rw, and rootflags=... into GRUB_CMDLINE_LINUX, which, using dracut at least (systemd-boot doesn't fit my reqs), breaks GPT partition-type UUID automounting with systemd-gpt-auto-generator.

Automounting is supposed to be enabled by default, but there's the cmdline flag root=gpt-auto which I suspected was to override any previously specified root= flags, but, putting this in /etc/default/grub or in /etc/dracut.conf.d had no effect. Dracut immediately drops to a rescue shell having failed on the switch root (service?).

In the end I renamed grub-mkconfig and, in its place, put a softlink to a wrapper script which parses the output destination, calls the real grub-mkconfig, then uses sed to remove the flags I don't want (seems more reliable than a pacman hook). So far this has been working well for me.

Not sure if this has the same root cause, apologies for the noise if not. I read that the kernel parses the cmdline directly, but also that it's supposed to ignore previous flags if they're repeated. In that light, not 100% sure if this is unexpected behaviour of dracut, the kernel, or my brain.