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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(Adding debian-efi)

Le 18/11/2021 à 14:38, Steve Capper a écrit :

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.

This kind of issue is not specific to the ARM EBBR platform. It also
happens on some UEFI x86 platforms.

grub-install may fail and exit in error when updating the EFI boot
variables for various reasons : insufficient free space in NVRAM, broken
UEFI implementation... On some machines, trying to update the EFI boot variables can even freeze the system and require a hard reboot or shutdown.

AFAICS, the current state is as follows :
- grub-installer does not offer any option to not update the EFI NVRAM, although grub-install and the grub-efi-<platform> support it.
- By default, grub-installer does not install GRUB as the fallback boot
loader in the "removable device path", and only offers the option to do
so in expert mode/low priority (with a rather obscure and deterrent
message).
- In normal (non expert/low priority) installation, grub-install is run automatically.
- When grub-install exits in error for any reason, grub-installer aborts
GRUB setup and does not run update-grub.

As a consequence,
- On systems which freeze when trying to update the EFI NVRAM, the only
way to avoid it is to select expert install/low priority and skip the
GRUB installation step entirely.
- When grub-install failed to update the EFI boot variables, GRUB won't
boot if not installed in the removable device path.
- When grub-install exited in error, even if GRUB boots from the
removable device path it won't display any menu because grub.cfg is missing.

These issues could be mitigated with a few changes to grub-install :
- Offer an option to not update the EFI NVRAM.
- By default, install GRUB in the removable device path if the location
is empty (so it won't silently overwrite an existing fallback boot loader).
- Run update-grub inconditionally even though grub-install exits in error.

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

This won't work if secure boot is enabled. There is a better an simpler
way without using explicitly chroot.
1) The installer has an command to execute a command in the installed
system : in-target <command>
2) grub-install has the --force-extra-removable option to properly
install GRUB also in the removable path and the --no-nvram option to not
update the EFI NVRAM. So the commands in an installer shell would simply
be :

in-target grub-install --no-nvram --force-extra-removable
in-target update-grub

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)