grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

graysky · 2012-09-07 21:25:49

tl;dr - In my experience an EFI boot is less robust and more of a headache than a BIOS boot. What is the advantage of an EFI boot?

Recently, we had some pretty strong thunderstorms which prompted me to unplug my systems. After plugging my work station back in when the storm passed, I found that I couldn't boot via EFI: the system kept returning to my BIOS indicating I had no valid EFI options. I could drop down to the EFI shell and see the files just fine, I just couldn't boot off the SSD. I returned to grub_bios after booted from a live CD and all is well.

bsilbaugh · 2012-09-26 03:16:19

For the official answer, you should read the intel docs. The ArchWiki also has a nice overview here.

I'm currently booting Arch on my MacBook (5,1) using the kernel UEFI stub loader, and rEFInd as my boot manager. So far, I haven't had any troubles with EFI. However, as is discussed in the rEFInd documentation, EFI/UEFI is still a rather new standard; therefore, there are bound to be some "teething" issues as the firmware and kernel developers build up experience implementing UEFI. In other words, don't be too quick to conclude that UEFI is a bad idea because of a bad implementation.

Also, keep in mind that BIOS, and it's companion the MBR, are limited in regards to disk size and number of partitions. So, if you want a hard drive larger than 2TB, or would like more than 4 primary disk partitions, you have no choice but to use EFI and GPT.

Lastly, EFI/UEFI is being adopted by a large number of manufacturers. So, like it not, it's here to stay.

In regards to your particular problem, I wonder if the power outage somehow reset your firmware such that your boot loader was no longer registered. Did you try re-registering your boot loader? On Apple systems this is done using the "bless" utility, and the "efibootmgr" utility for non-Apple firmware. (Apple uses a "tweaked" version of EFI.)

ratcheer · 2012-09-26 12:13:12

bsilbaugh wrote:

Also, keep in mind that BIOS, and it's companion the MBR, are limited in regards to disk size and number of partitions. So, if you want a hard drive larger than 2TB, or would like more than 4 primary disk partitions, you have no choice but to use EFI and GPT.

For this part of your answer, not true. I am using a large hard disk with GPT, but I still use MBR boot. GPT does not require EFI.

GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Tim

JLloyd13 · 2012-10-12 19:35:06

personnilly I just like not having to worry about extended partitions etc. easy to have like a bunch of distros multibooting without going in to extended partitions. its not big, but its nice. but yeah getting grub-efi to work was a real pain. even now my boot menu isn't labled right I just havent had the time to fix it

mynis01 · 2013-01-07 00:01:41

It was somewhat painful to get the hang of at first but now I have the procedures memorized. More than anything, I just use UEFI because it is going to be implemented in all new systems eventually, so I might as well get used to it now.

WonderWoofy · 2013-01-07 00:19:31

I think that many people apparently confuse UEFI with GPT. As stated above, you can definitely use GPT with bios booting. And MBR with UEFI. They are separate, one is the partitioning type and the other is a firmware type.

Graysky, two answer your question, I use UEFI because I wanted to learn about it. It was a lot to take in, but I guess that is kind of how it was to learn about MBR/bios back when I did. Overall, I really like the idea of the EFI System Partition and its ability to simply hold efi applications. At this point in time, I don't think that there is really a specific advantage to it. I do like how I wouldn't have to chainload if I were to be a windows user.

I guess this question makes me kind of wonder what you mean specifically when you say that EFI is less robust? Is there functionality with bios that you don't get with UEFI?

I think in the end, it really is just whatever you prefer. I have my UEFI set up, but I am still slightly afraid of something like what happened to you. So I do keep syslinux installed and set to boot up my Arch Linux installation. So that I can set it back to legacy bios and not have a problem if I need.

There was one time that I accidently hit the button to restore the bios to defaults instead of the save and exit button because they are right next to each other. I lost all my efibootmgr entries, but luckily I had the foresight to keep the UEFI Shell as /EFI/boot/bootx64.efi.

scjet · 2013-01-19 17:16:23

"what is the value of an (u)EFI system" - So far, and I own 2 of them now - absolutely NONE.
It was "supposed" to replace our 30-year old patched-to-hell BIOS, with the obvious advantages of keeping up more efficiently with many of today's infinitely newer PC technologies, not to mention better glueing of -as compared to way back when with the "...BIOS's long-standing problems ..." ? But instead, it has failed, so far, even to do any of that.
oh wait - GPT ? -Lol.

http://en.wikipedia.org/wiki/Unified_Ex … _Interface It's as straight-forward as you can get.
Check out, especially, the Section(s) on
"Criticism"
"Secure Boot"

-there's even much more than that, if you look around, and really dig, but imho, right, as far as "PC's" are concerned, it's a dismal failure, as well as yet another ploy by the only "2" Big Commercial/Proprietary OS's Corps' to control what you install on your PC, Laptop, unless you pay the "toll" fee, ... -yep, it's a FAIL, any way you look at it, right now.
sorry.

