unit_file_exists() currently does not follow symlinks, as it is
mainly used to test whether the unit (of any install state)
has been seen under search dirs. However, in ssh-generator
we should search for and honor whatever the distro ships,
which might be an alias or linked externally.
After debian updated the kernel from 6.17 to 6.18, mdadm command fails
with the following:
```
+ mdadm --create /dev/md/mdmirror ...
mdadm: size set to 64512K
mdadm: Can't open /sys/module/md_mod/parameters/legacy_async_del_gendisk
mdadm: init md module parameters fail
```
This seems a bug in mdadm, and fix is already merged in the upstream:
https://github.com/md-raid-utilities/mdadm/pull/228
Until the fix is backported, let's workaround the issue.
See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125390
As reported in https://yeswehack.com/vulnerability-center/reports/705270,
YesWeHack issue #YWH-PGM9780-66, if a newline is injected into the message
field, it is passed through unmolested and lands in the .ini file. This
obviously would cause the parser to be confused.
Let's forbid any control characters or quotes in those fields. If we want
something more complicated in the future, we can add a custom validation
function and allow some escaping mechanism.
This partially reverts commit e58ba80a40. Those
aliases were removed as part of the removal of sysvinit compat, but the removal
was immediately reported as a regression by users. In particular, users can
have one of those set as the default target, or use those names in Wants= or
Requires= dependencies. At least in Fedora, the removal was immediately
reverted.
When looking at our "portability and stability promise", I noticed that those
units are explicitly listed in the promise. Let's restore them upstream. They
are conditionalized under a new -Dcompat-sysv-interfaces=bool option, so that
downstreams like Arch that wasnt to strictly avoid legacy interfaces can easily
disable them. They are dropped from the docs, like we do for all deprecated
interfaces.
The kernel has a "don't break userspace" policy [1] which is very easy
to understand and like (even if the details are complicated). We had a
complicated policy statement, but the actual practice is that we'll
generally avoid changes that cause problems for users. So the whole
detailed table is more of a guideline than something that we can rely
on.
To improve public perception, and to align the docs with practice, let's
make a general promise to keep stability, and change the existing table
to a "guideline" that tells people which interfaces to use and which not
to use so that use and development of systemd don't conflict or create
pain.
The existing document was very long, and I think it'll have a bigger
impact if it shorter. In particular, the chart is dropped, because it
was of limited use and severly outdated, because we have added many new
interfaces and components without updating it. Adding the missing
elements (and then keeping it updated) would be a lot of effort. The
chart would be most useful to somebody trying to build a systemd
reimplementation, but there haven't been many attempts like this, so
let's save the work and drop it and make the document shorter.
I also dropped the mentions of Debian. Back in the day, we did indeed
adopt many Debian conventions for config files and such, but over the
years the scope of the project has grown quite a bit and that part
of systemd is a small fraction now. And we've adopted conventions
and ideas from many other places too, so we don't mention Debian
specifically.
[1] https://docs.kernel.org/admin-guide/reporting-regressions.html
change matches to generic input devices one as name can't be used
because these keyboards have multiple names and also they are used in
multiple devices. This way will be possible to define more detachable
keyboards in an easy way for multiple devices.
Known USB ids for D330 series are: 17EF:60C3, 17EF:60C6 and 17EF:60C8.
Also mark that the tablet part keys and the keyboard doesn't have any
LED to let interfaces decide to expose on-screen indicators.
Unlike other settings that takes multiple values, the setting takes
colon separated list of paths, but when specified as a DBus property,
it previously accepted space separated list of paths.
Let's also make the DBus property accepts colon separated lists.
Fixes#40513.
When machined is started earlier than DBus service, the execution is
blocked by reading properties through DBus for a while. Let's return
earlier if the DBus connection is not ready.
Fixes issue reported in #40414.
These are some patches we currently have in Ubuntu for the development
release. A couple are related to Ubuntu switching to uutils coreutils by
default.
When [DHCPPrefixDelegation] Assign=no, networkd creates routes instead of
addresses. These routes need to populate nftables sets for firewall
rules to work correctly.
This commit adds dhcp_pd_route_modify_nft_set() to handle NFT set
updates for DHCP-PD routes, similar to how address_modify_nft_set()
handles them for addresses.
Fixes: #38383
Partially reverts d6b3793704.
On Ubuntu 26.04 devel, TEST-75-RESOLVED often fails at this stage,
despite the matching query apparently being found:
+ monitor_check_rr '2025-12-18 16:02:54' 'follow10.so.close.signed.test IN CNAME follow11.yet.so.far.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow10.so.close.signed.test IN CNAME follow11.yet.so.far.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow11.yet.so.far.signed.test IN CNAME follow12.getting.hot.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow11.yet.so.far.signed.test IN CNAME follow12.getting.hot.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow12.getting.hot.signed.test IN CNAME follow13.almost.final.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow12.getting.hot.signed.test IN CNAME follow13.almost.final.signed.test
+ monitor_check_rr '2025-12-18 16:02:54' 'follow13.almost.final.signed.test IN CNAME follow14.final.signed.test'
+ set +x
Dec 18 16:02:54 ns1.unsigned.test resolvectl[552]: ← A: follow13.almost.final.signed.test IN CNAME follow14.final.signed.test
Unsetting pipefail, as was done before d6b3793704, appears to fix the
problem.
fstab/crypttab generation were moved to the late stage to support
'fixate-volume-key' option. This, however, broke the use-case when
fstab/crypttab are put to the generated partition/image.
Fixes#40444
With GNU coreutils, one can pass an argument to the "set" flag like:
date -s "-3 days"
With uutils coreutils, that gives an error:
error: unexpected argument '-3' found
tip: to pass '-3' as a value, use '-- -3'
That's a bug (https://github.com/uutils/coreutils/issues/9679), but both
implementations accept --set="-3 days" just fine, so use that instead.
On Ubuntu's test infrastructure for the development series, this test
often fails when piping the journal output to head. The cause is
unclear, but possibly related to Ubuntu's use of uutils coreutils.
Workaround this by just using journalctl's -n flag, which removes the
need for piping output to head.
This is needed to set up extension images from the initrd with
`systemd-sysext --root=/sysroot/ merge`.
- vpick: Don't use openat directly but resolve symlinks in given root
With systemd-sysext --root= all symlinks should be followed relative to
the given root and direct openat usage doesn't work.
Remove the openat call and let pin_choice do the work with the chase
helper function to resolve the symlink in the given root.
- discover-image: Follow symlinks in a given root
So far systemd-sysext with --root= specified didn't follow extension
symlinks (such as the "current" symlinks managed by systemd-sysupdate).
The main use case is running systemd-sysext --root=/sysroot for setting
up the overlay mounts already from the initrd.
Resolve symlinks correctly but don't defend against later symlink races
that would access a path outside of the given root. Malicous live
modifications are not a realistic threat model and anyway for that one
would need to rework how the image entry is passed over up to the point
when the loop device is set up. This change here does not introduce this
weakness nor does it expose it more than before. Thus, make it explicit
that setting up the extensions for a given --root= implies a certain
trust into this given root tree that it does not try do race conditions
with symlinks to trick systemd-sysext to mount a file outside --root=.
Without a strict --image-policy= set we would anyway mount filesystems
right away which is another attack vector but, again, the main use case
is to do this for the final system which is trusted at this stage.
- sysext: Use correct image name for extension release checks
For the extension release check the image name is needed and was derived
from the backing file of the loop device. However, this can have a
different name when symlinks were resolved. The surprising behavior was
that it worked when the target name started with the extension name and
_ because that's what's supported to chop off version suffixes. However,
we should not have such strict requirements for the target name and also
allow - as version separator and entirely different names/prefixes, the
same way as we also do for directories instead of raw images.
Do not use the image name derived from the backing file of the loop
device but directly the extension name we have at hand.
- test: Add tests for handling symlinks with systemd-sysext
When we now allow following symlinks inside a --root= we should also
test that it works in various cases from simple relative and absolute
symlinks to .v being a symlink itself or its contents, both for
directory and for .raw image extensions. While at it, also add a simple
test for .v without symlinks which wasn't there for direct usage of
systemd-sysext.
When link MTU is being adjusted in an IPv6 context (e.g., according to
the MTU received in an RA), the new MTU is clamped against link's
current MTU than link's max MTU. This means that the link MTU can never
be increased via an RA:
systemd-networkd[10068]: eth1: Reducing requested IPv6 MTU 8900 to the interface's maximum MTU 1500.
systemd-networkd[10068]: Setting '/proc/sys/net/ipv6/conf/eth1/mtu' to '1500'
systemd-networkd[10068]: No change in value '1500', suppressing write
Fix this check to make logical sense, and also to match a similar check
in src/network/networkd-setlink.c:link_adjust_mtu().
Commit 15b1c33 ("repart: Generate fstab and crypttab late") moved
fstab/crypttab generation to the late stage but this introduced a regression:
it may be necessary to include fstab and crypttab into the generated partition
(e.g. with CopyFiles=). This is incompatible with 'fixate-volume-key' option as
it is impossible to capture LUKS volume key before it gets created but all the
rest should work fine.
Generate crypttab twice: early and late to capture possible changes. There's no
need to do the same for fstab for now, so keep the status quo.
get_block_device_harder_fd() currently only traverses one level of
device mapper stacking when looking for the underlying block device.
This causes issues with nested DM setups like dm-crypt on top of
dm-integrity, where we don't traverse enough to get the actual physical
device.
Fix this by iterating through all DM layers until we reach a device with
no underlying device. And while we're at it also make cgroups use the
same logic.
Fixes: #40419
I had to sketch this out before I could get the internals of
systemd-sysupdate straight in my head, particularly around how an
`UpdateSet` points to one `Instance` from each of a set of `Resource`s,
and those `Instance`s are either all sources or all targets.
Hopefully this is useful to the next person to look at the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
User and group systemd-network are created from
sysusers.d/systemd-network.conf, which is only copied into the test
image when building with -Dnetworkd=true. This means that if
-Dnetworkd=false is used, the user and the group don't exist, which
causes the test to fail.
Use a locally created user and group to avoid that.
The immediate impulse for this change is the fedora scriptlet which called:
/usr/lib/systemd/systemd-update-helper install-system-units cryptsetup-pre.target cryptsetup.target getty@.service ... system-systemd\x2dcryptsetup.slice system-systemd\x2dveritysetup.slice ...
which called
systemctl preset cryptsetup-pre.target cryptsetup.target getty@.service ... system-systemd\x2dcryptsetup.slice system-systemd\x2dveritysetup.slice ...
which threw an error that system-systemdx2dcryptsetup.slice does not exist
and did nothing at all. (The backslash is consumed by the shell.)
The obvious fix here is to figure out more levels of escaping… But we should
do something more robust in such cases.
If we fail in processing of a single unit, let preset all continue processing
units, report the failure through 'changes'. At the end, return failure. In
general, for operations which operate on a list of units specified by the user,
fail the whole operation if any of the individual operations failed. The only
operation where we don't do this is 'preset-all'.
$ SYSTEMD_LOG_LEVEL=debug build/systemctl --root=/ preset asdf1.servie asdf2.path; echo $?
Cannot find unit asdf1.servie.service.
Cannot find unit asdf2.path.
Failed to preset unit: Unit asdf1.servie.service does not exist
Failed to preset unit: Unit asdf2.path does not exist
1
While at it, fix double logging in the manager: dump_unit_changes() already
logs about errors, so the manager should only log on success.
This partially reverts a4f0e0da35. The
intent was good, we gather the errors, but we have no mechanism to
propagate the result, so the gathered result was ignored. In 'changes'
we can only report errors for specific units. If reading of the
directory fails, we might just as well report the error immediately.
This isn't great, but it's better then ignoring the errors. In practice,
failing halfway in this manner is unlikely, since it'd mean that the fs
is corrupted or something like that. We might as well return immediately
on such catastrophic errors.
archive_read_header(3) states that `archive_read_next_header()` returns
`ARCHIVE_WARN` if it succeeds but a non-critical error is found, so issue a
warning instead of stopping the untar process in this case.
The current code assumes that FILEID_KERNFS filehandles will never grow
in size. This is not a safe assumption and userland shouldn't be trying
to guess the size of the filehandle it'll get.
We have a macro for that: MAX_HANDLE_SZ.
Mike Yuan
Luca Boccassi
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Antonio Alvarez Feijoo
Jim Spentzos
David Santamaría Rogado
Graham Reed
Govind Venugopal
Nick Rosbrook
Ivan Shapovalov
Nicolas Dorier
Vitaly Kuznetsov
Lennart Poettering
Philip Withnall
David Tardon
Kai Lüke
Jeff Layton