== Why you want a Linux bootloader even on UEFI systems One of the reactions to [[my entry on the complexity of Linux bootloaders BootloadersComplexity]] is to say that all of this is unnecessary on modern UEFI systems. On a UEFI system, you can just put all of your Linux kernel environments in the [[EFI system partition https://en.wikipedia.org/wiki/EFI_system_partition]] and give them (U)EFI boot menu entries to let the user choose between them. Unfortunately there are a number of problems with this on anything except the simplest systems, both in practice and in general. On the practical level, many systems have a very limited number of UEFI boot menu entries, which means that you can only support a handful of kernels and boot environments (for things like a recovery option); how many you can support also goes down if you need a dual-boot system. Often people want to keep a decent number of kernels available, although arguably this is mostly historical at this point. More importantly, UEFI BIOSes have historically been not very happy to have boot entries updated all of the time. Boot entries are EFI variables, and UEFI BIOSes have traditionally assumed that EFI variables wouldn't be updated very often. In addition to the problem of constantly changing the NVRAM, BIOSes have had bugs and problems here, simply because churning through lots of changes is unusual behavior that Windows doesn't do. One general issue is that you are putting things that change and that you need to be available into the EFI system partition, which is a FAT32 filesystem on a single disk. If you want to have a server with redundant disks that can survive (and reboot) after the total failure of one disk, you need to keep your two (or more) EFI system partitions in sync with each other, and also insure that the UEFI boot menu can use both of them somehow. Some people will tell you that you can use Linux software RAID mirroring here with the right magic; in practice, this is reportedly rather fragile (there are many exciting ways for the sides of the mirror to get out of sync with each other, since sometimes they are accessed outside of the software RAID) and may not work with any particular UEFI BIOS. Certainly it's not likely to be something that UEFI BIOS vendors either support or test. Another issue is that UEFI boot menu entries don't necessarily support Linux specific features like modifying the kernel command line, [[which can be necessary in special circumstances Fedora30GrubBLSGotcha]]. In addition to kernel parameters, a variety of Linux initramfs and init systems assume that you can modify kernel command line parameters to control their behavior, to turn on extra debugging messages or to start the system in single user mode or the like. You could do this with additional UEFI boot menu entries, but then you run into practical limits on how many a UEFI BIOS will support and how many people can sort through. So while you can directly load Linux through UEFI with the kernel's [[EFISTUB https://wiki.archlinux.org/index.php/EFISTUB]] support ([[also https://www.kernel.org/doc/Documentation/efi-stub.txt]]), the result is not up to the standards that people want and expect from a Linux boot environment, at least on servers. It might be okay for a Linux machine with a single disk where the user will only ever boot the most recent kernel or the second most recent one (in case the most recent one doesn't work), and if that doesn't work they'll boot from some alternate Linux live media or recovery media.