On Fri, Aug 04, 2017 at 04:28:05PM -0400, Rob Clark wrote:
On Fri, Aug 4, 2017 at 4:06 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/04/2017 09:32 PM, Rob Clark wrote:
Similar to a "real" UEFI implementation, the bootmgr looks at the BootOrder and BootXXXX variables to try to find an EFI payload to load and boot. This is added as a sub-command of bootefi.
The idea is that the distro bootcmd would first try loading a payload via the bootmgr, and then if that fails (ie. first boot or corrupted EFI variables) it would fallback to loading bootaa64.efi. (Which would then load fallback.efi which would look for \EFI*\boot.csv and populate BootOrder and BootXXXX based on what it found.)
I wonder if this implementation is Fedora specific.
For Debian I could not find any reference to boot.csv. And it is not mentioned in the UEFI 2.7 spec.
Please, provide the specification that your work is based on.
The references to boot.csv are based on looking at how shim/fallback work.. perhaps that is not standardized. I'll let Peter Jones comment on that if he knows better what windows and other linux distro's do.
The boot.csv parts are part of fallback.efi, which is part of shim. It's not distro specific, though not every distro uses it (though I thought debian had started doing so very recently), and fallback.efi + boot.csv is still strictly optional. But as Rob says below - the boot methodology fallback employs is based on what the spec says the boot manager will do. A distro could also just stick a second copy of their normal bootloader in /EFI/BOOT/BOOTAA64.EFI and it would boot through the recovery path every time until somebody manually created a boot variable. fallback is just shim's method of setting the variables automatically, and it is fairly widely deployed. I'm pretty sure SuSE and Ubuntu both use it, for example.
The bootmanager implementation is based on UEFI spec (sect 3.1 in v2.7), which does not depend on boot.csv or how shim/fallback program the BootOrder/BootXXXX variables. But simply that they do. I'm not particularly familiar with the boot chain on Debian, it is entirely possible that it works differently. My comments about boot.csv where merely to try to provide context (and are quite possibly misleading on some distro's), but are irrelevant to the bootmgr implementation which only cares about BootOrder/BootXXXX, as described in sect 3.1.
(There are a lot of details that I skipped over in the bootmgr implementation, simply because secure boot or setting of efi variables from the OS is not implemented, so they are not yet relevant.)
This is still all correct.