40

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.

Improve this question
12
  • 4
    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, 2013 at 12:22
  • Sounds cool. But since according to that link you can do it if you want, maybe it is a potential quagmire for distros to do it for you automatically. Betcha some will eventually give you the option tho.
    – goldilocks
    Jul 20, 2013 at 12:56
  • 1
    @Bakuriu An easier to understand system, a simpler boot sequence, less executed code and slightly faster boot up time, for instance.
    – Marco
    Jul 20, 2013 at 15:28
  • 4
    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, 2013 at 19:22
  • 1
    @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, 2013 at 9:06

7 Answers 7

Reset to default
10

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.

Improve this answer
3
  • 5
    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.
    – user
    Jul 20, 2013 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, 2013 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.
    – user
    Jul 20, 2013 at 16:35
3

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.

Improve this answer
2

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.

Improve this answer
1
  • your quality assertion is debatable, but i think the reason it s targeted has nothing to do with it anyway. they already have thousands of lines of poorly written shell script to handle it, so why would they want 20 good ones?
    – mikeserv
    Dec 16, 2015 at 9:00
2

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.

Improve this answer
2

The real problem is that people don't understand how it works. For example, in your question you mention that three scripts are all that is necessary, and most of the answers here are about all/any additional maintenance that would be required to make it work - but the truth is you don't need those scripts or any additional work.

All you need is to bind mount the ESP - or wherever you wish to keep the kernel - over /boot, which you can do with a single line in /etc/fstab. Do that and all of the current kernel update scripts will simply continue to work.

My `/etc/fstab' looks like:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

There's a good point made here, though, about manufacturer-specific settings. UEFI explicitly does not specify the interface for a boot menu. That's up for grabs and won't be consistent between machines. It's annoying, but true.

And so, while a loader such as grub actually only makes for more work, a menu application - such as rEFInd - equalizes the differences and simplifies everything.

Improve this answer
6
  • 1
    I don't understand how this could work. Note that the kernel's and initramfs' file names include the version. If there are no scripts you will boot your old kernel after installing a new one. Or phrased differently: How do you change the default kernel to point to the new one? (My scripts use efobootmgr to update the boot order and change the default kernel).
    – Marco
    Dec 16, 2015 at 10:49
  • @Marco - well the default boot path is \EFI\BOOT\BOOTX64.efi and so it could be named for that. the UEFI cant (by spec) handle arguments to the kernel in the first place - and so the initramfs/kernel image need to be bound together in that case. but i dunno what you mean about the version naming - i think only debians do that, and i consider it unproductive anyway. the conventional name for your kernel is vmlinuz. Anyway, the right way to do it is with a boot manager not a loader. Use an EFI app that finds your kernel and passes its name to the EFI to boot - like rEFInd does.
    – mikeserv
    Dec 16, 2015 at 10:54
  • I use Debian and the kernel's name is e.g. vmlinuz-4.2.0-1-amd64 which I leave as it is and then use efibootmgr to add that to the boot list and make it default. I see that naming the kernel BOOTX64.efi might be a solution. But in any way I would need to have a script in order to do that and furthermore that doesn't easily allow to keep multiple kernels if they are all named the same.
    – Marco
    Dec 16, 2015 at 11:00
  • @Marco - you don't need a whole separate script - your package manager - apt, probably - will be running some script anyway when a kernel is installed to build the initramfs. its probably doing a hundred things there to work out your kernel's name already, but just a single extra line will do the rename to whatever you want. and you can easily keep as many kernels as you like if you keep a boot tree. rEFInd handles it by making the default boot image the most recently modified kernel image in its search paths.
    – mikeserv
    Dec 16, 2015 at 11:05
  • Modifying stock scripts installed by the package manager is a bad idea. They might be updated which in turn wipes your changes and - in this particular case - might even result in an unbootable system. There are directories for user scripts that are invoked after a kernel/initramfs installation and that are meant to be used for exactly a purpose like this. BTW: You're suggesting to edit scripts in your comments. However, in your answer you state “you don't need those scripts or any additional work”, which is not true (at least for Debian).
    – Marco
    Dec 16, 2015 at 11:10
0

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: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C%20%20bios&cmpt=q

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.

Improve this answer
1
  • 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, 2013 at 11:43
-2

I think that if booting is handed by EFI only and we remove bootloader then it will be difficult for both HW vendor and Operating System makers. HW vendor will have more kernels to test while for companies that makes OS, it will be like whether their kernel is loaded by different FW.

Moreover with direct booting of kernel from EFI, where in the stack secure boot will fit? In current scenario, once control goes to OS bootloader,then bootloader check whether kernel is signed correctly or not. In case we load kernel directly from EFI then I think that it will create mess only as whole stack will get disturbed. Just an opinion from what understanding I have.

Improve this answer
1
  • that's silly. the reason the bootloader checks the key is because the UEFI doesn't. chain-loading is redundant to secure boot a signed kernel you just check the key in firmware - the way it should work.
    – mikeserv
    Dec 16, 2015 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .