On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
Let's improve display of boot entries and show what type they have (i.e.
boot loader spec type 1, or type 2, or auto-discovered or reported by
boot loader), and in particular mark entries the boot loader discovered
but we can't find (i.e. that likely vanished, or possibly couldn't be
found due to a misconfiguration) and that the boot loader didn't find
but we see (which are new, or possibly also the result of
misconfiguraiton).
This is supposed to be a replacement for #22161, but instead of hiding
vanished entries, highlights them, which I think is more appropriate for
a low-level tool such bootctl.
Replaces: #22161#22398
The single consumer of ticks_read() (i.e. time_usec()) checks for == 0
to detect the "not supported/invalid" case, hence actually return the
right value for that.
Note to self: should I ever become a black hat hacker, this is how I'd
hide a vulnerability. ;-)
(No, this one is not a vulnerability)
Follow-up for: 163d1ea5dd
No actual code changes, just renaming.
Rationale: the focus here should be on the fact that these are "unified"
images, whether our stub is used or not, or something else doesn't
really matter. Moreover, these are still Linux entries. Hence, emphasize
that these are *unified* images, and *Linux* images, and deemphesize
that our sd-stub is likely used.
The script was probably not used for a very long time. It is currently
passed systemd_boot.so as boot loader, which cannot work. The test
entries it creates are all pointing at non-existant efi/linux binaries,
which means they would not even show up in the menu if the created image
were actually booted. There is also nothing that actually tries to run
the image in the first place.
If we end up creating a proper systemd-boot test suite, it would be
better to start from scratch. In the meantime, mkosi already covers
the bare minimum with a simple bootup test.
The debug symbols are of very limited use in proper deployments
unlike with regular userspace. Unless someone goes through the pain
of setting up an EFI debugger (assuming their firmware even supports
this in the first place) any provided debug symbols will just be
useless.
Debugging under QEMU is possible, but even then it is non-trivial
to set up, so anyone willing to go that far can just build in
developer mode.
Meanwhile, at least x86 firmware tends to refuse binaries that contain
debug symbols. We do strip the files when converted to PE anyway, but
the elf file needs to stay around on other arches as objcopy does not
support PE as input there.
Also, the generated debug symbols seem to be not reproducible when
building with LTO. Whether this is an issue in tooling or our side
is unclear. This works around this issue.
Fixes: #22157
Remove the parameter 'only_auto' from the function
boot_entries_augment_from_loader() because each caller set it always to
true.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
When bootctl lists the boot entries, considers also the ones
returned by systemd-boot (via the efi LoaderEntries variable),
created at boot time.
Unfortunately this list may became incorrect if (e.g.) the user remove a
kernel package.
This patch changes this behaviour, so bootctl ignores some the
boot entries returned by systemd-boot.
In any case, bootctl still considers the 'auto-xxx' boot entries
listed below:
Boot entrie name Title
----------------------------- ------------------------------
auto-osx macOS boot loader
auto-windows Windows Boot Manager
auto-efi-shell EFI Shell
auto-efi-default EFI Default Loader
auto-reboot-to-firmware-setup Reboot Into Firmware Interface
The other entries that systemd-boot synthetizes (e.g. the ones loaded from
/efi/loader/entries/<uuid>) can be synthetized by bootctl too, so no
information is lost.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
The device path should not contain multiple hard drive nodes in it,
so looking at them all should not be needed.
If some crazy firmware/driver were to make nested GPT drives
available like that, we should be only looking at the last partition
and its containing GPT drive anyway.
Some firmware creates partition device paths without a messaging
device path node, making the search for the xboot loader partition
fail.
Fixes: #17756
Lennart Poettering
Jan Janssen
Daan De Meyer
Yu Watanabe
Goffredo Baroncelli
Luca Boccassi
Zbigniew Jędrzejewski-Szmek