This is an analog of x-systemd.requires that adds a Wants dependency
instead. This is useful for filesystems that support mounting in
degraded states (such as multi-device filesystems).
I didn't know that this helper existed… It is very similar to strdup_to_full(),
but all callers can actually be replaced by strdup_to(), which has more fitting
semantics.
The glibc API is behind the wrapper is called "secure_getenv()", hence
our wrapper really should keep the order too, otherwise things are just
too confusing.
This is the equivalent of RequiresMountsFor=, but adds Wants= instead
of Requires=. It will be useful for example for the autogenerated
systemd-cryptsetup units.
Fixes https://github.com/systemd/systemd/issues/11646
Prompted by #29705
Note that x-systemd.wanted-by= and x-systemd.required-by= are not
dropped, since we ignore them because they are unnecessary rather
than unapplicable.
Setting nofail for /usr mount doesn't make sense because without /usr we
can't really boot. However, having the flag set might cause races in
initrd where we could try to switchroot into rootfs before /usr is
actually mounted. Let's just ignore it so that we always have proper
mount unit ordering for /sysroot/usr mount.
Let's say "uki" rather than "stub", since that is just too generic, and
we shouldn't limit us to our own stub anyway, but generally define a
concept of a "measured UKI", which is a UKI that measures its part to
PCR 11.
This is mostly preparation for exposing this check to the user via
ConditionSecurity=.
Currently, fstab-generator does not use fstab file parsers in
fstab-util.c. So, this is not necessary. Just for a possible
optimization in the case the parsers used in the future.
If the key does not contain '-' or '_', then it is not necessary to use
proc_cmdline_key_streq(), and streq() is sufficient.
This also adds missing assertions about 'key' argument.
Like we do for root= or so.
Another possible option is adding support of fifth (sixth?) field in
systemd.mount-extra=. But that may be overkill, hence let's do that
later if someone request that.
Fixes fsck part of issue #28541.
When both prefix_sysroot and accept_root is true, the entry for "/" will
be accepted and converted to "/sysroot/".
Why? If the entry is read from the main system's fstab, then we already
mounted /sysroot/, hence it is not and should not re-add the .mount unit
for /sysroot/. However, if we want to specify the root mount through the
kernel command line or credential, without this change, we need to
specify the same entry in the two options. E.g.
===
systemd.mount-extra=/dev/sda1:/:auto:defaults
rd.systemd.mount-extra=/dev/sda1:/sysroot:auto:defaults
===
That's inconvenient. Of course, we can dedup that by using traditional
options, but cannot when defined in credential.
This makes the behavior consistent with the way we already do for
fstab and command line options.
In initrd, entries read from fstab.extra are mounted under /sysroot.
Previously, mounts specified in systemd.mount-extra= are equally handled
both in initrd and the main system. So, the mounts for the main system
are also mounted in initrd.
This introduces rd.systemd.mount-extra=, which specifies mounts in initrd.
Then, mounts specified in systemd.mount-extra= are still mounted both in
initrd and the main system, but prefixed with /sysroot/ when running in
initrd.
Fixes#28516.
If /usr mount is picked from the main system's fstab file (prefix_sysroot
is true, and the path is prefixed as /sysroot/usr), then previously it
was installed in the wrong target unit.
We currently prepend /sysroot to mount points for entries
in /sysroot/etc/fstab. But when it comes to bind mounts,
the source needs to canonicalized too.
Fixes#6827
Replaces #7894
We have this very similar code in various places, and it#s not entirely
obvious (since we want a prolonged timeout for the reload), hence unify
this at one place.
If we discover the root or /usr/ fs via roothash=/usrhash= we know the
file system mounted on it will be read-only, since Verity volumes are by
definition immutable. Hence, let's imply the "ro" mount option for them.
This way the "kernel: /dev/mapper/usr: Can't open blockdev" boot-time
log message goes away, reported here:
https://github.com/systemd/systemd/issues/27682
(I do wonder though why erofs even tries to open the block device as
writable, that sounds utterly pointless for a file system that carries
the fact it is read-only even in the name...)
Now, the following kernel command line options are supported:
systemd.mount-extra=what:where:fstype:options
systemd.swap-extra=what:options
Closes#27260.
With certain fstabs we may propagate ENXIO from the $SYSTEMD_SYSFS_CHECK
check all the way up, making fstab-generator exit with a non-zero EC and
without any helpful message, which is really confusing.
Chasing symlinks is a core function that's used in a lot of places
so it deservers a less verbose names so let's rename it to chase()
and chaseat().
We also slightly change the pattern used for the chaseat() helpers
so we get chase_and_openat() and similar.
