3970 e = object_path_startswith(path, prefix);
(gdb) p path
$1 = 0x55c5a166f768 "/org/freedesktop/portable1/image"
(gdb) p prefix
$2 = 0x55c59ffc2928 "/org/freedesktop/portable1/image"
(gdb) p e
$1 = 0x5581a1675788 ""
This can be a bit confusing in certain cases, so add a comment and a
test to make the behaviour clearer and explicit.
Before 9e82a74cb0, we had a check like the
following:
if [[ -d /efi/loader/entries ]] || [[ -d /efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/loader/entries ]] || [[ -d /boot/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION"
elif [[ -d /boot/efi/loader/entries ]] || [[ -d /boot/efi/$MACHINE_ID ]]; then
ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION"
…
In stock Fedora 34-, /efi isn't used, but grub creates /boot/loader/entries and
installs kernels and initrds directly in /boot. Thus the second arm of the
check wins, and we end up with BOOT_ROOT=/boot.
After 9e82a74cb0, we iterate over the inner
directory first and over the second directory later:
[ -d /efi/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /efi/Default ]
[ -d /boot/efi/Default ]
[ -d /boot/Default ]
[ -d /efi/loader/entries ]
[ -d /boot/efi/loader/entries ]
[ -d /boot/loader/entries ]
This was partially reverted by 447a822f8e which
removed Default from the list, and a5307e173b,
which moved checks for /boot up, so we ended up with:
[ -d /efi/<machine-id> ]
[ -d /boot/<machine-id> ]
[ -d /boot/efi/<machine-id> ]
[ -d /efi/loader/entries ]
[ -d /boot/loader/entries ]
[ -d /boot/efi/loader/entries ]
6637cf9db6 added autodetection of an entry
token, so we end up checking the following suffixes:
<machine-id>, $IMAGE_ID, $ID, Default
But the important unchanged characteristic is that we iterate over the suffix
first. Sadly this breaks Fedora, because we find /boot/efi/<machine-id> before
we could find /boot/loader/entries. It seems that every possible aspect of
behaviour matters for somebody, so we need to keep the original order of
detection.
With the patch:
[ -d /efi/<machine-id> ]
...
[ -d /efi/loader/entries ]
[ -d /boot/<machine-id> ]
...
[ -d /boot/loader/entries ]
[ -d /boot/efi/<machine-id> ]
...
[ -d /boot/efi/loader/entries ]
Note that we need to check for "loader/entries" too, even though it is not
an entry-token candidate, so that we get the same detection priority as
before.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2071034.
I took inspiration from pid1:
bus_unit_find()
→ find_unit()
→ manager_load_unit_from_dbus_path()
→ unit_name_from_dbus_path()
→ !startswith(path, "/org/freedesktop/systemd1/unit/")
→ return -EINVAL
←
←
←
← if (r < 0) return 0
← 0
←
i.e. we return 0 when queried for "/org/freedesktop/systemd1/unit".
Fixes#23445.
If $BOOT_ROOT is specified, but entry-token not, we'd skip the detection
altogether, effectively defaulting to entry-token=machine-id.
The case where $BOOT_ROOT was not specied, but entry-token was configured
was handled correctly.
This patch makes the handling of both symmetrical, i.e. will only set what
wasn't configured.
No changes to behaviour, but let's print everything out as we discover it.
The docs say that BOOT_ROOT can be specified by the environment. I have
it locally in /etc/kernel/install.conf, and then the override doesn't work.
It'd be nice to handle such cases more reliably.
Fixes#23433
matches is plumbed through until it finally gets used in unit_match()
which can deal with NULL matches so the assert() is unnecessary and
can be removed.
The two call sites of extract_image_and_extensions() also don't
assert() on matches either.
The SBAT section was included in a special section in the EFI code, but
the contents weren't directly visible in any way. Let's add a "test" that
prints them for visual inspection.
If there's some external linter for this format, we could hook it up in the
future.
This fixes a spurious warning from the manager running in user mode:
systemd[1668]: Reached target sockets.target.
systemd[1669]: Failed to create BPF map: Operation not permitted
systemd[1669]: Finished systemd-tmpfiles-setup.service.
systemd[1669]: Listening on dbus.socket.
systemd[1669]: Reached target sockets.target.
systemd[1669]: Reached target basic.target.
systemd[1]: Started user@6.service.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2084955.
rpms can be installed in two different modes: into a chroot, where the system
is not running, and onto a live system. In the first mode, where should create
all changes that are "permanent", and in the second mode, all changes which are
"permanent" but also those which only affect the running system. Thus, changes
like new modprobe rules, tmpfiles rules, binfmt rules, udev rules, etc., are
guarded by 'test -d "/run/systemd/system"' which is the official way to check
if systemd is running, so that they are *not* executed when installed into a
chroot. But the same logic does not apply to sysusers, hwdb, and the journal
catalog: all those files can and should result in changes being performed
immediately to the system. This makes the creation of immutable images possible
(because there are no permanent changes to executed after a reboot), and allows
other packages to depend on the the effect of those changes.
Thus, the guard to check if we're not in a chroot is dropped from triggers for
sysusers, hwdb, and the journal catalog. This means that those triggers will
execute, and no subsequent work is needed. systemd-sysusers.service,
systemd-journal-catalog-update.service, and systemd-hwdb-update.service.in all
have ConditionNeedsUpdate= so they they generally won't be invoked after a
reboot. (systemd.rpm does not touch /usr to trigger the condition, because the
%transfiletriggers make that unnecessary.)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2085481
"left from <something>" is not correct. "left <something>" would be the
usual form, but "left master interface" is not clear at all. So reword
those messages totally.
Follow-up for 3881fd406b.
This fixes a minor bug introduced by 10af8bb24b.
Before the commit, the interface group was set only when Group= is explicitly
specified, otherwise the interface group was kept. However, after the commit,
we need to specify Group= with an empty string to keep the current interface
group.