Created attachment 116046 [details] strace of the cryptsetup command that hangs As part of the process of decrypting the root volume during early boot, 'cryptsetup open --type luks /path/to/dev root' is executed while we're still in the initramfs and before switch_root is called. Starting with systemd 220 this call hangs and boot never continues. Attached is a screen shot of the end of the strace output. Git bisect shows the *parent* commit of https://github.com/systemd/systemd/commit/cb49a4f2dd53 as the last working revision. While testing commit cb49a4f2dd53, 'udevadm settle' would hang, though that's not the case with v220 or git master. I might check the range cb49a4f2dd53..master to see if there's a point where the both the 'udevadm settle' command and cryptsetup work. This is possibly related to bug 90656.
Forgot to mention this is on Arch Linux, running Linux 4.0.4 and cryptsetup 1.6.6.
Is this dracut or some other initrd?
It's not dracut; the initramfs is generated using mkinitcpio which I believe is specific to Arch. [1] [1] https://wiki.archlinux.org/index.php/Mkinitcpio
(In reply to Evangelos Foutras from comment #0) > Git bisect shows the *parent* commit of > https://github.com/systemd/systemd/commit/cb49a4f2dd53 as the last working > revision. While testing commit cb49a4f2dd53, 'udevadm settle' would hang, > though that's not the case with v220 or git master. I might check the range > cb49a4f2dd53..master to see if there's a point where the both the 'udevadm > settle' command and cryptsetup work. Actually, ignore this paragraph; I was removing the 'assert(manager->pid == getpid());' assertion from all my test builds (in src/udev/udevd.c). This might have messed with the results and possibly caused the 'udevadm settle' issue. The cryptsetup hang is still valid though.
Created attachment 116064 [details] "maximum number (20) of children reached" errors I ran systemd-udevd with --debug (in the initramfs) and a lot of "maximum number (20) of children reached" errors get repeated after I execute 'cryptsetup open'.
I did some more careful bisecting and the commit that introduced this bug is: commit e237d8cb0e5488eef311ca1eafe48e8a2248b04c Author: Tom Gundersen <teg@jklm.no> Date: Tue May 12 21:16:47 2015 +0200 udevd: move file descriptors to Manager No functional change. Link: https://github.com/systemd/systemd/commit/e237d8cb0e54 I haven't looked deeper into this, but it appears that workers aren't terminated properly (or maybe the manager loses track of them).
This should be fixed by 86c3bece38bcf55da6387d20c6f01da9ad0284dc.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.