Arch Linux

systemd-ask-password-plymouth.service is installed with -o/--optional (https://github.com/dracutdevs/dracut/blob/00efe708cab023bfe6eaf530d8ac8ea97b440de2/modules.d/00systemd/module-setup.sh#L51), so a nonexistent file is explicitly non-fatal. systemd supports multiple password agents, so if plymouth is not installed, systemd-ask-password-console.service will be used instead, which is part of the base systemd package. I don't think anything in dracut can or needs to be changed, since people might still want to be able to use dracut with plymouth installed from the AUR (although this will not be officially supported, of course).

What are the errors you are getting during boot?

Thanks Jonas. The error may be unrelated:

Shiv dracut-initqueue[401]: Failed to start systemd-cryptsetup@luksx2d19c6bbf3x2dc981x2d4276x2d82b3x2dbddfcfc7a8f2.service

This is before the dracut prompt to unlock the luks container, which I can successfully decrypt.

systemctl status systemd-cryptsetup@luksx2d19c6bbf3x2dc981x2d4276x2d82b3x2dbddfcfc7a8f2.service
Unit systemd-cryptsetup@luksx2d19c6bbf3x2dc981x2d4276x2d82b3x2dbddfcfc7a8f2.service could not be found.

systemd-cryptsetup@.service is generated on the fly in the initramfs using systemd-cryptsetup-generator, which is why you can't find it on your running system, making debugging this a bit harder. Since unlocking the disk eventually works, my first guess would be that 19c6bbf3-c981-4276-82b3-bddfcfc7a8f2 (the partition that the failing service is trying to unlock) is not the correct UUID of your encrypted partition, but dracut manages to decrypt the correct partition anyway since it tries to automatically unlock all encrypted partition it discovers.

How are you setting up the encryption (rd.luks.id/rd.luks.name kernel command line option, contents of /etc/crypttab)? What is the output of "lsblk -f" (to match the UUID of the failing systemd unit to a partition)?

This might actually be a dracut issue caused by commit https://github.com/dracutdevs/dracut/commit/f9c96cf56fed390841eac05c43826e62014c9188, see the upstream bug reports https://github.com/dracutdevs/dracut/issues/723 and https://github.com/dracutdevs/dracut/issues/727. Would you be able to test my suggested fix https://github.com/dracutdevs/dracut/pull/794 to see whether that fixes the spurious error message?

Hi Jonas,

I applied your patch and I still get the spurious error message(s). The luks volume is the correct one. For some reason it fails the first time:

loader entry:
options rd.luks.uuid=19c6bbf3-c981-4276-82b3-bddfcfc7a8f2 root=UUID=1d2dfd7d-accb-47f4-aa42-c85bfcff8e2f rd.lvm.vg=vgroup init=/usr/lib/systemd/systemd quiet loglevel=3 rw

lsblk:
─luks-19c6bbf3-c981-4276-82b3-bddfcfc7a8f2 254:0 0 117.2G 0 crypt

Thanks for the debugging data! Your configuration looks sane, so this indeed appears to be a problem with dracut. I am pretty sure that after applying the changes, the error message should at least change to include the necessary backslashes, i.e. "systemd-cryptsetup@luks\x2d19c6bbf3\x2dc981\x2d4276\x2d82b3\x2dbddfcfc7a8f2.service" - is that the case? Just to be sure, you did regenerate your initramfs after changing /usr/lib/dracut/modules.d/99base/dracut-lib.sh? Does the error show up with dracut 049 as well, or is it new in dracut 050?

I just copied your updated `dracut-lib.sh` to `/usr/lib/dracut/modules.d/99base/` and regenerated the image with:

/usr/bin/dracut -H -f --no-hostonly-cmdline --kver 5.6.5-1-JWR /boot/initfamfs-dracut.img

Rebooting shows the same error, without backslashes (ie., exactly as if using the default dracut-lib.sh).

I downgraded to 049, and no errors are thrown when generating the intird.

Should I just open a bug upstream for the plymouth issue?

Thanks for the help!

Thank you for testing! Unfortunately I am out of ideas for the moment regarding the systemd-cryptsetup@.service error message, the only thing I can suggest is doing a full bisect between dracut 049 and 050 to see which commit introduced it.

Opening an upstream issue for the "systemd-ask-password-plymouth.service does not exist" warning sounds like a good idea, it looks like it has been introduced by https://github.com/dracutdevs/dracut/commit/70b19acf941c0bf41b2c69c761124425910c0653 and should be easily fixed by checking for the existence of systemd-ask-password-plymouth.service before running systemctl add-wants in modules.d/00systemd/module-setup.sh (though this only comes from briefly looking over the relevant changes, I haven't actually verified that conjecture yet).

OK, thanks Jonas.

I have opened an issue upstream: https://github.com/dracutdevs/dracut/issues/795

And I'll begin the bisection to track down the other issue.