Last edited by scjet (2013-01-19 17:22:56)

WonderWoofy · 2013-01-20 03:53:06

I use UEFI, and I can partially agree with scjet that I think using uefi in itself has no clear advantage.

But this

scjet wrote:

oh wait - GPT? -Lol.

Seriously? You think that extended partitions are a better solution? Also the backup GPT at the end of the disk has actually saved me once, something which the MBR would have just failed completely at. So I fail to see how this is not better.

cfr · 2013-01-20 04:15:46

I use UEFI because I insisted on using GPT. Apparently my firmware will not boot a GPT disk in BIOS mode. (At least, not if it is the internal disk - I think I managed to do this with a USB key formatted that way when experiementing.)

I am not sure the UEFI is really more complicated to learn than BIOS for booting. I found both pretty difficult at first. It was a long time since I'd even had a machine with a BIOS. I knew how to use yaboot and a tiny amount about Open Firmware (what everyone knows about Open Firmware, I expect).

I also knew nothing really about MBR or GPT. But GPT sounded like a big improvement so wanting to use that eventually pushed me to UEFI. I didn't really care BIOS or UEFI. UEFI just had the advantage of working. (Well, eventually.)

I think, too, that Secure Boot is not UEFI. UEFI may make it possible but it is not the same thing.

The major issue as far as I can tell is buggy firmware and firmware which is fussy in all sorts of different ways about BIOS/UEFI booting at all. But that's just an impression.

srs5694 · 2013-01-20 05:53:51

cfr wrote:

I am not sure the UEFI is really more complicated to learn than BIOS for booting. I found both pretty difficult at first.
...
The major issue as far as I can tell is buggy firmware and firmware which is fussy in all sorts of different ways about BIOS/UEFI booting at all.

I think you're absolutely right on both scores. "Old hands" at x86 computers tend to forget just how quirky and weird BIOS-mode booting can be. It's got complications related to boot loader installation locations, primary vs. extended vs. logical partitions, disk size limits, boot loaders fighting for primacy, etc. Some of these problems have analogs in the EFI space, but the key point is that EFI is just different.

I'll add that Linux distributions have, by and large, been playing catch-up on EFI issues, and that complicates matters. Arch is at least partially ahead of the curve on this score, but it's not immune to criticism -- there have been a number of threads here about problems getting the Arch installer to boot on some systems, for instance. These problems will get ironed out with time. So will buggy firmware issues, with the important caveat that currently-available buggy firmware will be in service, with no upgrade path, for years to come.

WonderWoofy · 2013-01-20 05:57:36

Yes, I think that bios booting simply has had that much more time than UEFI to standardize and have all the manufacturers actually get on the same page about what is expected of the boot environment. So I would say that it UEFI is becoming better and better, but still has a ways to go.

Honestly, though I see no particular advantage, I simply like the whole idea of efi applications held within a special partition, rather than 446 bytes that start a bootloader, which in turn boots a kernel. It just seems to me like the right direction to be able to boot the kernel directly. For ease of use, I still use a boot manager, but that still seems a vast improvement over grub2, which tries to a do a million things I don't need (or want) it to do.

scjet · 2013-01-20 18:26:01

Well, of course, and if Linux, *BSD's would've been, (at the least), included in the conversation(s)/implementain(s) of (u)efi as a "proper" BIOS repleacement, then we would NOT be in this toy-cesspool of efi, in the first place. -hence the "ironed out" someday/month/year/decade, eventually....? -unless anyone considers' cookie-crumb handouts' as a saviour ?

It'll NEVER happen, until the *ix's have some say in atleast the low-level (e)UEFI/firmware implementations.
-aka, a bit 'o "OpenHardware" anyone ? -how 'bout from some of the major PC/MB hardware manufacturers" ? mmmm.

In other words, and right NOW, "..,What is the advantage of an EFI boot?.." uhhh, not even close to what it should be, by NOW !
and, as far as "(you-know-who's)-Secure Boot" ?! - well, that's just an un-written illegality, for all concerned.
Edit: what I mean is, just ask Garrett/Redhat, 'cause they are "literally" paying for it, however, it has made installations', much more successfully simpler. ..., for the average end-User(s).
The actual "future" trade-off of that, be it politically, technically,..., is, of course, what we ALL should be very concerned about, though.

Last edited by scjet (2013-01-20 18:42:13)

cfr · 2013-01-20 19:52:57

I'm not saying secure boot is not a concern. Nor am I saying it is or is not a good, bad or indifferent thing. I have views about that but I don't think this is the place for them. All I meant was that technically UEFI is not the same as secure boot even if it is a necessary condition for it. My machine has UEFI but it does not, that I know of, have secure boot unless there is some obscure way of enabling it which I'm not aware of.

srs5694 · 2013-01-20 21:35:59

