[Installation] UEFI boot entry not generated, despite installation being successful

[Enigma83]

So, I recently swapped out my laptop's SSD to a smaller 1TB, with the intention of single booting Debian only, without Windows. The ultrabook is Dell XPS 13 9360.

The partition layout is simple, I manually created it in Parted Magic before installing from the Bookwork netinstall iso. It consists of an efi system partition, a boot partition, followed by partitions for root, home, and swap, with some unallocated space at end of disk for SSD overprovisioning. Partition table is GPT. The drive is a newly bought Samsung 980 NVMe, but I doubt it's playing a role in the issue.

The install went normally and without obvious errors. But at the end I rebooted, only to see a small text message saying that no bootable devices are present. In the BIOS, there were no UEFI entries. In Parted Magic, all partitions look fine and are populated with what seems to be the appropriate files (kernel, initrd, efi files, root filesystem, etc). I also noticed that that efi partition had a Debian directory, but no fallback bootloader (EFI\boot\bootx64.efi) that all BIOSes should find if there are no valid entries. At this point, I can go into BIOS and manually add an entry pointing to Debian's GRUB efi file and be done with it, but I'm more interested in what the cause is. I can also boot Debian from an external helper tool, like Ventoy or a rEFInd CD iso.

When dualbooting with either Windows 10/11, most of the time the installer would generate a valid entry, but not in a few cases. With Debian alone, an entry never gets generated no matter how many times I've tried. And regardless of manual partitioning vs automatic. I know that there is nothing wrong with the installed OS since it can be externally booted, so reinstalls aren't necessary, they were only done for testing.

I think if the Debian maintainers would default to additionally installing a fallback bootloader efi file, this issue would be very rare or nonexistent. Windows does it by default, and so do a lot of other distros. I do believe the fallback bootloader is officially listed in the UEFI Specification as a way to mitigate buggy/inconsistent BIOSes. Surely they must have a valid reason for not doing so, on top of the Debian directory in the efi partition. Or default to installing a fallback bootloader only if it doesn't exist already, to avoid overwriting an efi file placed by another OS.

[fabien]

Hello,

I think if the Debian maintainers would default to additionally installing a fallback bootloader efi file, this issue would be very rare or nonexistent. Windows does it by default, and so do a lot of other distros. I do believe the fallback bootloader is officially listed in the UEFI Specification as a way to mitigate buggy/inconsistent BIOSes. Surely they must have a valid reason for not doing so

They do have a valid reason

Force grub-efi installation to the removable media path

Many UEFI firmware implementations are unfortunately buggy, as mentioned earlier. Despite the specification for boot entries and boot order being quite clear about how things should work, there are lots of systems in the wild which get it wrong. Some systems simply ignore valid requests to add new boot entries. Others will accept those requests, but will refuse to use them unless they describe themselves as "Windows" or similar. There are lots of other similar bugs out there, suggesting that many system vendors have done very little testing beyond "does it work with Windows?"

As described above, on a UEFI system bootloaders should be installed only in the correct vendor-specific directory in the EFI System Partition (ESP). But, because of the buggy firmware implementations out there, operating system distributors cannot necessarily expect that this will work correctly for all systems. Microsoft have worked around this (and arguably also made the problem worse) - the Windows installer also installs to the removable media path in the ESP (e.g. \EFI\boot\bootx64.efi for amd64/X64 systems). All firmware implentations have to use this path to be able to run an OS installer. This means that Windows will always work on all these broken implementations, but it also means that system vendors can get away with shipping broken implementations. It removes the idea of having a fallback boot path and sensible control of boot order.

All OS installers installing things to this removable media path will conflict with any other such installers, which is bad and wrong. That's why in Debian we don't do this by default.

However, solutions are proposed

However, to help support those unfortunate people who own buggy systems like this there is an option to force grub-efi installation to the removable media path too. There is a d-i Rescue Mode option to force this - if you've just installed Debian on your UEFI system but it won't boot Debian afterwards, this may fix the problem for you. It can also be selected during the normal installation run using Expert mode, or preseed users can add the following option in their configuration (for amd64, tweak the package name to suit on other architectures):

grub-efi-amd64 grub2/force_efi_extra_removable boolean true

You can also select this by using dpkg-reconfigure grub-efi-amd64.

[flamur]

...There is a d-i Rescue Mode option to force this - if you've just installed Debian on your UEFI system but it won't boot Debian afterwards, this may fix the problem for you...

I had this problem = installed debian 12, restarted and my computer cant find any OS.

How do I use the d-i rescue mode? How do I access it and use it? (totally new to linux/debian)

[Enigma83]

This issue seems to be fixed with the newest Debian netinstall 12.6.0 iso. I recently did a clean install on the Dell, it generated a UEFI boot entry just fine. With the older 12.5.0 netinstall iso, a proper entry wasn't created despite installation succeeding. I followed exactly the same install steps I had taken before, but reused my existing partition layout after formatting them and manually deleting old entries of no longer existing OSes.