Why do most distributions chain UEFI and grub

bootboot-loadergrub2uefi

Most distributions install a additional boot loader on an UEFI system. UEFI
itself is a boot loader, it offers a menu to select different operating
systems or individual kernels. Furthermore, the UEFI settings can easily be
altered with userspace tools like efibootmgr.

Kernels since 3.3 support EFI_STUB, which means the kernel can be loaded
directly from the UEFI. What's the reason distributions decide to use an
additional boot loader? Most tutorials on Linux/UEFI focus mainly on how to
set up the additional boot loader (rEFInd, grub2, ELILO, etc.) instead of
booting Linux with EFI_STUB.

The only thing missing in the distributions is support. Since most
distributions chain a second boot loader, the kernel is not added to
the UEFI boot menu, nor is it copied to the EFI system partition.

Three scripts are sufficient to do all the magic. One which copies
the initramfs to the ESP. A second one copies kernel to the ESP and
creates a new entry in the UEFI boot menu. The third script removes
the old kernel and initramfs from the ESP and deletes the UEFI boot
menu entry. This allows fully automatised kernel/initramfs
updates/purges without user interaction. I am using this approach
since more than a year and it has worked flawlessly.

Why do most distributions use grub instead of EFI_STUB?

Links:

EDIT: I'm not talking about removing grub support entirely but to offer a
choice for those who want to use it for various reasons. Distributions could
provide a package grub-efi for those who want to chain UEFI and grub and a
package efistub-boot which contain the scripts I mentioned above.

Best Answer

Given that UEFI was only defined in 2005 there is a bunch of legacy equipment out there that doesn't support the spec. To add UEFI to a standard distribution would require testing of two code paths instead of one, and not only is boot code notoriously finicky, it's one of the most irritatingly time consuming bits of code to test.

Related Question