* ecec612792 Stop installing /var/lib/systemd/
* 120f84266d d/rules: use --no-also for networkd and journald
* 41780703f2 d/rules: do not restart sockets, it fails if the service is running
* 5f219fbd65 Increase number of sections of sd-stub on amd64 too
* 5832d7f614 d/systemd.postinst: use --no-dbus for daemon-reexec
Max Gautier [Tue, 5 Mar 2024 08:54:47 +0000 (09:54 +0100)]
Don't install systemdstatedir (/var/lib/systemd)
systemdstatedir is created by tmpfiles conf (tmpfiles.d/systemd.conf.in)
already.
By shipping it, systemd prevents the effect of tmpfiles.d/var.conf.in:
q /var 0755 - - -
This should helps implementing the "Hermetic /usr" pattern.
Yu Watanabe [Sat, 31 Jan 2026 17:37:07 +0000 (02:37 +0900)]
mkosi: workaround issue in mdadm-4.5 + linux-6.18
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
This partially reverts commit e58ba80a40fb6e96543d56774a5bc5aa9cdadbf3. 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.
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.
Yu Watanabe [Fri, 30 Jan 2026 11:52:39 +0000 (20:52 +0900)]
bus-unit-util: make ExecSearchPath= accepts colon separated list
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.
Yu Watanabe [Fri, 30 Jan 2026 12:34:02 +0000 (21:34 +0900)]
machine: skip reading properties through DBus when not connected
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.
Yu Watanabe [Fri, 30 Jan 2026 16:19:38 +0000 (01:19 +0900)]
A few test fixes (#40524)
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.
Govind Venugopal [Fri, 30 Jan 2026 14:38:13 +0000 (07:38 -0700)]
network: fix NFTSet population when [DHCPPrefixDelegation] Assign=no (#40049)
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.
Yu Watanabe [Fri, 30 Jan 2026 14:32:07 +0000 (23:32 +0900)]
repart: Restore early fstab/crypttab generation (#40473)
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.
Nick Rosbrook [Mon, 19 Jan 2026 21:09:12 +0000 (16:09 -0500)]
test: use journalctl -n option instead of piping to head
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.
Yu Watanabe [Fri, 30 Jan 2026 13:36:20 +0000 (22:36 +0900)]
discover-image: Follow symlinks in a given root (#39843)
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.
Ivan Shapovalov [Fri, 30 Jan 2026 12:11:04 +0000 (13:11 +0100)]
network: fix max MTU check for IPv6 MTU adjustments
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().
Vitaly Kuznetsov [Mon, 26 Jan 2026 13:10:38 +0000 (14:10 +0100)]
repart: Restore early generation of fstab/crypttab
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.
Yu Watanabe [Fri, 30 Jan 2026 06:36:03 +0000 (15:36 +0900)]
Fix bug in DM iteration and standardise how to iterate through DM layers (#40426)
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.
Philip Withnall [Tue, 27 Jan 2026 15:25:08 +0000 (15:25 +0000)]
docs: Add a diagram for the internals of sysupdate
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>
David Tardon [Tue, 27 Jan 2026 13:41:27 +0000 (14:41 +0100)]
test: fix test with -Dnetworkd=false
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 a4f0e0da3573a10bc5404142be8799418760b1d1. 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.
tar-util: do not error out if archive_read_next_header() returns ARCHIVE_WARN
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.
Jeff Layton [Wed, 28 Jan 2026 13:25:10 +0000 (08:25 -0500)]
pidfd/cgroup-util: use fully-sized filehandle buffers
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.
Kai Lueke [Thu, 20 Nov 2025 14:43:55 +0000 (23:43 +0900)]
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.
Kai Lueke [Thu, 20 Nov 2025 14:43:55 +0000 (23:43 +0900)]
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.
Kai Lueke [Thu, 20 Nov 2025 14:43:55 +0000 (23:43 +0900)]
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.
sd416 [Wed, 28 Jan 2026 05:23:21 +0000 (10:53 +0530)]
github: add group configuration for dependabot actions update (#40490)
Add group configuration for dependabot github actions update. This will
ensure that depandabot only creates 1 PR for updating all the new github
actions rather than 1 PR / action update.
As discussed in
https://github.com/systemd/systemd/pull/40089#issuecomment-3672063388,
if any other control msg got truncated it's a genuine error, and
we should reject the message as a whole.
The commit changed the documentation, but the actual impl
was apparently not updated. And the documented behavior
feels a bit off. I think generally "auto"/true should
override $NO_COLOR.
Plus, the test for auto-24bit is at odds with the logic
we merged. I guess it was overlooked after applying
https://github.com/systemd/systemd/pull/40303#discussion_r2720450393
Jörg Behrmann [Fri, 23 Jan 2026 12:55:51 +0000 (13:55 +0100)]
kernel-install: handle removal unsuccessful UKIs and loader entries separately
When a tries file exists, 90-uki-copy.install removes a previous UKI of the
same kernel version and all it's unbooted variants. This removal is guarded
behind a check for the existence of the already booted UKI, i.e. if uki.efi
already exists, uki.efi and uki+*.efi will be removed.
This leaves the edge case that if uki.efi does not exist, but only an unbooted,
e.g. uki+3.efi, it will not be removed. This is not a problem, if the number of
tries is constant between both builds, since a new uki+3.efi would overwrite
the existing one, but if the number of tries is changed to, e.g. uki+5.efi, we
are left with both uki+3.efi and uki+5.efi.
sd-bus: allow receiving messages with MSG_CTRUNC set (#40089)
In the event that we can't receive all of the fds from the message
(which can happen for a number of reasons including LSM denials or
hitting the fd limit of the process) the kernel will set the MSG_CTRUNC
flag. Through our use of recvmsg_safe() we've been treating this as a
fatal error, which will result in dropping the connection.
Let's dial that back a bit: we can receive the message, but when the
user attempts to access the missing fds via sd_bus_message_read_basic()
we can return the (existing) error code of -EBADMSG to indicate that the
fd is missing.
We can do this by using recvmsg() directly, and relaxing some of the
checks on message creation: when (and only when) we have received
MSG_CTRUNC we allow a smaller than expected (per the header) number of
fds to be present. The error check in sd_bus_message_read_basic() was
already there so we don't need to do anything about that.
This puts the receiver of the message into a difficult situation: you
can call sd_bus_message_read_basic() as often as you want but as long as
it keeps returning -EBADMSG it won't progress through the message and
you won't be able to close whatever container you're in. That means
that the user will probably need to abandon processing the message
anyway. So why not just drop the message up front? This approach is
more likely to yield a useful error message, which will be invaluable
for people trying to track down problems caused by LSM denials.
Michael Vogt [Mon, 26 Jan 2026 18:25:50 +0000 (19:25 +0100)]
vmspawn: keep stderr fd connected when running ssh-keygen
When vmspawn executes ssh-keygen it currently hides all std{out,err}.
This is not ideal when errors happen, so this commit tweaks the
code to include stderr in the output.
My use case is that I recently ran into the issue that inside a
`mkosi box` my systemd-homed user was not available so ssh-keygen
errored with `No user exists for uid 1000` [0] but that error was
not visible, only the generic:
`'/usr/bin/ssh-keygen' failed with exit status 255.`
was displayed.
This also adds FORK_REOPEN_LOG to the pidref_safe_fork flags,
thanks to Mike Yuan for the suggestion.
[0] Arguably this is also an issue in ssh-keygen because it does
not need to do the user lookup when `-f /path/` is passed.
Sriman Achanta [Tue, 27 Jan 2026 06:11:35 +0000 (01:11 -0500)]
hwdb: Add extended SteelSeries Arctis headset device support (#40479)
Add USB device IDs for additional SteelSeries Arctis headset models to
the sound card hardware database. This extends support for the complete
Arctis lineup including newer models.
Newly added device IDs:
- Arctis 7 P (0x12d5)
- Arctis Pro (0x1290)
- Arctis Nova 3 (0x12ec)
- Arctis Nova 3 P (0x2269)
- Arctis Nova 3 X (0x226d)
- Arctis Nova 5 (0x2232)
- Arctis Nova 5 X (0x2253)
- Arctis Nova 7 Rev2 (0x2258)
- Arctis Nova 7 Diablo (0x223a)
- Arctis Nova 7 WoW (0x227a)
- Arctis Nova 7 2 (0x22a1)
- Arctis Nova 7 Gen2 (0x227e)
- Arctis Nova 7 X Gen2 (0x229e)
- Arctis Nova Pro (0x12e0)
- Arctis Nova Pro X (0x12e5)
Also reordered existing entries for better organization.
Note, steelseries [firmware release
103.0.0](https://techblog.steelseries.com/2026/01/21/GG-notes-103.0.0.html)
was a major update for all Nova 7 (Gen 1) Family headsets with new PIDs
being issued for the devices. I only own the Nova 7 which is the only
(previously unknown) PID being added. Additional PIDs will need to be
added for those new identifiers (if any), but this should be basically
every Steelseries Headset which the kernel supports/will eventually
support.
We add some test cases for the previous commits: first (with Claude's
help) we exercise the message creation API internally by passing it
various combinations of incorrect fds with the might_be_truncated flag
set to true or false.
Then we try more of a "real world" test by lowering our fd limit and
sending ourselves a message via the bus and making sure that we
successfully receive a message that has had at least some of its fds
truncated.
sd-bus: allow receiving messages with MSG_CTRUNC set
In the event that we can't receive all of the fds from the message
(which can happen for a number of reasons including LSM denials or
hitting the fd limit of the process) the kernel will set the MSG_CTRUNC
flag. Through our use of recvmsg_safe() we've been treating this as a
fatal error, which will result in dropping the connection.
Let's dial that back a bit: we can receive the message, but when the
user attempts to access the missing fds via sd_bus_message_read_basic()
we can return the (existing) error code of -EBADMSG to indicate that the
fd is missing.
We can do this by using recvmsg() directly, and relaxing some of the
checks on message creation: when (and only when) we have received
MSG_CTRUNC we allow a smaller than expected (per the header) number of
fds to be present. The error check in sd_bus_message_read_basic() was
already there so we don't need to do anything about that.
This puts the receiver of the message into a difficult situation: you
can call sd_bus_message_read_basic() as often as you want but as long as
it keeps returning -EBADMSG it won't progress through the message and
you won't be able to close whatever container you're in. That means
that the user will probably need to abandon processing the message
anyway. So why not just drop the message up front? This approach is
more likely to yield a useful error message, which will be invaluable
for people trying to track down problems caused by LSM denials.
/usr/share/ is a directory commonly accessed by various tools, hence we
really should make sure we umount it lazily (MNT_DETACH), since
otherwise there's a good chance that the umount might simply fail.
conf-files: add flag so that we don't always prefix returned paths with the root dir path used
This is useful in tools such as system-repart where we show the
definition file paths a lot in our output, but if prefixed with the root
path we'd show a temporary mount dir when operating on a image file.
Hence, let's drop the prefix here, and show only the path within the
image.
Mike Yuan [Sat, 24 Jan 2026 17:33:05 +0000 (18:33 +0100)]
sd-event: unpoison memory returned by epoll_pwait2()
Our fuzzer CI recently got bumped to Ubuntu 24.04 with
glibc >= 2.35. Apparently msan is not happy with the new
epoll_pwait2(), hence explicitly mark the memory region
as initialized.
* 6f4d90be5c Do not install autovt@ for upstream builds
* 8cc28a6b82 Install new files for upstream build
* 0d15255073 Use deb-systemd-invoke to reexec instead of manual calls
* db04e5fa0b Use dh_installsystemd to handle journald and networkd
* d8756a4c82 Use dh_installsystemd more to manage units
* 40b23b0d5d d/tests: drop tests-in-lxd
* 5821c5a350 d/control: have systemd-boot depend on efibootmgr for amd64 and arm64 only
units/getty@.service: use [Install]Alias= instead of static alias
In Fedora, kmsconvt@.service is starting to be used instead of getty@.service
to have nicer font handling. This means that we need the autovt@.service alias
point to the new unit. So far the alias was done through a static symlink
because there was little reason to change it. Let's use [Install] instead so
the decision which implementation to use can be made after installation.
projects / thirdparty / systemd.git / log
