What are the implications of not installing a Linux boot loader and use UEFI instead?

Question

Before UEFI, installing a boot loader was necessary to boot an OS, with the introduction of UEFI, many UEFI firmwares come with a decent boot manager and boot loader that allow the user to boot the OS directly from it.

By not installing a boot loader like GRUB, what are the implications?

Answer 1

with the introduction of UEFI, many UEFI firmwares come with a decent boot manager and boot loader

This is only half true. (Less than half, depending on your definition of "decent.") There are two types of programs, the names of which are often used interchangeably, but which are really quite different:

• Boot managers -- These tools present a menu or some other type of user interface that enables users to select a boot option, which the boot manager then executes. These are fundamentally user interface tools. Something that is only a boot manager is inadequate for launching an OS; something else is needed for that....
• Boot loaders -- These tools load an OS kernel (and often extra things, like a Linux initial RAM disk [initrd] file) into memory and give the kernel control of the OS. A boot loader does not need to have any user interface elements; it's just is a purely technical one of transferring control to an OS.

GRUB, and many other BIOS-mode programs like it (LILO, SYSLINUX, etc.) provide both boot manager and boot loader functions. In the EFI world, though, these functions are more often separated. The firmware's built-in boot manager is just that -- a boot manager. It cannot launch an OS kernel by itself. There are also add-on boot manager programs, like rEFIt, rEFInd, and gummiboot/systemd-boot, which are easier to configure, prettier, or otherwise more full-featured than the typical built-in EFI boot manager. Tools that are purely boot loaders also exist. In some sense, this is true of ELILO and the EFI version of SYSLINUX; although they can present menus to enable you to pick a Linux kernel, they can't chainload to another EFI program, which is what you'd need to launch Windows or macOS. The EFI version of GRUB, like its BIOS counterpart, functions as both a boot manager and a boot loader. See my page on the subject for more on EFI boot loaders and boot managers for Linux.

There is one more twist in this story: Since version 3.3.0, the Linux kernel has included a feature called the EFI stub loader. This feature effectively turns a Linux kernel into its own boot loader -- the kernel can be launched like any other EFI application, so the EFI boot manager can launch a Linux kernel directly. (This feature enables rEFInd and gummiboot/systemd-boot to function much like GRUB in the boot process, too.) Launching the kernel directly from the EFI boot manager has several drawbacks compared to using GRUB, rEFInd, or some other boot manager/loader:

• Kernel location -- The kernel must live somewhere that the EFI can read. On most PCs, this means a FAT partition. (On Macs, HFS+ will work, too.) Few distributions set things up this way by default, and some rely on filesystem features like symbolic links in the kernel's directory for one feature or another, so using FAT is likely to be a poor choice. There are EFI filesystem drivers for other filesystems, but getting them to load automatically is likely to be a pain that would further complicate matters. (rEFInd makes this easy, so rEFInd can launch kernels from several Linux-native filesystems, even though it's using the same EFI calls behind the scenes.)
• Lack of OS support -- Few distributions provide setup scripts or other tools to help in managing a kernel installed in this way. Thus, you're likely to have to keep copying kernels, and maybe modifying the NVRAM-based EFI boot manager entries, whenever you update a kernel.
• Ease of configuration -- The efibootmgr program and the way options are passed to kernels are both finicky; a single typo can result in an unbootable system. By contrast, GRUB installations include scripts that usually get these details right, and rEFInd includes code that usually gets such details right when it scans your kernels. Other boot loaders and boot managers usually rely on text-mode configuration files that are, if not easy to set up, at least less finicky than the efibootmgr commands you must use to configure booting your kernels directly.
• Delicacy -- Many computers' NVRAM entries are delicate; they can be damaged or deleted by accident. Because these entries must include more than just the kernel's filename (most distributions require options like the root filesystem identifier), re-creating an entry once it's been lost can be more of a pain than it would be if you relied on GRUB or some other boot program.
• Lack of boot-time options -- GRUB, rEFInd, gummiboot/systemd-boot, and most other such tools provide boot-time options that are lacking from a typical EFI boot manager. For instance, there may be options to reboot the machine into its firmware setup utility; and you can usually edit the options passed to the kernel on a one-time basis. In some ways, this point is another way of saying that most EFIs' built-in boot managers are not "decent," although of course that's a subjective matter, and some computers' built-in EFI boot managers are better than others. If you want something bare-bones, you might be happy with the built-in boot manager; but you can also configure other boot loaders and managers to present a minimal user interface or to boot straight into your default selection with little or no delay.
• Secure Boot support -- Most distributions ship with the Shim EFI program, which makes the distribution compatible with Secure Boot. You can add this program to a boot path involving other boot loaders, with a little extra effort. The level of effort required to boot a kernel directly with Secure Boot is a bit greater if you use Shim, and much greater if you want to boot really directly, without Shim.

The advantages of booting in this way can be summed up as follows:

• A shorter boot path -- By bypassing GRUB or other boot programs, you are indeed making the boot path shorter. Technically, though, you aren't eliminating the boot loader -- the kernel's EFI stub loader is the boot loader. It just happens to be built into the kernel. This advantage is pretty slim. It translates into a marginally shorter boot time, but that's about it, from a practical perspective.

In sum, it is possible to boot an EFI-based computer into Linux directly from its EFI boot manager, bypassing GRUB, rEFInd, SYSLINUX, or other boot loaders or boot managers. Doing so is, IMHO, more of an expression of mastery over your computer than a practical option, though; the drawbacks and extra effort required to configure the system in this way far outweigh any advantage it might offer.

Answer 2

There are no "implications" that I am aware of, other than you need access to an EFI shell and good knowledge of the EFI shell. I got rid of GRUB2 and other multiboot loaders years ago and have yet to run into a problem.