Bootloaders not showing up in UEFI
I'm using a Thinkpad T440p with a single hard drive, it's set to UEFI only mode (Secure Boot disabled). Any time I used to install an OS corresponding entries would show up in UEFI to boot those OSs.
This time when I installed Debian 9 and Windows 10 no entries showed up. I can still boot both systems by copying grub to /EFI/Boot/bootx64.efi on the EFI parition and then telling UEFI to boot the hard drive.
How can I get UEFI to show entries for /EFI/debian/grubx64.efi and /EFI/Microsoft/Boot/bootmgfw.efi again?
Reseting UEFI did not change anything. Using efibootmgr on Linux to manually add the entries creates entries that show up in efibootmgr (marked as active) across reboots, but they don't show up in the actual UEFI and can therefore not be used.
What's the mechanic behind this? Is an OS installer supposed to add an entry to UEFI or is UEFI supposed to automatically find new .efi files in the EFI parition?
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.