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. -- Len Sorensen
