Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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?


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.

share|improve this question
Why should they? They have already established methods for dealing/generating grub configuration file. Furthermore it helps if all systems (non-UEFI & UEFI) behave the same. – Ulrich Dangel Jul 20 '13 at 12:22
@Marco this also means that your kernel has to be compiled with this feature and may not work on other systems without efi (not sure if you can load an efistub kernel on a normal grub system). From my POV it only has disadvantages for a distribution. – Ulrich Dangel Jul 20 '13 at 13:49
@Bakuriu An easier to understand system, a simpler boot sequence, less executed code and slightly faster boot up time, for instance. – Marco Jul 20 '13 at 15:28
This question should be put off-hold, since the hold reason given is wrong. The question does have a simple uncontestable answer: UEFI does not provide a boot menu. Some implementations do. Some don't, because in order to reach their target boot time for Windows 8, the BIOS does not even initialize input devices. Let alone wait to see if the user presses a key. So you'd have to go through Windows to get to Linux, or vice versa. The former works on some systems, but I doubt the spec guarantees it. The latter doesn't work (you can enter UEFI setup from GRUB, but not from Linux). – sourcejedi Jul 20 '13 at 19:22
@sourcejedi You claim does not match your sources. UEFI does provide a boot menu (UI inconsistent across vendors though). mjg59 meant you can't get to boot menu without philosophical compromise (accepting W8 EULA). But this problem will be the same for installers with non-EFISTUB grub bootloaders. So it doesn't answer why we'd prefer grub over EFISTUB either. – Lingzhu Xiang Jul 21 '13 at 9:06

5 Answers 5

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.

share|improve this answer
Not only is it irritatingly time consuming to test, it is the most irritating code possibly to go wrong. Consider: what do you prefer, some sort of issue while the system is up and running mostly normally, or not being able to even boot the system? The boot loader is definitely one of the pieces of software I feel most strongly about not touching unless it's necessary. – Michael Kjörling Jul 20 '13 at 13:43
The above comment by @MichaelKjörling should be in an Answer. Switching to a new boot loader is very very risky. Distro-creators want their users to have a good experience, but more than that, they want everey single potential new user to have a flawless first time experience. I am sorry that I called distribution a "distro", but it felt OK in conjunction with creators. – Johan Jul 20 '13 at 15:38
@Johan msw is free to edit that point into the answer, I don't mind. (It isn't enough to be an answer on its own, IMO.) Both Tobu and goldlilocks touch on the issue as well. – Michael Kjörling Jul 20 '13 at 16:35

Distros have limited resources and there may not be any reasons at all beyond that. It may be reasonably simple and safe, but no matter what it will require more maintenance work because the grub option must be maintained, if only for non UEFI systems.

I'm sure everybody has a list of features and options they'd like to see distros adopt (I'll give you a few pages, lol), and no doubt many of those would be "totally easy, no hassles, honestly...". However, there is not an infinite amount of person hours to implement them. When faced with decisions like this ("Do we we put work into this feature, vs. some other?") primary questions should be:

  • Is it necessary? (The answer here is no).
  • How many people will benefit, and how much? (IMO: a few, and not much)
  • Is there a reasonable alternative by way of which the user can accommodate his/her self without us doing anything? (Apparently there is.)

The reason people use distros at all is because everyone is subject to resource constraints (otherwise, just hire a team, buy them some space and equipment, and have them do everything for you exactly how you want). So the reality is that the distros reflect the generalized needs of their users.

That said, I do think this will in time be adopted as an option, and I upvoted the question.

share|improve this answer

Targetting UEFI bootloaders in addition to grub would complicate quality control and support. The distros are targetting grub rather than the UEFI spec because grub is free software, hackable, more flexible, and high-quality. You can still get a pure-UEFI boot by following a tutorial and mounting the UEFI partition on /boot, because if you do that, the maintenance is on you.

share|improve this answer

They chain the UEFI and GRUB as a temporary implementation solution.

As UEFI support and the accompanying issues (eg Secure Boot) get resolved, more and more distributions will use it directly. In the mean time this is still very new: Google Trends shows rather limited adoption:

Others have all mentioned potential pitfalls of going for a pure UEFI solution and/or supporting both non-UEFI and pure UEFI systems simultaneously. A UEFI kernel might work on a non-UEFY system, but the kernel update tools need to update either a GRUB menu OR a UEFI boot menu OR both, etc etc.

It realy is about quality control as mentioned: importantly problems with this code have a high impact: When the computer fails to boot new users, i.e potential Linux converts, will ditch it as garbage and go back to something "safe".

But as I said as the technology gets more adoption it will become the standard.

share|improve this answer
I hope not - but that's mostly because I have severe concerns about UEFI's lockdown modes and Microsoft's "promise" to make sure there'll always be a signed image for linux to use... – Shadur Jul 23 '13 at 11:43

Extra code is necessary to work around firmware bugs

When not chaining grub, the distribution is relying more upon the firmware to correctly boot. As any software will have issues, firmware is also prone to that. Now the Linux distributions will have to write to workaround these firmware bugs too.

A real life case as an example. The Asrock H81 pro BTC P1.80 motherboard allows the creation of boot menu entries with efibootmgr. There can be multiple boot menu entries created, and boot order can be changed using efibootmgr --bootorder XXXX,YYYY,ZZZZ or a temporary next boot option can be set using efibootmgr --bootnext XXXX. Both these command return output which gives you the idea that boot order has changed or next boot will run, for example BootNext: XXXX. However on reboot the stubborn firmware just ignores the newly requested boot option and reboots into the previous BootCurrent: value. A permanent boot order change can only be made from firmware setup utility. And a non permanent change is not available at all.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.