http://bugzilla.suse.com/show_bug.cgi?id=1152006 http://bugzilla.suse.com/show_bug.cgi?id=1152006#c9 --- Comment #9 from Martin Wilck --- (In reply to Stefan Seyfried from comment #4)

See - no root device needed ;-)

Understood. The problem is that that dracut's primary objective is still booting computers, and it's easy to forget about the other use cases.

I guess that initrd-root-device.target is intended simply as an ordering helper target in systemd

In principle, this is modeled via the dependencies of "initrd.target". By default, these include "initrd-root-fs.target initrd-root-device.target initrd-fs.target". That supports my point - if the root device and FS are present, there's no point in waiting any further, whether or not "$netroot" is set. [Note to self: By default, "initrd-parse-etc.service", pulled in by "initrd.target", execs systemctl daemon-reload ("Reload Configuration from the Real Root") and then starts "initrd-cleanup.service", which has "After" deps on initrd-root-fs.target initrd-fs.target initrd.target and isolates "initrd-switch-root.target". See also bootup(7).] The Right Solution (TM) for dracut's alternate use cases such as Kiwi (and also, for the default case) would be to create a proper model for the dependencies for initrd.target. In your case, the dependency list of initrd-root-device.target is empty, and thus nothing to wait for. BUT you need to wait for the network to be up, and that should be properly modeled by a systemd dependency. Also, you don't need initrd-switch-root.target, obviously (how is that avoided today?). Unfortunately, there's no such thing as "initrd-network.target", currently. Instead, there's dracut's legacy "initqueue" concept. At least the "finished" initqueue is not much else than a "poor man's systemd" trying to model service dependencies in a simplistic manner. This was the point of my patch - the initqueue dumbly waits for the network device even though it's redundant and the root disk has long be found. Doing this right for all use cases (or at least: figuring out a framework that can be extended to work for all use cases) is non-trivial, prone to cause regressions, and would require intensive upstream discussion. Comments welcome. -- You are receiving this mail because: You are on the CC list for the bug.