As you can see, something spurious happens in the logs below.
```
initrd-switch-root.target: Trying to enqueue job initrd-switch-root.target/start/isolate
systemd-repart.service: Looking at job systemd-repart.service/stop conflicted_by=no
systemd-repart.service: Looking at job systemd-repart.service/start conflicted_by=no
systemd-repart.service: Fixing conflicting jobs systemd-repart.service/stop,systemd-repart.service/start by deleting job systemd-repart.service/stop
initrd-switch-root.target: Fixing conflicting jobs initrd-switch-root.target/stop,initrd-switch-root.target/start by deleting job initrd-switch-root.target/stop
systemd-repart.service: Deleting job systemd-repart.service/start as dependency of job initrd-switch-root.target/stop
```
The two conflicting jobs for systemd-repart.service are initially queued
as the following:
- initrd-switch-root.target has Wants=initrd-root-fs.target, and
initrd-root-fs.target has Wants=systemd-repart.service (through symlink),
hence starting initrd-switch-root.target tries to start
systemd-repart.service,
- systemd-repart.service has Conflicts=initrd-switch-root.target, hence
starting initrd-switch-root.target tries to stop
systemd-repart.service.
As similar, interestingly(?) starting initrd-switch-root.target tries to
stop initrd-switch-root.target.
So, now there are at least two pairs of conflicting jobs:
- systemd-repart.service: start vs stop,
- initrd-switch-root.target: start vs stop.
As these jobs are induced by starting initrd-switch-root.target, of course
the most important one is the start job for initrd-switch-root.target.
Previously, as you can see in the logs at the beginning, even if
the start job for initrd-switch-root.target is important, we may first
try to resolve the conflict in systemd-repart.service, and may drop the
stop job for systemd-repart.service even if it is relevant to the start
job of initrd-switch-root.target.
This makes first we solve the pair of conflicting jobs for anchor task.
So the stop job for initrd-switch-root.target is dropped first, and the
induced start job for systemd-repart.service is automatically removed,
thus it is not necessary to solve the conflict in systemd-repart.service
anymore.
This is especially important for services that are enabled both in initrd
and after switching root. If a stop job for one of the service is
unexpectedly dropped during switching root, then the service is not stopped
before switching root, and will never start after that.
Fixes#38765.
* 786b8fe1c8 Return false from want_efi() for UKI outputs
* fac86dbc93 mkosi-tools: add qemu/pipewire packages for gui profile for debian
* 3bb98f0e6e Add ncdu to tools tree packages
* 1332b32cb4 config: Fix type for devicetree setting
* eff03569ee initrd: Add intel_pmc_ssram_telemetry module by default
* e04305b030 Make Bootable= determine whether we build a UKI for esp images
* 7252146429 mkosi-obs: use --force also for unzstd
* f58e31e228 mkosi-obs: do not fail if there are no bootloaders in the ESP
* fac3bd4bf1 rhel: Look up entitlement keys and certificates in sandbox
* da814d9634 opensuse: Add support for RISC-V for Tumbleweed
* b1d66c88d0 fedora: Rework rawhide GPG key logic
* b9360f25df Include {sys,conf}ext info in metadata file
* 94c6db6148 Set MakeInitrd=yes in documentation for building custom initrd
* d134013ca8 mkosi-tools: add grub2-common to openSUSE tools tree
* c97d345395 mkosi-tools: virtiofsd is only available on a subset of architectures on debian/ubuntu
There's no guarantee that $GIT_BRANCH is always the same across
stable release branches and main. But we still need to make sure
we switch commits if we're switching between main and release branches.
To make this work, let's not check if the current HEAD commit is an
ancestor of the currently configured origin branch. Instead, let's
check if any of the origin branches contains the current HEAD commit.
This still makes sure that we won't switch commits if we're working
on a local branch while making sure that we do switch commits if we're
switching between main and stable release branches with different
git branches configured for the packaging repo checkout.
These options were added in v255 with commit
cb341090d0, but were not documented as
standalone options in loader.conf. See #29440 for more information.
As a hardening measure it makes sense not to process potentially crafted
data in `openssl_pubkey_to_pem()` before we know that the caller is
authorized to perform the action.
There are a lot of resolved.conf.d drop-ins used in these tests. Use
proper numeric prefixes, especially to avoid confusion with sorting
relative to test.conf.
Make the test base config 10-test.conf, and use 90-*.conf elsewhere.
On reload, resolved does not apply new DNSSEC= (or DNSOverTLS=) settings
on links, because the link unicast scopes are not re-created. However,
the servers and link states are updated correctly, so resolvectl and link
state files do show the new setting, leading users to believe the change
took effect immediately, the same way `resolvectl dnssec` does.
Fix this by freeing all of the link unicast scopes during reload, so
that they are re-created with the new settings in link_allocate_scopes().
A boot loader entry for a unified kernel image has
BootEntry.kernel : path to the image relative to ESP or XBOOTLDR,
BootEntry.path : path to the image.
Hence, these two effectively point to the same file.
Hence, by unlink command, the image is removed by
```
deref_unlink_file(&known_files, e->kernel, e->root);
```
then later tried again by
```
r = chase_and_unlink(e->path, root, ...);
```
and of course it fails with -ENOENT.
Let's ignore the failure there. We already ignore ENOENT on removal
at various places, especially in deref_unlink_file().
Fixes#38706.
Follow-ups for 8702496bfb.
If we are asked to come up with our own name for the namespace to
allocate (because client enabled "mangle"), then we so far created a
randomized name if shortening what was proposed didn't work. This broke
polkit authorization however, because when polkit is in the mix, we
process method calls twice, submitting the polkit request on the first
and then assuming a response is known on the second invocation. But if
we generate a randomized name for the two checks we'll not be ablet to
match up the requests because it's going to be different. Let's fix that
by not using a randomized name, but one hashed from the socket
connection we are processing mixed with the client provided name. This
will ensure that for the same method call we'll generate the same name,
but different calls (i.e. calls with different names on the same socket,
or with any name on any socket) we'll end up with different names,
minimizing chance of collision.
This ensures PK starts to work with nsresourced userns registration when
a bad or no name is specified, which previously would end up in a PK
query loop.
All mice were measured using mouse-dpi-tool, and the measurements match vendors
specs, with the exception of Asus Cerberus (it officially has
500/*1000/1500/2500 DPI, but my measurements were quite different, so I opted
to include the real values).
tmpfiles attempts to correct the label of a file during various actions
via the function fd_set_perms(). Currently, said function generally
respects the dry-run mode. However, it attempts to fix the label of a
given file regardless of the state of said dry-run mode.
This causes problems, because a user could attempt to run tmpfiles with
elevated permissions and dry run enabled, expecting the tool to not
modify their system. Instead, tmpfiles would falsely relabel a file,
modifying their system.
This commit explicitly checks for when dry-run is enabled and skips the
file relabelling process. Furthermore, I added logging for both cases.
I found helpful during debugging. That said, I don't think it's
necessary to use the level LOG_INFO on the dry-run path, as it would
always produce an info log.
manager_add_job() -> transaction_add_job_and_dependencies() may update
dependencies when a unit is not loaded yet. Hence, we need to restart
dependency loop in that case.
Follow-up for b7777d0884 (#37465).
Fixes#38676.
Commit 70b7e03 introduced 3 calls to log_debug() about the presence or
absence of NX_COMPAT support. Since sd-boot does not yet have the
ability to only print messages above a certain loglevel, these will
always be printed, even on top of the configured splash screen. This
commit removes the log_debug() call after a success and only prints
those for missing firmware support if the UEFI should support them in
the first place (i.e. starting with version 2.10).
Currently these messages (broken for length)
2025-08-20T12:04:15.9609277Z
/home/runner/work/systemd/systemd/tools/check-version-history.py:26:
FutureWarning: This search incorrectly ignores the root element, and will be fixed in a future version.
If you rely on the current behaviour, change it to './/funcprototype/funcdef/function'
can be seen in CI output. So let's apply the suggestion.
Hence, we need to wait for the previous operation finished.
Fixes the following failure:
```
TEST-46-HOMED.sh[107]: + homectl unregister signtest
TEST-46-HOMED.sh[1449]: Failed to unregister home: Home signtest is currently being used, or an operation on home signtest is currently being executed.
```
Fixes#38643
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Sergey A
Jasmine Andrever-Wright
Allison Karlitskaya
Daan De Meyer
Felix Pehla
Josh Triplett
Matthias Gerstner
Antonio Alvarez Feijoo
Nick Rosbrook
Lennart Poettering
Kamil Páral
kanitha chim
Jan Fooken
AsciiWolf
Jörg Behrmann
Jack Wu
Luca Boccassi
Jesse Guo
