The imds-network= meson option has never had an effect on the generated
network configuration. It arrived in 168a7f7770 together with the IMDS
generator, which wired IMDS_NETWORK_LOCKED_DEFAULT (turned into
IMDS_NETWORK_DEFAULT by c3e4e8a527) into the generator's
arg_network_mode. But the generator only ever compares that variable
against IMDS_NETWORK_OFF, to decide whether to pull
systemd-imds-early-network.service into the initial transaction, and
"off" is not one of the option's choices. It also never forwards the
mode on to systemd-imds-early-network.service, neither as a command
line switch nor via a drop-in.
85-imds-early.network is written by systemd-imds-early-network.service,
which runs "systemd-imdsd --setup-network", and that code path's
arg_network_mode was left at _IMDS_NETWORK_MODE_INVALID. As
setup_network() requires "!= IMDS_NETWORK_UNLOCKED" before emitting the
"prohibit" routes, the unset sentinel behaves exactly like "locked".
At first that went unnoticed, because the option defaulted to "locked"
as well: the documented default matched the implemented behaviour by
accident, and only "-Dimds-network=unlocked" was quietly ignored.
6240d420d6 ("meson: unlock imds network by default") then flipped the
default by reordering the option's choices, i.e. moved a macro that
nothing consumed. From that point on the default was wrong for
everybody: unless systemd.imds.network= is passed on the kernel command
line, every generated network file locks the IMDS endpoint down, no
matter how the build is configured. ac64b2dfa3 later documented the new
default in man:systemd-imdsd@.service(8) (#42687), which meant the
documentation now described behaviour that does not exist.
In practice this rarely became visible until the previous commit, since
systemd-imdsd --setup-network mostly lost its race against udev and
wrote no network file at all.
Initialize arg_network_mode from IMDS_NETWORK_DEFAULT, the same way
imds-generator.c does. No other code distinguishes the INVALID sentinel
from a real mode; the remaining users compare against IMDS_NETWORK_OFF
and IMDS_NETWORK_UNLOCKED only. The kernel command line still overrides
the build-time default, and the only difference in the generated network
file are the two "prohibit" routes: the fwmark routing table and the
matching routing policy rule are written in either mode, as before.
systemd-imds-early-network.service carries
After=sys-devices-virtual-dmi-id.device, so that systemd-imdsd
--setup-network sees the IMDS_* properties that udev applies to the DMI
device from hwdb data. Ordering dependencies only take effect if both
units are part of the same transaction though, and nothing ever pulled
the device unit in: the generator hooks the service into
sysinit.target.wants/ only, and the unit sets DefaultDependencies=no.
The ordering was therefore a nop, and the service raced udev's
coldplugging.
When it lost that race the failure was silent: smbios_server_info()
found no IMDS_VENDOR= property, so no endpoint got configured,
cmdline_run() returned EXIT_NOTCONFIGURED, the unit's
SuccessExitStatus=NOTCONFIGURED reported that as success, and no
85-imds-early.network was written at all.
Give the unit the same drop-in we already write for
systemd-imdsd@.service, which adds Wants= in addition to After= for the
device unit, and factor it out into a helper. We only get here once the
DMI device has been found in the hwdb, hence pulling the device unit
into the transaction is safe.
Note that with the race fixed I have yet to see systemd-imdsd actually
work in locked mode: it appears to end up locked out by the "prohibit"
route itself, despite the fwmark bypass. That is a separate issue, and
left for somebody else to look into.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able
to have it in /nix/store too like the other util-linux tools).
This makes vmspawn work when /usr/share/qemu/edk2-i386-vars.fd is on
disk with 0444 permissions as is the case on NixOS.
The nix package manager does not store any access permissions, ownership,
timestamps, or extended attributes in its package format to increase
reproducibility. The only meta-data that is stored is the executable bit.
Thus when unpacking a nix package, the executable bit is preserved, but no other
access permissions are preserved and all files in /nix/store end up as
read-only.
This causes the template OVMF vars file to have 0444 permissions. If we preserve
those permissions when copying the template file to /tmp that means QEMU can not
write to the file and fails.
So lets not preserve permissions and keep the 0600 permissions that are set by
default.
* systemd.pc: Keep support for rootprefix and root_prefix
We dropped support for split-usr in https://github.com/systemd/systemd/commit/b0d3095fd6cc1791a38f57a1982116b4475244ba
but kept the `rootprefix` variable in meson but ignore it to make sure we do
not break downstream builds that depend on systemd.
This is fine because we had logic in our meson.build that rootprefix and prefix need to be the
same when split-usr=false.
However we never had this logic in our systemd.pc.in file. This leads to a nasty breaking problem
downstream. Many packages [0,1,2] (there might be more!) rely on overriding rootprefix or root_prefix when calling pkg-config to configure where
to install systemd units. This is because before split-usr we installed units in rootprefix. Setting prefix
on the pkg-config file didn't work. Even when split-usr=false people had to set rootprefix to install units
in the right position.
E.g. they have a line like:
systemdunitdir = systemd.get_variable(pkgconfig: 'systemdsystemunitdir', pkgconfig_define: ['rootprefix', systemd_root_prefix])
With https://github.com/systemd/systemd/commit/b0d3095fd6cc1791a38f57a1982116b4475244ba landing
This would mean all these downstream packages need to be patched to use `prefix` next to `rootprefix`.
(Both need to be kept to keep backwards compat with using older versions of systemd).
This puts a big burden on downstream packages.
Instead we should not break the existing behaviour and keep the old behaviour of systemd.pc.in around.
I've changed systemd.pc.in such that either setting prefix, rootprefix or root_prefix will all have
the same effect. This way we do not break any downstream packages.
- [0](https://github.com/fwupd/fwupd/blob/caa788b37ff34334d83debb047335fd12f3a7836/meson.build#L464)
- [1](https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blame/main/meson.build#L204)
- [2](https://github.com/PipeWire/pipewire/blob/49cdb468c28ba366dbd08eef9cb6dbf2dea2a2e5/src/daemon/systemd/system/meson.build#L1)
In 9b9f6aa412 (#27069)
we changed get_file_version to return 0 instead of 1 on success.
However we did not update the printing of the version number to
handle this change so we would never print the version number.
This is inline with the OCI runtime spec:
On POSIX platforms, path is either an absolute path or a relative path
to the bundle. For example, with a bundle at /to/bundle and a root
filesystem at /to/bundle/rootfs, the path value can be either
/to/bundle/rootfs or rootfs. The value SHOULD be the conventional
rootfs.
(https://github.com/opencontainers/runtime-spec/blob/master/config.md)
In SecureBoot mode this is probably not what you want. As your cmdline
is cryptographically signed like when using Type #2 EFI Unified Kernel
Images (https://systemd.io/BOOT_LOADER_SPECIFICATION/) The user's
intention is then that the cmdline should not be modified. You want to
make sure that the system starts up as exactly specified in the signed
artifact.
journalctl --unit= already did this, and allows you to tail all the logs
for a certain slice easily. It seemed only natural to make --user-unit
behave in a similar way.
The _SYSTEMD_USER_SLICE field was not documented as being added by
journald, so I have added that to the documentation too.
Furthermore, I have documented the existing behaviour of --unit= and the
new behaviour of --user-unit=
The behaviour was actually not documented before, so I am also OK with
removing the match for the --unit= command instead. The user would then
have to manually provide _SYSTEMD_SLICE= filter to journalctl in both
cases. Both options work for me.
Arian van Putten