Comment # 9 on bug 1152006 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.