Let's move the currently used/default/oneshot entry output after the
basic info about the boot loader itself, since conceptually these are
objects kinda "one level down" from the boot loader perspective. Hence,
let's *first* show all info about the boot loader itself before we
display the objects it manages.
This is just a trivial change in output, just swaps th elines for these
fields with the ones showing where the boot loader is installed.
So far we'd output both the partition and the binary path always, even
if we didn't know either (but in that case show empty information).
Let's address this, and show partition info only if we know it, or if we
know the EFI binary path, but suppress both if we know neither.
Note that we'll show the partition info if we don't know it still if we
know the EFI binary path used for boot, since it is relative to the
partition of course, and hence it's really strange to know one but not
the other, hence it deserves some mentioning in the output.
Let's make the stub and loader output sections more alike, and say in
both cases whether we recieved that data from the boot phase or not the
same way.
This new field allows specification of an fd on which the password
prompt logic will look for POLLHUP events for, and if seen will abort
the query.
The usecase for this is that when we query for a pw on behalf of a
Varlink client we can abort the query automatically if the client dies.
The values that were previously hardcoded in sd-varlink.c are now defined
in new varlink_set_info_systemd() and that function is called everywhere
where we create a server.
The bootspec util-lib's handling of global addons didn't previously
match the behavior of sd-stub, and this commit corrects that.
First, bootspec didn't load global addons from the XBOOTLDR dir, but the
stub does. So, bootspec now enumerates addons in XBOOTLDR, not just ESP
Second, the stub only loads resources (including addons) from the
partition that it was found on. Thus, we must keep track of which
partition the global addons come from, and which partition each boot
entry comes from. In other words: global addons found on the ESP will
NOT apply to UKIs found in XBOOTLDR, and bootspec now reflects that.
systemd-boot uses the existance of loader/keys/auto to determine
whether to auto-enroll secure boot or not so only create the directory
if we're actually going to put auto-enroll signature lists in it.
This allows loading the X.509 certificate from an OpenSSL provider
instead of a file system path. This allows loading certficates directly
from hardware tokens instead of having to export them to a file on
disk first.
