Bug 36528

Summary:	Device plugging and cryptsetup don't get along
Product:	systemd	Reporter:	Andy Lutomirski <luto>
Component:	general	Assignee:	Lennart Poettering <lennart>
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	medium	CC:	luto
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Andy Lutomirski 2011-04-23 10:26:10 UTC

I have an F15 system with two disks.  One contains root and swap, on LVM, on LUKS.  The other contains /home on LVM on LUKS.  Systemd gets stuck trying to boot it.  One of the causes is that the cryptsetup rules ignore default dependencies, which means that they don't pull in udev-trigger.service, which means that the LUKS devices never become "active".  I can "fix" this by hacking up cryptsetup-generator to add Wants: udev-trigger.service.

(patch attached)

This seems flaky, though: shouldn't systemd be smart enough to start udev-trigger.service on its own as soon as something waits for a .device unit that exists in sysfs but is inactive?  (Alternatively, udev-trigger.service could just always run at the very beginning because something'll need it and it might even finish faster the sooner it starts because there may be fewer device nodes.)

[Severity set to major because this makes my system unbootable]

Comment 1 Lennart Poettering 2011-04-26 12:58:20 UTC

udev-trigger.service is installed and statically enabled by udev. (i.e. there is a .wants/ symlink for it in /lib), it should only run once, at boot, for coldplug. If you disabled it you must have done so manually.

I am not entirely sure what precisely this bug is about. Can you elaborate? If you disable udev-settle manually, overriding the default udev configuration then things will break, where's the news in that?

Comment 2 Andy Lutomirski 2011-04-26 13:35:02 UTC

This is F15 and I didn't disable anything.  I did, however, boot with systemd.unit=emergency.target, and it got stuck.  emergency.service has DefaultDependencies=no, which makes cryptsetup wait forever.

In any case, it seems like bad form for a service to have wait forever for a dependency that it neither Wants nor Requires.

(I suspect that the reason I couldn't boot without systemd.unit=emergency.target was a combination of LVM not working and a now-fixed selinux bug.)

Comment 3 Lennart Poettering 2011-04-26 15:06:20 UTC

(In reply to comment #2)
> This is F15 and I didn't disable anything.  I did, however, boot with
> systemd.unit=emergency.target, and it got stuck.  emergency.service has
> DefaultDependencies=no, which makes cryptsetup wait forever.

hmm? emergency.target should not pull in cryptsetup at all, it just starts a shell and that's it. What else is being started for you? Can you attach the output of "dmesg" when booting with systemd.log_level=debug and systemd.log_target=kmsg on the kernel cmd line?

> In any case, it seems like bad form for a service to have wait forever for a
> dependency that it neither Wants nor Requires.

Almost everything in systemd is timed out after 3min.

> (I suspect that the reason I couldn't boot without
> systemd.unit=emergency.target was a combination of LVM not working and a
> now-fixed selinux bug.)

emergency.target should not spawn any LVM related service.

Comment 4 Andy Lutomirski 2011-04-26 16:34:19 UTC

My turn to apologize -- I misdiagnosed this problem.

The combination of two Fedora bugs [1,2] caused my system to hang while trying to mount /home.  Try try to debug the problem, I booted with systemd.unit=emergency.target and did systemctl start cryptsetup.target, which hung.  I said "aha!" and filed this bug because I figured out why systemctl start cryptsetup.target hung and assumed that it was the same reason my bootup hung.

I still think it's worth fixing this "bug" because it's annoying for systemctl start cryptsetup.target to time out when run from an emergency shell.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=699918
[2] https://bugzilla.redhat.com/show_bug.cgi?id=699155

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.