Vitaly Kuznetsov [Fri, 27 Feb 2026 13:20:20 +0000 (14:20 +0100)]
cryptsetup-tokens: Print tpm2-primary-alg: only when it is known
When 'tpm2-primary-alg' is missing in LUKS JSON token, the output of
'cryptsetup luksDump' is always:
tpm2-primary-alg: ecc
because tpm2_parse_luks2_json() returns the default (TPM2_ALG_ECC). This can be
misleading and wrong. Make tpm2_parse_luks2_json() return the reality and move
the default to tpm2_unseal().
Vitaly Kuznetsov [Fri, 27 Feb 2026 12:46:07 +0000 (13:46 +0100)]
cryptenroll: Save primary algorithm type to the LUKS token
'tpm2-primary-alg' field is currently unset in LUKS JSON token both for the
case when SRK was used for enrolling (--tpm2-device-key=) and for the case when
SRK was obtained/generated (--tpm2-device=). While this information is not
really needed for unsealing (the sealed object itself has key type in it), it
may be convenient to see key type in e.g. 'cryptsetup luksDump' in the
situations where key type matters. Since 'tpm2-primary-alg' is already defined,
just set it properly in all cases.
core/socket: fix reversed symlink direction in error message
After the update to 260-rc1 in Fedora Rawhide, we get a lot of messages like
this:
systemd[1]: systemd-resolved-monitor.socket:
Failed to create symlink /run/systemd/resolve/io.systemd.Resolve.Monitor →
/run/varlink/registry/io.systemd.Resolve.Monitor, ignoring: Permission denied
The actual issue will need to be fixed too, but let's fix the message first.
While at it, let's rename the variables to be meaningful.
Luca Boccassi [Wed, 25 Feb 2026 23:12:28 +0000 (23:12 +0000)]
mkosi: explicitly add mount package to build image
Some dependency changed in testing and it's not pulled in anymore:
‣ Running build script /home/runner/work/systemd/systemd/mkosi/mkosi.images/build/mkosi.conf.d/debian-ubuntu/mkosi.build.chroot…
/work/build-script: line 35: mount: command not found
‣ /work/build-script failed with non-zero exit code 127
‣ (Maybe a program was not found or the script interpreter (e.g. bash) is not installed?)
FAILED: [code=127] mkosi
Luca Boccassi [Tue, 24 Feb 2026 21:09:26 +0000 (21:09 +0000)]
Install hwids in /usr/lib/systemd/boot/hwids/<EFI_ARCH>/
These are meant to ship with ukify, in the same package,
so install them when ukify is enabled. Given they are
hardware-specific, use a per-arch subdirectory to make it
easier to enable them by default in ukify.
Tobias Heider [Mon, 2 Feb 2026 11:08:46 +0000 (12:08 +0100)]
boot: import Snapdragon device hwid json files
Add hwids json files for Snapdragon devices that use of this
feature since they don't ship with devie trees embedded in firmware.
The json files were originally generated for Ubuntu stubble and
are kown to work since they ship in all Ubuntu arm64 ISOs by default.
Some of the devices might not be supported in mainline Linux yet
and use preliminary compatible strings.
* 23a1c1fed9 Install /usr/lib/systemd/boot/hwids/ in ukify package
* 985170fdc6 Version 259.1
* 2e10d7da1e Revert getty changes a bit harder
* 96c683c3de Revert all remaing changes to getty@.service
* 24a305a398 Revert to previous handling of getty@.service
* 6a500eb814 Create getty@tty1.service again and move autovt@.service alias to /usr/lib
* 88bd4ab206 Properly enable systemd-tmpfiles-clear.service in scriptlets
* d9f3f02206 Raise the number of placeholder sections in kernel and addon stubs
* e301db0151 Stop enabling getty@tty1.service
* a1c33507a2 Fix unit names in systemd-udev scriptlet
* b7b3e024d6 Enable getty@.service through presets
* ec5e1b1ed7 Move tpm2 and getty support to -udev subpackage
* 9c9976a7f8 Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
* f353d244fd Add 2 patches for automatic aarch64 DTB selection change
* 399885597c Revert "Disable sysinit-path for upstream builds"
Luca Boccassi [Wed, 25 Feb 2026 11:16:28 +0000 (11:16 +0000)]
mkosi: add groupadd/groupmod to ASAN wrappers list
TEST-74-AUX-UTILS.sh[3789]: + groupadd haldo
TEST-74-AUX-UTILS.sh[3875]: ==3875==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
Mike Yuan [Tue, 24 Feb 2026 18:40:14 +0000 (19:40 +0100)]
core/namespace: clean up append_private_tmp() a bit
With the previous changes the modes for /tmp/ and /var/tmp/
may come in arbitrary directions, i.e. we may downgrade one
and upgrade another. Hence let's refactor the setup logic
a bit so they're truly independent.
core: simplify requirements in unit_get_private_var_tmp() to just After=
As in the previous commit, checking for both requirements and ordering seems
unnecessary. In practical cases, the mount will be pulled in by the rest
of the transaction, so ordering is the part that matters. (The setup is
racy without the ordering.) If we drop the second check, the admin can
just use After=tmp.mount to achieve the desired behaviour, without needing
to explicitly pull in the unit. This is easier to configure and more robust.
core: upgrade /tmp when PrivateTmp=yes/DefaultDeps=no to disconnected
In https://github.com/systemd/systemd/issues/28515, multiple people report that
services that have PrivateTmp=yes and DefaultDependencies=no fail to create the
temporary directories under /tmp, when /tmp is e.g. a bind mount or some other
kind of mount that takes more time.
Before PrivateTmp=disconnected was added, we didn't have a nice solution:
DefaultDependencies=no is used to start services very early, so we wouldn't
want to add a dependency on /tmp automatically. With PrivateTmp=disconnected we
have a fairly nice solution. Let's "upgrade" to this mode automatically.
Strictly speaking, it is a small compat break, but in practice it's unlikely to
matter for early-boot services whether their /tmp is private or disconnected.
The dependency on /tmp that is checked is After. I think this is enough,
since any tmp.mount would be pulled in by local-fs.target and the rest of
the transaction anyway, so we don't need to check more than After.
The asserts are relaxed, because now the two settings can now diverge
in either way.
Mike Yuan [Tue, 24 Feb 2026 22:11:55 +0000 (23:11 +0100)]
core/execute: stop looking at ExecSharedRuntime to determine PrivateTmp= state
The only reason why ExecSharedRuntime.(var_)tmp_dir might
be suppressed is when (/var)/tmp/ is listed in InaccessiblePaths=,
in which case mount namespace is needed anyways. Moreover,
the current logic imposes a chicken-and-egg problem:
at various places in pid1 we'd need to check whether
the unit runs in a mountns, but the ExecSharedRuntime
may not be allocated for it just yet.
Mike Yuan [Wed, 25 Feb 2026 08:23:50 +0000 (09:23 +0100)]
core/namespace: two fixes for namespace_cleanup_tmpdir()
* Make sure we're not passing NULL to rmdir()
* Remove the inner "tmp" subdir as well, so that callers
can handle this transparently (e.g. exec_shared_runtime_make()
is not aware of the nested rmdir() requirements)
Nick Rosbrook [Mon, 23 Feb 2026 20:25:27 +0000 (15:25 -0500)]
seccomp-util: add lsm_get_self_attr and lsm_list_modules to @default
These syscalls are part of a newer kernel API to replace interaction
with /proc/self/attr, with the goal of allowing LSM stacking. These are
being used now by e.g. libapparmor, so should be more easily available
to services using seccomp filtering.
Daan De Meyer [Fri, 20 Feb 2026 13:16:48 +0000 (14:16 +0100)]
nspawn: Add support for delegated UID ranges
We expose this via --private-users-delegate= which takes the number of
ranges to delegate. On top of delegating the ranges, we also mount in
the nsresourced socket and the mountfsd socket so that nested containers
can use nsresourced to allocate from the delegated ranges and mountfsd to
mount images.
Finally, we also create /run/systemd/dissect-root with systemd-tmpfiles to
make sure it is always available as unpriv users won't be able to create it
themselves.
Luca Boccassi [Fri, 20 Feb 2026 19:28:34 +0000 (19:28 +0000)]
test: avoid hanging forever waiting for udev if not a booted system
test_sd_device_enumerator_filter_subsystem hangs forever in OBS builds,
as it waits for the udev queue to be drained. But this is not a booted
system, with systemd and udev, so nothing will do that.
Skip the test in that case.
Daan De Meyer [Thu, 29 Jan 2026 15:45:59 +0000 (16:45 +0100)]
nsresourced: Optionally map foreign UID range
Whenever delegating UID ranges to a user namespace, it can also be
useful to map the foreign UID range, so that the container running in
the user namespace with delegated UID ranges can download container
images and unpack them to the foreign UID range.
Let's add an option mapForeign to make this possible. Note that this option
gives unprivileged users full access to the any foreign UID range owned directory
that they can access. Hence it is recommended (and already was recommended) to
store foreign UID range owned directories in a 0700 directory owned by the
owner of the tree to avoid access and modifications by other users.
This is already the case for the main users of the foreign UID range,
namely /var/lib/machines, /var/lib/portables and /home/<user> which all
use 0700 as their mode.
Users will also be able to create foreign UID range owned inodes in any
directories their own user can write to (on most systems this means /tmp,
/var/tmp and /home/<user>).
Daan De Meyer [Sat, 24 Jan 2026 00:03:35 +0000 (01:03 +0100)]
nsresourced: Add support for self mappings with delegations
mkosi does all of its environment setup in an unprivileged user
namespace with an identity mapping. When it invokes nspawn and nspawn
tries to get a transient userns from nsresourced, this fails as no
transient ranges are mapped into mkosi's unprivileged userns (as doing
so would require privileges).
To fix this problem, let's allow allocating unprivileged self user
namespaces in nsresourced, similar to what the kernel allows, except that
we also support delegations for these. This means that mkosi can get its
unprivileged userns as before from nsresourced, but it can also request a
delegated 64K range inside that userns as well, which nsresourced can then
allocate to nspawn later when it asks for one.
Similar to the kernel, we disallow setgroups for self mappings. However,
instead of doing this via /proc/self/setgroups, which applies to the current
user namespace and all its child user namespaces, we use the BPF LSM to deny
setgroups instead, so that it can still be allowed for child user namespaces.
We need this because as soon as a container launches in a child user namespace
using one of the delegated mappings, it has to be able to do setgroups() to be
able to function properly.
To allow mapping the root user, we need to add the CAP_SETFCAP capability to
nsresourced.
Daan De Meyer [Fri, 23 Jan 2026 11:31:47 +0000 (12:31 +0100)]
nsresourced: Add support for delegated ranges
We want to support the scenario where we bind mount the nsresourced
varlink socket into a container to allow nested containers where the
outer container runs in its own transient range from nsresourced but
can still allocate transient ranges for its own nested containers.
To support this use case let's add support for delegation. Delegated
ranges are allocated when allocating the primary range and are propagated
1:1 to the user namespace. We track delegated ranges in ".delegate" files
in the userns registry so that they can't be used for other range allocations.
We make one exception for delegated ranges though, if we get a request from
a user namespace that is a child of the user namespace that owns the delegated
ranges, we allow allocating from the delegated range. The parent userns already
has full ownership over the child userns, so it doesn't matter that the parent
userns and the child userns share the same range. This allows making use of
delegated ranges without having to run another copy of nsresourced inside the
parent userns to hand out from the delegated range.
To support recursive delegations, we keep track of the previous owners of the
delegated range and restore ownership to the last previous owner when the current
owner is freed.
The purpose of the userns-restrict BPF-LSM program is to prevent the
transient ranges leaking to disk, so let's allow operations outside the
transient UID ranges, even if the mount is not allowlisted.
This is preparation for the next commits where we'll add support for mapping
the current user and the foreign UID range into the user namespaces provisioned
by nsresourced. Operations creating files/directories as these UIDs/GIDs should
not need the corresponding mount to be allowlisted with nsresourced.
Yu Watanabe [Tue, 24 Feb 2026 16:35:38 +0000 (01:35 +0900)]
man: coredump: KeepFree/MaxUse clarification of default values (#40796)
On sd-coredump for both `MaxUse` and `KeepFree` defaults has a caveat,
it may set it differently if not explicit configured.
On `MaxUse` it'll cap to 4GiB as seem
[here](https://github.com/systemd/systemd/blob/d39b10371964d048a3c5d7dbf84552ecdba66bbe/src/coredump/coredump-vacuum.c#L82).
Similar for `KeepFree`
[here](https://github.com/systemd/systemd/blob/d39b10371964d048a3c5d7dbf84552ecdba66bbe/src/coredump/coredump-vacuum.c#L98)
sd-netlink: pin reply slot while we execute callback
The callback might drop the last ref to the slot object, and we still
want to access it. Hence do what we usually do in these cases: keep an
extra reference while processing the callback.
network: enable LLDP for links that use only link-local addressing
Links with link-local-only communication are typically peer-to-peer
links between two laptops or similar. In such cases it makes sense to be
able to see which device one is specifically connected to, hence let's
just enable LLDP for it. This doesn't leak any data really, given that
this is inherently local, and typically only used between isolated
systems that are under the same user's possession.
Background: I recently connected multiple laptops via thunderbolt networking
and was kinda annoyed not being able to see what system I was actually
talking to.
(Also, the file touched here is an example only anyway, so even if this
would leak too much info, it's not in effect by default)
Kai Lüke [Tue, 24 Feb 2026 11:10:48 +0000 (20:10 +0900)]
journalctl: order systemd-journalctl.socket after systemd-sysusers
The socket failed on boot due to a ordering problem caused by
systemd-sysusers running later and thus the socket group was still
missing. The socket unit can only start when systemd-sysusers created
the group.
Order the socket after systemd-sysusers.service to have the group
available.
Could ask to Bastien Nocera who originally commited the joysticks hwdb
integration
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1429#note_3338386
and stated that was for use in iio-sensor but later anything was done.
As the variable was never used replace it with the new variable actually
in the process to be use in libinput. Even more at least some of the
idea that was planed for ID_INPUT_JOYSTICK_INTEGRATION could be done in
libinput.
Actually ID_INPUT_JOYSTICK_INTEGRATION was never used anywhere, replace
it with ID_INTEGRATION.
I'm pretty sure we should not create more of these multiplexer
interfaces, which in this specific also leads to a fair bit of
confusion: start/stop/reload-or-restart --marked all enqueue
all job types.
Instead, a dedicated verb will be introduced in later commits.
Luca Boccassi [Tue, 24 Feb 2026 11:53:47 +0000 (11:53 +0000)]
resolved: Add ifindex=0 support for BrowseServices to browse all mDNS interfaces (#40133)
With v259, resolved can be used to replace Avahi for mDNS service
discovery and announcement. One key difference in the API is that Avahi
by default browses on all available interfaces by passing a special
`AVAHI_IF_UNSPEC` (-1) interface index value. With this change, passing
ifindex value `0` can be used to achieve the same , so this will work:
```
# Browse on all available interfaces
varlinkctl call --more unix:/run/systemd/resolve/io.systemd.Resolve \
io.systemd.Resolve.BrowseServices \
'{"domain":"local","type":"_display._tcp","ifindex":0,"flags":0}'
```
Not having to iterate through all interfaces on the client side then
also makes it more straight forward to build a resolve-avahi-compat
library for painlessly replacing Avahi with systemd-resolved.
A PoC compat lib requiring this change is available at
https://github.com/LorbusChris/resolve-avahi-compat
Adrian Vovk [Tue, 24 Feb 2026 01:02:03 +0000 (20:02 -0500)]
NEWS: Add note about logind's Can* return values
We've changed them to return additional values, which may be a breaking
change for desktop environments. In practice, it doesn't seem to be a
major issue. However, let's make sure to document the changes in the
NEWS anyway!
Adrian Vovk [Tue, 20 Jan 2026 00:26:30 +0000 (19:26 -0500)]
login1: Emit NCurrentInhibitors changed events
Currently, there's no way for a desktop environment to detect when a
systemd inhibitor has been added or removed. This means that a desktop
environment that wishes to show current inhibitors to the user will be
either forced to poll systemd or just use stale data.
Now, the desktop can listen for changed events on NCurrentInhibitors and
call GetInhibitors() in response to that.
Adrian Vovk [Mon, 19 Jan 2026 23:15:53 +0000 (18:15 -0500)]
login1: Add "inhibited" state to Can* methods
Desktops cannot currently tell the difference between a power action
being set to challenge permanently (i.e. because the sysadmin wanted to
restrict the given user) and a power action being set to challenge
because it's temporarily inhibited.
Thus, a desktop might take an action that is valid in the first case but
not the second case. For instance: GNOME hides all of its automatic
suspend settings from the UI whenever a sleep inhibitor is active.
This now returns a new state: "inhibited". It communicates to the
desktop that the action is available normally, but at the moment the
desktop isn't allowed to perform the action due to an inhibitor.
* 89a825b80e Install new files for upstream build
* 38b1a75eaa systemd.postinst: update journal catalog after reexecing managers
* 9420ffa0dd Install new files for upstream build
* cb5fdf4df0 Install sd-report from new path
* 2501efe312 homed: drop dependency satisfied since bookworm/noble
* 424262b674 d/control: add TODO
* 9aaa01c99d d/libsystemd-shared.preinst: refuse to upgrade without unified cgroupv2 hierarchy
* 7d0ac8a4b8 Install new files for upstream build
* 7e55d41841 Do not install legacy.conf in upstream builds
* 190387958e d/e/checkout-upstream: try to install build deps with sudo in case it fails
* 2a4aa9f426 Disable installing runlevel targets for upstream build
* e02600f2d9 Install new files for upstream build
* 0f1a56cf10 Update changelog for 259.1-1 release
* e463300b1a d/e/checkout-upstream: try to install build deps again after switching to CI branch
* b3f72821e5 Install ask-password polkit policy file
* 8219d561ae Restrict the tpm2-generator manpage to arches where it is built
* 30a0f27283 systemd.postinst: reexec system manager before user instances
* 1fc9ea2790 systemd.postinst: reexec before restarting any service
* d9991aeb22 d/control: use libarchive13t64 | libarchive13 for bookworm/jammy
* b750346711 d/control: make systemd-container Depends: libarchive13t64
sysupdated: Split Update() into Acquire() and Install() D-Bus methods (#40628)
These mirror the `sysupdate acquire` and `sysupdate install` verbs,
which are themselves a split of `sysupdate update` into downloading and
installing stages.
I have dropped the existing `Update()` method in the final commit, as
per the suggestion on
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2004#note_2145880.
If the D-Bus API for `sysupdated` is considered stable now, though, I
can drop that commit.
Philip Withnall [Mon, 19 Jan 2026 18:33:27 +0000 (18:33 +0000)]
sysupdated: Drop the Update() D-Bus method
Now that it’s been replaced by `Acquire()` and `Install()`, there’s no
need to expose it as a separate method. Wrappers around `sysupdated` can
still expose an ‘update’ convenience verb by calling those two methods.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
Philip Withnall [Mon, 19 Jan 2026 18:12:39 +0000 (18:12 +0000)]
test: Expand sysupdate test to test updatectl update
This further expands the sysupdate test to run the suite a fourth time,
testing that `updatectl update` behaves the same as `sysupdate update`
and `sysupdate acquire; sysupdate update --offline`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>