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
* 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
Follow-up for 072e72424b
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2429626https://fedoraproject.org/wiki/Changes/UseKmsconVTConsole
Yu Watanabe
dependabot[bot]
sd416
Mike Yuan
Jörg Behrmann
Zbigniew Jędrzejewski-Szmek
Daniel Foster
Peter Oliver
Michael Vogt
Sriman Achanta
Allison Karlitskaya
Lennart Poettering
Luca Boccassi
Luca Boccassi