If emergency.target is started while initrd-parse-etc.service/start is queued,
the initrd-parse-etc job did not get canceled. In parallel to the emergency
units, it eventually runs the service, which starts initrd-cleanup.service,
which in turn isolates initrd-switch-root.target. This stops the emergency
units and effectively starts the initrd boot process again, which likely
fails again like the initial attempt. The system is thus stuck in an endless
loop, never really reaching emergency.target.
With this conflict added, starting emergency.target automatically cancels
initrd-parse-etc.service/start, avoiding the loop.
Quoting https://github.com/systemd/systemd/pull/24054#issuecomment-1210501631:
> this would need a patch in dracut, specifically adding the
> systemd-sysroot-fstab-check to the list of installed stuff:
> fe8fa2b0ca/modules.d/00systemd/module-setup.sh (L47).
>
> I could do this manually in the CI (and I guess I'd have to do it anyway even
> if the patch lands in upstream, since it won't be available in C8S), but it
> should get there first before merging this PR, otherwise it's going to break
> Rawhide.
This makes use of the option switch that was added in the previous commit.
We used a pretty big hammer on a relatively small nail: we would do daemon-reload
and (in principle) allow any configuration to be changed. But in fact we only
made use of this in systemd-fstab-generator. systemd-fstab-generator filters
out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on
a big majority of systems it wouldn't do anything.
Also, since systemd-fstab-generator first parses /proc/cmdline, and then
initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the
host would only matter if it the same mountpoint wasn't configured "earlier".
So the config in the host could be used for new mountpoints, but it couldn't
be used to amend configuration for existing mountpoints. And we wouldn't actually
remount anything, so mountpoints that were already mounted wouldn't be affected,
even if did change some config.
In the new scheme, we will parse /sysroot/etc/fstab and explicitly start
sysroot-usr.mount and other units that we just wrote. In most cases (as written
above), this will actually result in no units being created or started.
If the generator is invoked on a system with /sysroot/etc/fstab present,
behaviour is not changed and we'll create units as before. This is needed so
that if daemon-reload is later at some points, we don't "lose" those units.
There's a minor bugfix here: we honour x-initrd.mount for swaps, but we
wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be
pulled in immediately.
This makes things a bit simpler and the build a bit faster, because we don't
have to rewrite files to do the trivial substitution. @rootbindir@ is always in
our internal $PATH that we use for non-absolute paths, so there should be no
functional change.
It seems the return code of systemctl daemon-reload can be !=0 in some
circumstances, which causes a failure of the unit and breaks booting in
the initrd.
First, rename root-fs.target to initrd-root-fs.target to clarify its usage.
Mount units with "x-initrd-rootfs.mount" are now ordered before
initrd-root-fs.target. As we sometimes construct /sysroot mounts in
/etc/fstab in the initrd, we want these to be mounted before the
initrd-root-fs.target is active.
initrd.target can be the default target in the initrd.
(normal startup)
:
:
v
basic.target
|
______________________/|
/ |
| sysroot.mount
| |
| v
| initrd-root-fs.target
| |
| v
| initrd-parse-etc.service
(custom initrd services) |
| v
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
| x-initrd.mount)
| |
| v
| initrd-fs.target
| |
\______________________ |
\|
v
initrd.target
|
v
initrd-cleanup.service
isolates to
initrd-switch-root.target
|
v
______________________/|
/ |
| initrd-udevadm-cleanup-db.service
| |
(custom initrd services) |
| |
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
switch-root
Instead of using local-fs*.target in the initrd, use root-fs.target for
sysroot.mount and initrd-fs.target for /sysroot/usr and friends.
Using local-fs.target would mean to carry over the activated
local-fs.target to the isolated initrd-switch-root.target and thus in
the real root. Having local-fs.target already active after
deserialization causes ordering problems with the real root services and
targets.
We better isolate to targets for initrd-switch-root.target, which are
only available in the initrd.
