This is a plain and simple hack around dependency issues between dracut
and systemd.
When using Tang-pinned LUKS root devices, we want to rely on
`systemd-cryptsetup@.service` to unlock it. However, that service only
runs `After=remote-fs-pre.target`, while `dracut-initqueue.service` has
`Before=remote-fs-pre.target` (which makes sense because we don't want
to attempt networked root devices before networking is up).
However, the rootfs-generator here wants to make sure that the root
device exists *before* exiting the initqueue via an initqueue/finished
"devexists" hook. This will never work though because by design
`systemd-cryptsetup@.service`, which unlocks the root device, won't run
until after we exit.
So we have a dependency cycle:
initqueue -> devexists hook -> root device ->
systemd-cryptsetup@.service -> remote-fs-pre.target -> initqueue
There's no clean way to break this. The root issue is that there's no
way right now to split sequencing of systemd services across the
initqueue/online and initqueue/finished events because it's all bundled
in a single service. (The deeper root issue of course is that we have
two init systems. :) ).
Here we do a tactical fix: if there's a `systemd-cryptsetup@.service`
instance, let's assume it's for the root device and skip waiting for it
to show up if it depends on `remote-fs-pre.target`.
JobRunningTimeoutSec now affects how long can start jobs for device
units stay in the "running" state. Disabling default job timeout via
JobTimeoutSec=0 doesn't disable running state timeout. We need to set
running state timeout as well.
Note that doing this the other way around has effect on generic timeout,
i.e. disabling running state timeout disables generic timeout. But doing
it this way we would create implicit dependency on fairly new
systemd-234. However, by setting both options we don't create dependency
on specific systemd version.
When 'systemctl daemon-reload' is run, systemd will clean out
/run/systemd/generator and re-run all the generators.
So it is important that the generators always create the required
files.
rootfs-generator.sh currently does *not* create the desired files
if $hookdir/initqueue/finished/devexists-${_name}.sh
exists.
This is not removed by "systectl daemon-reload" so the first time this
generator is run it will do the right thing. Subsequent times it
won't.
This results in incorrect timeouts after "daemon-reload" is run.
So let the existence of each file only guard the creation that file.
Signed-off-by: NeilBrown <neilb@suse.de>
Basic systemd functionality is in 00systemd now.
Switching root and the initrd.target is in 00systemd-initrd.
Dracut additions to the systemd initrd are in 98dracut-systemd.
If kernel cmdline has no root= provided, *and* the initrd carries
a default value, create a systemd mount unit to have it available
in /sysroot
References: bnc#855258
Signed-off-by: Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
When generating units for devices the administrator might
want to use a different timeout than the default.
So implement a new parameter 'rd.timeout' for this.
References: bnc#878770
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Thomas Renninger <trenn@suse.de>
In the kernel comments PARTUUID is shown using uppercase A-F:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/do_mounts.c?id=HEAD#n183
However, dracut tries to use the value of PARTUUID directly in
/dev/disks/by-partuuid/ which expects the hex to be lowercase. This will
cause root to never be found, oops!
Fix dracut so it can, like the Kernel, accept either casing.
Untested but I added a hack on my local system that was similar.
Now init checks that we understood the root= option, and can
act upon it, presenting and error if not. Also, clean up the
generation of udev rules such that we don't require /bin/echo.