Restoring EFF booting after a firmware update

Help
1

When I update the firmware on my X1 Carbon (Gen 6) using fwupd, it seems to apply the firmware upgrade on the next reboot attempt, but NixOS no longer boots. There still is an entry in the boot menu for the drive, but it doesn’t work.

I can boot the install USB, mount the system under /mnt and redo the nixos-install. Since everything is there already it does very little, but does fix the ability to boot the disk.

I don’t know much about the EFF boot process. Is there a simpler procedure I can use? I’ve had problems if the USB disk is a older snapshot than the one currently installed on the computer. Is the way to make nixos-install use the channel setup on the /mnt system rather than its own?

2

EFI boot is configured by writing configuration to the NVRAM, which is done as expected.

The issue is that some firmware implementations, on upgrade, will clear the NVRAM to reset everything to defaults. This affects any setting you could have configured in the firmware interface, and more annoyingly, the boot options.

If you’re using grub you could use boot.loader.grub.efiInstallAsRemovable to install it at the default fallback location, meaning that selecting the disk will boot that program.

What I personally do, for bad UEFI implementations (mostly those that reset themselves unexpectedly) is to not rely on the bootloader for boot order, but instead rely on another bootloader that has been built to chainload other EFI programs. This bootloader is rEFInd, and I have some notes on its wiki page.

I basically copy that bootloader on the default fallback location, and that bootloader saves its configuration to the ESP, meaning that even when resetting the NVRAM, it will know which option was last booted. It would also have the advantage of keeping track of the last booted option if you did dual boot.

From rEFInd, you would select the Boot EFI\NixOS-boot\grubx64.efi from ESP option (or equivalent for systemd-boot). It will remember the last selected boot option.

A drawback is that it adds one level of indirection to the boot time, in addition to a long timeout. Its default would add, IIRC, 10 seconds to the unattended boot time. It is possible to configure it to a lower timeout if wanted.

Neither of the option is technically better, but the option to install GRUB “as removable” is probably the better one to reduce complexity in the boot chain.