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
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.html http://man7.org/linux/man-pages/man1/bootctl.1.html -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
