To answer your final question first: When an OS installs on an EFI-based computer, it's supposed to register its boot loader with the EFI, which stores a pointer to that boot loader in NVRAM. Linux distributions use the efibootmgr
tool for this, but other OSes have other tools with similar functionality. (Microsoft extended the bcdedit
tool to register its boot loader with the EFI, for instance.) At least one OS (FreeBSD) doesn't do this, though; it stores its boot loader using the fallback filename (EFI/BOOT/bootx64.efi
), which IMHO is a bad choice -- but if they don't have an equivalent of efibootmgr
, it might be their only option. I don't know of any EFIs that actively scan for bootloaders with arbitrary names, although they do boot to the fallback filename if nothing else is present. Some also treat the Microsoft boot manager (EFI/Microsoft/Boot/bootmgfw.efi
) as a fallback filename.
It sounds as if your EFI and its NVRAM entries have gotten messed up. Ordinarily, I'd recommend resetting the firmware to the defaults in the hope that this action would correct the problem, but you've already done that. Perhaps you should remove extraneous entries with efibootmgr
or something similar and then try resetting the NVRAM. (Do not remove everything, though; I've seen EFIs behave very strangely after all boot entries are removed. OS entries, like for Debian and Windows, should be safe to remove, but leave entries that are clearly hardware-specific, like entries that refer to hard disk models or PXE-boot options.) Removing these entries may leave the computer unable to boot, so having my rEFInd boot manager on a USB flash drive or CD-R may be helpful; you should be able to boot from it and then rEFInd should enable you to boot any OS it detects, which you can then use to re-create working boot entries.
A couple of additional approaches include:
- Remove all hard disks and boot the computer. This may "kick it in the pants" and get it to fix its boot-entry problem.
- Update your firmware. Even an "update" to the exact same version might help (although the update utility might refuse a no-upgrade update). An update might fix a bug that's causing the problem, but just as important, it might reset some variables or storage space that even the reset-to-defaults operation isn't touching.
These are both desperation measures with a small chance of success, so don't get your hopes up. Nonetheless, they're both worth attempting, IMHO. Be prepared with a rEFInd emergency disk, since either might wipe any working boot entries you've already got.
If your system is completely fubared and can't be fixed, then you might try putting your preferred boot manager on the disk as EFI/BOOT/bootx64.efi
and configure it to provide boot options for your other OSes. There are computers that have badly broken EFIs that require this approach even when they're brand-new, and it wouldn't surprise me to learn of EFIs that can be broken to require this workaround despite having worked OK in the past.
1Thanks for the explanation. It seems my EFI got irrecoverably messed up and doesn't let new entries in anymore. I just put GRUB in the fallback location to load my OSs. – ralftoringo – 2017-07-31T13:23:43.593