Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by home_update_quota_auto() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by find_tpm2_auto_data() which is not expected to return
any positive values, but let's be consistent anyway and move the
ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_NOT_SUPPORTED() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_NOT_SUPPORTED() is the
value returned by efi_loader_get_entries() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_NOT_SUPPORTED() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the
value returned by varlink_connect_address() which is not expected to
return any positive values, but let's be consistent anyway and move
the ERRNO_IS_DISCONNECT() invocation to the branch where
the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the argument passed to ERRNO_IS_DISCONNECT() is the value
returned by dns_transaction_emit_tcp() and dns_transaction_emit_udp()
which are not expected to return any positive values, but let's be
consistent anyway and move the ERRNO_IS_DISCONNECT() invocation
to the branch where the return value is known to be negative.
Given that ERRNO_IS_DISCONNECT() also matches positive values,
make sure this macro is not called with arguments that do not have
errno semantics.
In this case the arguments passed to ERRNO_IS_DISCONNECT() are the
values returned by instance_from_socket(), socket_load_service_unit(),
and service_set_socket_fd() which are not expected to return any
positive values, but let's be consistent anyway and move
ERRNO_IS_DISCONNECT() invocations to the branches where the return
values are known to be negative.
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.
When the mkosi CI fails to boot, it just sits there waiting at the emergency
console until the job times out. Add a drop-in for emergency.service in the
CI configuration so that instead it exists immediately.
Follow-up for 6a488fa7cc
Currently, if an fstab entry for /boot/ exists, we'll skip to try /efi/
instead. However, if it's already using the same device as the discovered
one, we should not duplicate the mount.
There is some issue in our code that triggers this warning constantly,
but it's nothing users can solve, so downgrade to debug level until
we can figure out the original issue (which is a permission denied
error on ReleaseSession D-Bus method call).
Related to https://github.com/systemd/systemd/issues/28514
Before c43ff248f9, the following line in
60-drm.rules also sets ID_PATH for all pci, usb, and platform devices:
===
ACTION!="remove", SUBSYSTEM=="drm", SUBSYSTEMS=="pci|usb|platform", IMPORT{builtin}="path_id"
===
Unfortunately, some existing rules rely on the unexpected behavior.
To keep the backward compatibility, let's set ID_PATH for them.
Fixes#28411.
Dmitry V. Levin
Daan De Meyer
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Frantisek Sumsal
Franck Bui
Erik Sjölund
Jan Janssen
Mike Yuan