Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#66290 - [dracut] 050-1 systemd module has hard depends on systemd-ask-password-plymouth.service

Attached to Project: Arch Linux
Opened by jason ryan (jasonwryan) - Saturday, 18 April 2020, 06:05 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 04 May 2021, 15:57 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No


Description: Generating an img with dracut 050-1 throws an error for a missing systemd module:

dracut: *** Including module: systemd ***
Failed to add dependency on unit, unit systemd-ask-password-plymouth.service does not exist.

Which is to be expected if you haven't installed, or have any desire to use, plymouth.

Steps to reproduce: update to dracut 050-1 and generate an image,*without having plymouth installed*. The generated image does work, but throws additional errors on boot (possibly unrelated).
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 04 May 2021, 15:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 051
Comment by Jonas Witschel (diabonas) - Saturday, 18 April 2020, 08:24 GMT
systemd-ask-password-plymouth.service is installed with -o/--optional (, 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?
Comment by jason ryan (jasonwryan) - Saturday, 18 April 2020, 08:44 GMT
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.
Comment by Jonas Witschel (diabonas) - Saturday, 18 April 2020, 10:07 GMT
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 ( 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)?
Comment by Jonas Witschel (diabonas) - Saturday, 18 April 2020, 13:49 GMT
This might actually be a dracut issue caused by commit, see the upstream bug reports and Would you be able to test my suggested fix to see whether that fixes the spurious error message?
Comment by jason ryan (jasonwryan) - Saturday, 18 April 2020, 18:43 GMT
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 init=/usr/lib/systemd/systemd quiet loglevel=3 rw

─luks-19c6bbf3-c981-4276-82b3-bddfcfc7a8f2 254:0 0 117.2G 0 crypt
Comment by Jonas Witschel (diabonas) - Saturday, 18 April 2020, 21:58 GMT
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/ Does the error show up with dracut 049 as well, or is it new in dracut 050?
Comment by jason ryan (jasonwryan) - Saturday, 18 April 2020, 22:09 GMT
I just copied your updated `` 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

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!
Comment by Jonas Witschel (diabonas) - Saturday, 18 April 2020, 22:39 GMT
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 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/ (though this only comes from briefly looking over the relevant changes, I haven't actually verified that conjecture yet).
Comment by jason ryan (jasonwryan) - Saturday, 18 April 2020, 23:01 GMT
OK, thanks Jonas.

I have opened an issue upstream:

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