Hi Pascal,
On 21/11/2021 10:53, Pascal Hambourg wrote:
(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.
FWIW, we'd be more than happy to test any approaches out on Arm systems
if that helps.
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
Ahhh! Many thanks for these steps and the clarification on Secure Boot.
Cheers,
--
Steve
