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.
The refernce to mkosi is manually updated by using tools/fetch-mkosi.py,
and should not be done automatically, as it may have a bigger impact.
Follow-up for c69c5dd58a.
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.
We switched away from recvmsg_safe() in order to gracefully
handle MSG_CTRUNC. But MSG_TRUNC really shouldn't happen.
While at it, do not use RET_NERRNO with ssize_t.
Follow-up for af718e0535
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
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.
The same is done for loader entries.
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.
Fixes#34688
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.
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.
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.
Fixes#34688
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.
Let's make sure we can safely load configuration files based on a root
fd, including XAT_FDROOT.
(While we are at it, always pass path to root fs before fd to root fs,
following our recently updated CODING_STYLE)
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.
Fixes#40455
Alternative to #40463
Zbigniew Jędrzejewski-Szmek
David Tardon
Kai Lüke
Antonio Alvarez Feijoo
Jeff Layton
dependabot[bot]
Yu Watanabe
sd416
Mike Yuan
Jörg Behrmann
Daniel Foster
Peter Oliver
Michael Vogt
Sriman Achanta
Allison Karlitskaya
Lennart Poettering