[solved] efibootmgr vs. gummiboot - What's the significant difference?

zacariaz · 2013-08-18 18:20:27

This question may seem odd, so let me explain.

My laptop, a Lenovo IdeaPad y500, has a SSD on sda and a HDD on sdb which is all fine and dandy. However, when having the EFI System partition on sdb, it's impossible to get it to boot using efibootmgr, at least by any means I know of, and I've tried just about anything, however using gummiboot it works flawlessly.

Now, I don't mind using gummiboot, but I don't need an actual boot loader/manager, at least I should not think so and I have to wonder what is actually different between the two approaches.

One thing I have noticed it that gummiboot have created two apparently identical entries to NVRAM; "Linux Boot Manager" and "EFI HDD Device", which seems rather odd.

If not for anything but curiosity, I'd very much appreciated if anyone could shed some light on this.

Best regards.

edit:

Never mind for now. I think I've got an idea.

edit 2:
Upon further consideration, it's probably not as odd as I first thought, not to say that I understand it.

Last edited by zacariaz (2013-08-19 05:52:59)

cfr · 2013-08-18 18:27:04

You'd need to post the output of efibootmgr -v and maybe lsblk -f to see why a direct entry might not be working.

Are you sure gummiboot created both entries?

Generally, a boot manager (gummiboot or rEFInd) gives you a menu so you can select different boot options and, sometimes, tools e.g. EFI shell. It also allows you to edit the kernel command line parameters should you need to do so. It still uses the EFI stub loader built into the kernel to boot, though, just like a direct entry does. (Boot loaders, on the other hand, don't use the stub loader - e.g. grub, syslinux.)

There are some... quirks, eccentricities, outright bugs affecting many, many UEFI implementations and that one thing works and another not may be something nobody is able to explain without doing a lot of diagnostic work.

zacariaz · 2013-08-18 18:39:03

cfr wrote:

You'd need to post the output of efibootmgr -v and maybe lsblk -f to see why a direct entry might not be working.
Are you sure gummiboot created both entries?
Generally, a boot manager (gummiboot or rEFInd) gives you a menu so you can select different boot options and, sometimes, tools e.g. EFI shell. It also allows you to edit the kernel command line parameters should you need to do so. It still uses the EFI stub loader built into the kernel to boot, though, just like a direct entry does. (Boot loaders, on the other hand, don't use the stub loader - e.g. grub, syslinux.)
There are some... quirks, eccentricities, outright bugs affecting many, many UEFI implementations and that one thing works and another not may be something nobody is able to explain without doing a lot of diagnostic work.

I'm quite sure I've got two identical entries with different names.

Next time I get a chance, I'll be sure to post the needed output, but for now I'm working on getting bcache to make sense, so it may take a bit.

Thanks for the feedback.

WonderWoofy · 2013-08-18 18:41:11

You should use a boot manager. It is really the convenience that makes them worth while. If you create a direct efibootmgr entry (a firmware entry straight to the kernel/efistub) then you don't have a really easy way to change the kernel command line in the even that you might need to. You can obviously create a new efibootmgr entry, but of course that requires that you are booted from a running system. Say for example, that a kernel update has rendered your system unbootable, and now requires a special kernel command line parameter in order to get things working right. It is a whole hell of a lot easier to simply edit the kernel command line from the boot manager (gummiboot or rEFInd) than it is to try to find a way to get an efibootmgr entry in there.

I have heard the argument from some that the direct efibootmgr entry is faster. I will admit that indeed it is slightly faster. But as an example, my last boot took gummiboot 14ms to load itself before handing control off to the kernel/efistub. This, in my mind, makes the difference in speed a lousy argument. My firmware typically takes about 1.7s to get throug POST, so adding an additional 14ms is hardly worth mentioning.

If you don't think you need to see the menu when you boot, with gummiboot you can actually set the parameter "timeout 0" (or just omit "timeout" altogether) and you won't see it at all. There will be no waiting for a countdown to the default entry or anything. If you want to get to the boot manager menu (if you need to choose a different boot entry or change the kernel command line), you can simply hold any key before gummiboot gets loaded and the menu will show up. Of course, you can't hold any key that is significant to your firmware, like F1 on my machine will take me to the bios settings and F12 will give me the firmware's boot manager. But any other key will do. Unfortunately, rEFInd does not have this ability, so you have to have a timeout of at least 1 (second) in order to be able to see/change the things in the boot manager menu.

cfr is right about bugs though. It is probably a good idea to actually also have an alternative boot solution in place that does not rely on efistub. So something like grub-efi, elilo, or syslinux-efi is good to also have set up just in case.

Edit: Also, I am almost postivive gummiboot didn't make the second entry. It will only make itself a "Linux Boot Manager" entry, and that is it. On my machine though, it did for some reason push the "setup" option out of spot 0000, so the setup option had to remake itself as a different number. Maybe this is the case for yours as well (the entry was there before, it is just now numbered differently)? Of course, again, like cfr said, unless you can give us the output of "efibootmgr -v" to compare the actual contents of the entry, there is no way to know for sure.

Last edited by WonderWoofy (2013-08-18 18:43:53)

zacariaz · 2013-08-18 19:18:22

WonderWoofy wrote:

... SNIP! ....

You're absolutely right, a boot manager does make life easier, this was more a matter of interest really, and I will return with more info when I can. Am still strugling with bcache.

As for the double entry... Well, if gummiboot didn't make the second one, I don't know who did. I certainly did and both entries booted the system jsut the same.

srs5694 · 2013-08-19 02:25:16

AFAIK, gummiboot itself doesn't change the NVRAM entries; however, Arch's gummiboot-efi package does add the gummibootx64.efi binary to the system's NVRAM. Thus, gummiboot is unlikely to have created that second entry, although it's conceivable that installing or upgrading the gummiboot-efi package might conceivably do so.

In my experience, EFI boot manager entries with names like "EFI HDD device" are typically created by the EFI itself to refer to the fallback boot loader (EFI/BOOT/bootx64.efi) on the disk. You haven't said why you think this entry is identical to your gummiboot entry, but if it's simply that both entries launch gummiboot, that's probably because you've got a duplicate of gummiboot in the fallback filename position. The "efibootmgr -v" output that cfr has requested will help clarify this matter. So might the following command:

ls -l `find /boot -iname "*.efi"`

zacariaz · 2013-08-19 05:52:34

srs5694 wrote:

AFAIK, gummiboot itself doesn't change the NVRAM entries; however, Arch's gummiboot-efi package does add the gummibootx64.efi binary to the system's NVRAM. Thus, gummiboot is unlikely to have created that second entry, although it's conceivable that installing or upgrading the gummiboot-efi package might conceivably do so.
In my experience, EFI boot manager entries with names like "EFI HDD device" are typically created by the EFI itself to refer to the fallback boot loader (EFI/BOOT/bootx64.efi) on the disk. You haven't said why you think this entry is identical to your gummiboot entry, but if it's simply that both entries launch gummiboot, that's probably because you've got a duplicate of gummiboot in the fallback filename position. The "efibootmgr -v" output that cfr has requested will help clarify this matter. So might the following command:
ls -l `find /boot -iname "*.efi"`

Sounds sensible.

forumache · 2013-10-17 20:26:41

WonderWoofy wrote:

You should use a boot manager. It is really the convenience that makes them worth while. If you create a direct efibootmgr entry (a firmware entry straight to the kernel/efistub) then you don't have a really easy way to change the kernel command line in the even that you might need to.

It makes sense to use a boot manager. But I don't use one, as I like to boot as fast and uncomplicated as possible. I have a .nsh script just in case in my UEFI partition. I can edit and launch it manually from the UEFI v2 shell. My BIOS(?) allows me to choose the UEFI app. If something is wrong with the normal boot I can choose to boot in UEFI shell, edit (if necessary) and launch the .nsh file.

Just my case scenario

Arch Linux

#1 2013-08-18 18:20:27

[solved] efibootmgr vs. gummiboot - What's the significant difference?

#2 2013-08-18 18:27:04

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#3 2013-08-18 18:39:03

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#4 2013-08-18 18:41:11

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#5 2013-08-18 19:18:22

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#6 2013-08-19 02:25:16

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#7 2013-08-19 05:52:34

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

#8 2013-10-17 20:26:41

Re: [solved] efibootmgr vs. gummiboot - What's the significant difference?

Board footer