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#70335 - [cryptsetup][systemd] Hanging boot with cryptsetup 2.5.3-4 due to missing 11-dm-initramfs.rules

Attached to Project: Arch Linux
Opened by Kristóf Marussy (k_marussy) - Wednesday, 07 April 2021, 17:59 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 05 May 2021, 08:37 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


After upgrading to cryptsetup 2.5.3-4 from 2.5.3-4, systemd hangs with a start job timeout for the root device after successfully unlocking and mounting my LUKS encrypted root device with the sd-encrypt.
Even some systemd services from the root device start, and some log messages get written to the system journal about the boot (but not about the start job timing out).
Nevertheless, after timing out with the start job, systemd tries to enter single-user recovery mode, and refuses to continue booting.

We could manage to track the issue down to the missing usr/lib/udev/rules.d/11-dm-initramfs.rules file in the initramfs.
It's probable that the bug was introduced in the commit for cryptsetup 2.5.3-3, but I upgraded directly to 2.5.3-4.
After reverting the change to use add_udev_rule instead of add_file to /usr/lib/initcpio/udev/11-dm-initramfs.rules (see the attached file 11-dm-initramfs-rules-add-file.patch), the system manages to boot successfully.
See the attached file lsinitcpio.txt for the differences of the contents of initramfs between cryptsetup 2.5.3-2, 2.5.3-4, and 2.5.3-4 with the patches install-sd-encrypt script.
While between 2.5.3-2 and 2.5.3-4, a bunch of files related to tpm and token unlocking were added, 11-dm-initramfs.rules went missing, but it is restored by revering to add_file.

Possibly, this bug manifests because /dev/dm* doesn't get added back after udev reload without this rules file in the initramfs.

Additional info:
* For more information about my setup (kernel command line, /etc/{crypttab,crypttab.initramfs,fstab}), see the attached file setup.txt.
* cryptsetup 2.5.3-4
* mkinitcpio 30-1
* systemd 248-3

Steps to reproduce:
* Upgrade to cryptsetup 2.5.3-4
* Inspect /boot/initramfs-linux.img to verify that it doesn't contain usr/lib/udev/rules.d/11-dm-initramfs.rules
* Use the sd-encrypt hook to unlock a LUKS-encrypted root device that appears in root= on the kernel command line
* Systemd hangs on the boot device shortly after udev reload
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 05 May 2021, 08:37 GMT
Reason for closing:  Fixed
Comment by Kristóf Marussy (k_marussy) - Wednesday, 07 April 2021, 18:33 GMT
Err, I mean after upgrading to cryptsetup 2.5.3-4 from 2.5.3-2, sorry.
Comment by Christian Hesse (eworm) - Wednesday, 07 April 2021, 21:57 GMT
I guess I missed that because the lvm2 hooks installs this for me...
Comment by Christian Hesse (eworm) - Wednesday, 07 April 2021, 22:16 GMT
Please try systemd 248-4 with unmodified cryptsetup 2.5.3-4...
Comment by Kristóf Marussy (k_marussy) - Wednesday, 07 April 2021, 22:28 GMT
Just updated to systemd 248-4 and it's working fine with unmodified cryptsetup 2.5.3-4, thanks!
Comment by Tedd (tedd) - Wednesday, 05 May 2021, 08:36 GMT
  • Field changed: Percent Complete (100% → 0%)
I want to add a comment as I was still getting bit by this bug. Pacman needed to install systemd 248-4 and cryptsetup 2.3.5-4 (cryptsetup version numbers are wrong all through this bug report), after which booting failed. I needed to upgrade systemd *first*, reboot, then upgrade cryptsetup.

This will be a warning for others searching.