On 4/4/20 11:57 AM, François Ozog wrote:
Hi,
I instrumented boot on my Ubuntu 18.04 server right after systemd startup and caught an access to: /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
Jeremy's patch 06f7d4a1618d ("efibc: Add EFI Bootloader Control module") introduced the variable though this change seems to be unrelated to the commit message. See efibc_set_variable() in drivers/firmware/efi/efibc.c.
@Jeremy, Ard Why is this variable written when CONFIG_EFI_BOOTLOADER_CONTROL=y? It seems not be related to the description of the customizing setting.
According to the UEFI spec the SetVariable() service is optional at run-time.
I have started work on implementing variable services at run-time in U-Boot. See https://lists.denx.de/pipermail/u-boot/2020-March/404441.html.
Best regards
Heinrich
This led to: https://systemd.io/DISCOVERABLE_PARTITIONS/ And then: https://systemd.io/BOOT_LOADER_INTERFACE/ https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
My server is configured with Grub to boot (grub and kernel on a HD, root FS of NVME as grub do not have nvme driver for my card) but the udev is still checking those systemd-boot variables.
From a boot loader perspective, we have the following EFI applications:
- Grub2
- EFIBootGuard (used by CIP)
- Systemd-boot (used by ?)
Regardless of the loader, I assume we need to ensure whatever option is selected by solution builders, they can implement it with our U-Boot reference implementation of UEFI.
The Systemd boot-bless seems of high interest for rolling back UEFI update capsules of firmware...
I'd be happy to get some feed back on :
- the systemd-boot technology
- whether we need to implement the above specs in our UEFI implementation
- whether this has an influence on EBBR
Cheers
FF
PS: other references https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html https://manpages.debian.org/testing/systemd/systemd-bless-boot.service.8.en.... http://man7.org/linux/man-pages/man1/bootctl.1.html