The reallocation of memory and counter incrementation is moved from
the only caller to the function. This way the callers can remain oblivious
of the BootConfig internals.
We must be consistent in the two listings, so let's split out the loading code
and call it from both verb_status() and verb_list(). This effectively makes
verb_status() also call efi_loader_get_entries().
There is still some code duplicated, but that's hard to avoid. Error messages
are made identical for the same errors in various places.
Fixes#22580.
This normalizes naming of functions operating on BootConfig objects.
Let's always call them boot_config_xyz(), like our usual way to name
stuff.
moreover, move the BootConfig parameter to the beginning, as it's not a
return value (which we typically move to the end of the parameter list),
but simply an object, that even happens to be initialized already.
With these changes the functions are more like our usual way to call
things, and less surprises are good.
the function contains a loop and if expressions and whatnot. Let's
define it as regular function, to make the header easier to read and let
the compiler more freedom on whether to inline this or not.
For testing purposes I run one of my system symlinking /boot/loader/ to
/efi/loader/. This triggers annoying behaviour in boot entry
enumeration: the code ends up iterating through the 'entries' subdir of
both, thinking one was actually in the ESP and the other in XBOOTLDR,
and thus distinct. This would result in duplicate entries.
Let's address that, and filter out duplicates via their inode numbers:
never process the same inode twice. This should protect us from any
confusion effectively, regardless which inodes are symlinked (or even
bind mounted).
The code is quite different from the rest of bootspec.c, with different
deps and stuff. There's even a /***/ line to separate the two parts.
Given how large the file already is, let#s just split it into two.
No code changes, just some splitting out.
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
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>
As suggested in https://github.com/systemd/systemd/pull/11484#issuecomment-775288617.
This does not touch anything exposed in src/systemd. Changing the defines there
would be a compatibility break.
Note that tests are broken after this commit. They will be fixed in the next one.
In cases where systemd (and thus bootctl) is updated to a version
including the earlier unique-ID fix, but the corresponding new version
of systemd-boot is not installed to the ESP and run at least once,
the bootloader will report old-style entry IDs cached in the
LoaderEntries EFI variable, while bootctl will report new-style IDs for
the same entries, producing duplicate entries. This commit makes bootctl
compute and retain old-style IDs for non-auto entries so that it can
properly deduplicate entries even if the cache contains old-style IDs.
Now only two operations are left. Let's just move this into the caller,
since it should make things simpler, clearer and shorter, in particular
as there's only a single user for this.
It's a simple wrapper around boot_entries_load_config(), but determines
the ESP/XBOOTLDR paths automatically at first. Also, it looks for a path
/run/boot-loader-entries/ and loads the entries from there if it
exists. This is supposed to be a hook for other boot loaders to make our
tools aware of their own entries.
Previously, bootctl would show boot loader entries discovered by the
boot loader which couldn't found locally separately in the output.
Let's move this code into bootspec.c, and beef it up a bit. This way we
can use it later on for logind, and correctly show automatically
discovered windows/macos entries too.
This 'root' field contains the root path of the partition we found the
snippet in. The 'kernel', 'initrd', 'efi', … fields are relative to this
path.
This becomes particularly useful later when we add support for loading
snippets from both the ESP and XBOOTLDR, but already simplifies the code
for us a bit in systemctl.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
Hiding automatic entries allows for giving custom entry names like
"Windows 10" instead of "Windows Boot Manager" by creating an appropriate
loader file in the loader/entries folder.
Note that it is already doable by renaming bootmgfw.efi (or the other auto-detected
boot loaders) and then using the renamed file for a custom entry. But windows will
automatically recreate the boot loader on updates, including the default EFI
bootloader entry if that one is missing.
Make hiding EFI reboot a separate option because there is no simple way to create
it with a custom loader entry and people may still want that around while still
hiding the other auto entries.
Also, turn no_editor into a positive boolean name while we're touching this code.
This renames find_esp() to find_esp_and_warn() and tries to normalize its
behaviour:
1. Change the error that is returned when we can't find the ESP to
ENOKEY (from ENOENT). This way the error code can only mean one
thing: that our search loop didn't find a good candidate.
2. Really log about all errors, except for ENOKEY and EACCES, and
document the letter cases.
3. Normalize parameters to the call: separate out the path parameter in
two: an input path and an output path. That way the memory management
is clear: we will access the input parameter only for reading, and
only write out the output parameter, using malloc() memory.
Before the calling convention were quire surprising for internal API
code, as the path parameter had to be malloc() memory and might and
might not have changed.
4. Rename bootctl's find_esp_warn() to acquire_esp(), and make it a
simple wrapper around find_esp_warn(), that basically just adds the
friendly logging for the ENOKEY case. This rework removes double
logging in a number of error cases, as we no longer log here in
anything but ENOKEY, and leave that entirely to find_esp_warn().
5. find_esp_and_warn() now takes a bool flag parameter
"unprivileged_mode", which disables logging in the EACCES case, and
skips privileged validation of the path. This makes the function less
magic, and doesn't hide this internal silencing automatism from the
caller anymore.
With all that in place "bootctl list" and "bootctl status" work properly
(or as good as they can) when I invoke the tools whithout privileges on
my system where /boot is not world-readable
