On Thu, Nov 18, 2021 at 01:38:09PM +0000, Steve Capper wrote:
Hello,
We have an issue installing Debian on some EBBR (Embedded Base Boot Requirements) based systems. Specifically, on EBBR platforms, UEFI SetVariable() is not required at runtime[1] (it is, however, required for boot time services). So, from within Linux, efibootmgr may not work for the end-user; but EFI applications that employ boot time services, would be able to set boot variables.
When working through a Debian install, one workaround we have is to "Execute a shell" when the GRUB install phase throws an error, and then:
# chroot /target
# update-grub
# mkdir /boot/efi/EFI/BOOT
# cp -v /boot/efi/EFI/debian/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi
Before continuing with the rest of the install.
The question from our side is; would it be possible to please put some sort of workaround for EBBR systems into the Debian install logic if EFI SetVariable() fails? For example, a bootaa64.efi could be placed on the target system in the removable path that is either: 1) a copy of grub, or 2) could be an EFI utility that sets the Debian EFI boot variable?
I am curious how the people in charge of this spec were imagining anyone
ever installing an OS on the system?
Perhaps someone should go fix their bad spec instead. I thought the idea
of having UEFI was to finally be able to treat arm systems as pretty
generic and use a normal installer on them and avoid the mess that has
been custom u-boot on arm systems in the past.
But I am just a user. Not like you can even buy any 64 bit arm servers,
since they only ever get announced but never actually become available
to buy unless you are a cloud data center owner apparently. Developers
don't seem to be able to actually get one to work with.