[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-installer for Arm EBBR systems



(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


Reply to: