Since Linux 4.18 CONFIG_AUTOFS4_FS just enables CONFIG_AUTOFS_FS, its
description in fs/autofs/Kconfig reads:
This name exists for people to just automatically pick up the
new name of the autofs Kconfig option. All it does is select
the new option name.
It will go away in a release or two as people have
transitioned to just plain AUTOFS_FS.
In order to get a good approximation of latencies when starting
services, timestamp before/after running the test cases and print
the difference. This allows to measure while ignoring the setup/shutdown
time for the test harness.
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.
In it's latest release, agetty will support reading the agetty.autologin
and login.noauth credentials, so let's make sure we import those in our
getty units so they're available to agetty to read.
To avoid apt complaining:
+ apt-get -y install clang-15 lldb-15 lld-15 clangd-15
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
python3-lldb-14 : Conflicts: python3-lldb-x.y
python3-lldb-15 : Conflicts: python3-lldb-x.y
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
Otherwise in such case a first `systemctl hibernate` would fail but would still
initialize /sys/power/resume fooling a second `systemctl hibernate` into
believing that 'resume=' is correctly set and can be used by the resume process
to find the swap device to resume from.
Follow-up for #27330.
Otherwise bad things happen:
systemd-networkd[3140]: wlan0: Saved new link: ifindex=5, iftype=ETHER(1), kind=n/a
systemd-networkd[3140]: Assertion '(_error) != 0' failed at src/network/networkd-wifi.c:119, function manager_genl_process_nl80211_config(). Aborting.
Resolves: #28534
Workaround for CI issue, the sd-stub we build is overwritten in the final
image as the package gets pulled there, install it in the base to
work around it for now
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.
