After the update to systemd 257.7 in Fedora, there are reports that we fail to
create a symlink:
systemd-gpt-auto-generator[585]: Failed to create symlink /run/systemd/generator/local-fs.target.wants/systemd-fsck-root.service: File exists
(sd-exec-[574]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1.
I guess that some other generator created the symlink. We silently ignore
EEXIST in similar codepaths, so add that in one more place. (The target of the
symlink doesn't really matter. The name of the link matters. So something like
symlink_idempotent would not be better. For example, a different generator
might use a slightly different target path, and symlink_idempotent would be too
strict.)
Because it returns the result of the final sd_path_lookup() call rather than the return value of RET_GATHER,
it appears that it may return success even if an error occurs during processing.
With this patch, errors encountered during the loop will be properly tallied and returned, and failures will not be silently ignored.
Signed-off-by: anthisfan <gtpgx305@gmail.com>
When SYSTEMD_COLORS is invalid, parse_systemd_colors() logs about it.
Logging helpers then call into parse_systemd_colors() to pretty-print
the log message, which then fails, so it logs about the failure,
rinse and repeat until segfault.
Follow-up for c8210d98a4
Child processes are left hanging on abort() as these child procs
freeze(), so test suites hang as well when test-namespace fails,
and processes are leaked.
From the docs:
The parent-death signal setting is also cleared upon changes to any of
the following thread credentials: effective user ID, effective group ID,
filesystem user ID, or filesystem group ID.
Set the deathsig again after changing id.
Follow-up for 2ade821859
It is killed when the main test process exists, but still,
it will be left hanging while other test cases run, so it's
not very clean.
Follow-up for 8b5e3be88e
When the test VM is accidentally rebooted, there exists the previously
created volume, and the command fails with the following:
```
TEST-64-UDEV-STORAGE.sh[282]: + lvm pvcreate -y /dev/md/mdlvm
TEST-64-UDEV-STORAGE.sh[442]: Can't initialize physical volume "/dev/md127" of volume group "mdlvm_vg" without -ff
TEST-64-UDEV-STORAGE.sh[442]: /dev/md127: physical volume not initialized.
[FAILED] Failed to start TEST-64-UDEV-STORAGE-mdadm_lvm.service.
```
Let's ignore the existence of previous volume and forcibly create new one.
Workaround for issue #38240.
Otherwise the child processes will continue, return to the test
main function, and try to run other test cases themselves:
<...>
/* test_namespace_get_leader */
PID hierarchy: 553438 ← 553459 ← 553460
/* test_detach_mount_namespace_harder */
/* test_detach_mount_namespace_harder */
/* test_detach_mount_namespace_harder */
Follow-up for 0b8b13324e
Otherwise it remains there, and another test case accidentally
uses it on refresh, which then makes another later test fail,
as the hierarchy is already merged:
[ 203.969708] TEST-50-DISSECT.sh[890]: + systemd-sysext status
[ 203.981831] TEST-50-DISSECT.sh[2795]: HIERARCHY EXTENSIONS SINCE
[ 203.982196] TEST-50-DISSECT.sh[2795]: /opt app0 Mon 2025-09-08 11:49:11 UTC
[ 203.982551] TEST-50-DISSECT.sh[2795]: /usr app0 Mon 2025-09-08 11:49:11 UTC
[ 204.119772] TEST-50-DISSECT.sh[2799]: Hierarchy '/usr' is already merged.
Fixes https://github.com/systemd/systemd/issues/38282
The test occasionally fails with:
TEST-50-DISSECT.sh[3852]: Hierarchy '/usr' is already merged.
I can't really tell what is already merged as all previous ops
look as they are undone from the logs, so add status/list commands
just before the failing operation to hopefully give more info
For https://github.com/systemd/systemd/issues/38282
This reverts commit b177095bfa.
The original issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375275,
https://github.com/systemd/systemd/issues/22168) was about having a block
cursor instead of a box cursor after VM reset, which doesn't seem particularly
urgent. OTOH, the patch causes a minor regression, where the splash screen is
cleared immediately and replaced by a blinking cursor. With the patch, we are
trading one visual issue for another visual issue. The second is probably more
noticeable, since some poeple put in quite a lot of work to have pretty boots
where the firmware splash screen is displayed until the login prompt pops up.
Avoiding a regression is more important than fixing a minor long-standing
issue, so let's revert this.
Fixes https://github.com/systemd/systemd/issues/38752.
Even if there's no uid shift, we still won't be able to bind to
privileged ports in the host network namespace, so drop the capability
regardless of whether we have a uid shift or not.
