Missing fallback bootloader (EFI/BOOT/bootx64.efi) leads to unbootable system after NVRAM loss

[Mitroshenkov87]

Problem:
After installing AnduinOS and performing initial setup (which included MOK registration), the UEFI boot entry for AnduinOS disappeared from the boot menu. The disk and all system files were intact, but the system was unbootable because no fallback loader existed at EFI/BOOT/bootx64.efi. Recovery required booting from a Live USB and manually reinstalling GRUB.

Steps that led to the issue:

Installed AnduinOS on an internal disk (btrfs with subvolumes), Secure Boot enabled.
Performed initial setup which triggered MOK registration.
After reboot, AnduinOS was gone from the UEFI boot menu.
The system was completely unbootable until the fallback bootloader was manually created.
Root cause:
The installer only created an NVRAM boot entry (\EFI\AnduinOS\shimx64.efi) without a fallback copy at EFI/BOOT/bootx64.efi. MOK registration appears to have wiped or overwritten the NVRAM entry, leaving no way for the firmware to find the bootloader.

This is not specific to one manufacturer. Similar NVRAM-related boot failures have been reported on:

ASUS — NVRAM entries cleared during MOK operations or firmware updates
Acer — boot entries disappear on every reboot
Lenovo/ThinkPad — BIOS/UEFI updates reset NVRAM completely
HP — firmware removes GRUB entries if not on the same disk as Windows
Intel-based boards — some chipsets ignore non-Windows NVRAM entries entirely
Various — NVRAM can fill up from MOK/dbx entries, preventing new boot records from being saved
Proposed fix:
Run grub-install --removable by default during installation, or provide a checkbox (enabled by default) in the installer. This ensures a signed fallback loader exists at EFI/BOOT/bootx64.efi, so the system remains bootable even when NVRAM is wiped.

Why it matters:
Windows always installs a fallback bootloader, which is why it survives NVRAM loss. Since AnduinOS aims to be a user-friendly, Windows-like Linux experience, this fallback should exist by default. A new user coming from Windows would likely perceive the OS as broken and abandon it — they cannot even manually select the disk in UEFI, because the firmware looks for .efi files, not disks.

Environment:

Device: ASUS laptop
Disk: internal, btrfs with subvolumes
UEFI: Secure Boot enabled
Trigger: MOK registration during first-time setup

[Anduin2017]

Will take a look soon. Thanks for reporting.

[Anduin2017]

Hi @Mitroshenkov87, thank you for the detailed report—and especially for recovering the installation and explaining exactly what was missing. You have identified a real gap in our boot resilience: an ordinary internal UEFI installation currently relies on its AnduinOS NVRAM entry and does not install an EFI/BOOT/BOOTX64.EFI fallback chain. If that entry disappears, the files on the disk can remain perfectly intact while the machine becomes difficult or impossible to boot normally.

There is an important reason we did not simply enable GRUB's removable-media installation for every system. In issue #422, a machine booted the UEFI OS fallback entry and repeatedly displayed “Reset System” instead of starting AnduinOS. GRUB's generated removable-media chain can include shim's fallback application, which attempts to recreate an NVRAM entry and reset the machine. On affected firmware, that path can be selected again after the reset, producing a loop. We changed the installer to create and verify the normal \EFI\AnduinOS\shimx64.efi NVRAM entry explicitly, while disabling GRUB's automatic extra-removable chain. We also must not blindly overwrite EFI/BOOT on an ESP shared with Windows or another OS.

So we agree with the problem you raised, but we do not plan to apply grub-install --removable unconditionally or add a default-on checkbox that invokes it. That could reintroduce the #422 boot loop or replace another system's fallback loader.

The direction we are considering is a more controlled fallback for installations where AnduinOS owns a dedicated ESP: keep the normal NVRAM entry, then separately install a direct, Secure-Boot-compatible chain in EFI/BOOT—signed shim, signed GRUB, MokManager, and the matching GRUB configuration—without shim's NVRAM-recreating fallback application. We already use this approach for external, whole-disk installations; extending it safely to eligible internal installations is a plausible next step. Shared-ESP/coexistence installs need a separate policy so we do not overwrite another OS's files.

Before changing the installer, we want to test both sides of this carefully: boot after deleting the AnduinOS NVRAM entry, boot after MOK enrollment, Secure Boot on and off, and systems with a shared ESP. We also want to distinguish why your entry disappeared. Its disappearance after MOK enrollment is clear from your report, but without before-and-after firmware records we cannot yet conclude that MOK enrollment itself deleted it; firmware boot-order changes or NVRAM persistence problems are also possible. If you happen to have efibootmgr -v output from before or after the incident, or the ASUS firmware version, that would help us narrow it down—but the missing fallback is worth addressing regardless.

Thanks again for bringing this up. Your report exposes a genuine recovery gap, and we would rather fix it without reopening the boot-loop problem we encountered previously.