scjet wrote:

Well, of course, and if Linux, *BSD's would've been, (at the least), included in the conversation(s)/implementain(s) of (u)efi as a "proper" BIOS repleacement, then we would NOT be in this toy-cesspool of efi, in the first place. -hence the "ironed out" someday/month/year/decade, eventually....? -unless anyone considers' cookie-crumb handouts' as a saviour ?

The EFI spec has nothing in it that's particularly hostile to Linux (or Unix generally). In fact, for the first decade of its existence (that is, until just a year or so ago), EFI was generally used on Itanium workstations, which generally ran Linux or other Unix-like OSes. The first mass-market platform to adopt EFI was Apple's OS X -- which of course is based on Unix.

The biggest single problem with EFI today is, as cfr pointed out, buggy implementations. More input from Linux or Unix developers in EFI's creation would not have eliminated that problem. (Other things might have helped -- for instance, simplifying EFI. It really is a very complex spec, and complexity breeds bugs.)

It'll NEVER happen, until the *ix's have some say in atleast the low-level (e)UEFI/firmware implementations.
-aka, a bit 'o "OpenHardware" anyone ? -how 'bout from some of the major PC/MB hardware manufacturers" ? mmmm.

Are you aware that EFI is open source? You can download the complete source code from its Sourceforge page. To the best of my knowledge, every working implementation today is built from that source code or one of its predecessor versions, albeit often with proprietary additions and changes.

As to hardware manufacturer support, that's certainly an issue, but it would be an issue with any firmware -- EFI, BIOS, OpenFirmware, CoreBoot, or others. Face it: Today, the lion's share of PC sales are for computers that run Windows, so manufacturers are most motivated to get Windows booting smoothly on their hardware. Anything else is a distant second for them. (Apple hardware is an obvious exception, as is anything designed for niche markets like server hardware.) BIOS had an edge in this realm simply because it was mature and stable; boot loader and kernel developers have long known what to expect from a BIOS and how to work around its limitations. EFI, OTOH, is new, is variable, and is rapidly changing. This would be true even if the industry had shifted to OpenFirmware, CoreBoot, or something else rather than to EFI.

In other words, and right NOW, "..,What is the advantage of an EFI boot?.." uhhh, not even close to what it should be, by NOW !

I agree that there are few advantages to EFI to the end user today. They aren't nonexistent, though, and the advantages will grow in time, as disk sizes increase, as the EFI software market matures, as OS support improves, and as hardware is redesigned to remove its BIOS chains. You probably won't even be aware of the advantages as they arrive because many of them will be transparent, or they'll relate to problems that don't materialize because the system is no longer hobbled by BIOS limitations. Your computer might be a little faster, or run a little cooler, or otherwise be a little better because it uses EFI rather than BIOS, but you won't associate that improvement with the firmware because it'll be a new computer with so many other differences from your old one that you won't be able to disentangle what's giving you each particular improvement.

and, as far as "(you-know-who's)-Secure Boot" ?! - well, that's just an un-written illegality, for all concerned.

If you really believe that, then file a lawsuit. Really. I see this type of complaint a lot, but never from somebody who's backed it up with any action -- not even consultation with a lawyer. The fact that Red Hat, Ubuntu, the FSF, and others with the resources to do so have not filed lawsuits is suggestive on this score.

mynis01 · 2013-01-21 01:08:07

I'm not the most tech savvy person when it comes to system level programming. But isn't one of the main advantages of UEFI that it supports drivers built in C and not just x86 assembly like BIOS?

srs5694 · 2013-01-21 01:15:49

mynis01 wrote:

I'm not the most tech savvy person when it comes to system level programming. But isn't one of the main advantages of UEFI that it supports drivers built in C and not just x86 assembly like BIOS?

Yes. FWIW, rEFInd ships with filesystem drivers for ext2/3fs, ext4fs, ReiserFS, ISO-9660, and HFS+, all written in C. Of course, the same is true of GRUB, even on BIOS. The difference is that the rEFInd drivers enable other programs to access these filesystems, whereas the GRUB drivers are good for GRUB alone.

Arch Linux

#1 2012-09-07 21:25:49

grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#2 2012-09-26 03:16:19

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#3 2012-09-26 12:13:12

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#4 2012-10-12 19:35:06

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#5 2013-01-07 00:01:41

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#6 2013-01-07 00:19:31

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#7 2013-01-19 17:16:23

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#8 2013-01-20 03:53:06

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#9 2013-01-20 04:15:46

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#10 2013-01-20 05:53:51

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#11 2013-01-20 05:57:36

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#12 2013-01-20 18:26:01

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#13 2013-01-20 19:52:57

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#14 2013-01-20 21:35:59

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#15 2013-01-21 01:08:07

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

#16 2013-01-21 01:15:49

Re: grub_bios vs. grub_efi_x86_64: what is the value of an EFI system?

Board footer