Gigabyte's Hybrid EFI

by Rod Smith, rodsmith@rodsbooks.com

Web page created: 2/26/2012; last update: 3/15/2012

I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!

Donate $1.00	Donate $2.50	Donate $5.00	Donate $10.00	Donate another value

Introduction

If you've read my other Web pages, you may be aware that I've taken an interest in the new Extensible Firmware Interface (EFI) and Unified EFI (UEFI) firmware, which supplements or replaces the older Basic Input/Output System (BIOS) firmware. I've used EFI or UEFI in a couple of computers, in VirtualBox, and as add-on products such as UEFI DUET, which enables you to run UEFI atop a standard BIOS-based computer. When my main computer's motherboard died suddenly, though, I ran across conflicting and confusing information about a particular product when I did my hasty research to find a replacement. Specifically, Gigabyte offers several motherboards with what it calls Hybrid EFI to enable support for hard disks over 2TiB in size. Since one of the motherboards I was considering for my necessarily rapid replacement was the Gigabyte GA-78LMT-S2P (rev. 4.0), which uses a Hybrid EFI, I wanted to know more, and ultimately decided to give it a try myself. Although Web forums in particular were filled with confusing information, a few news sites had more reliable information. (See the References section for links.)

Briefly, Hybrid EFI is a UEFI based on the open source TianoCore reference implementation. This implementation is also at the heart of UEFI DUET, which enables you to boot using EFI methods on BIOS-based computers. In fact, conceptually, Hybrid EFI is similar to using UEFI DUET, except that the EFI code is built into the firmware: Underneath the UEFI layer, Hybrid EFI uses an old-style BIOS—specifically, an Award BIOS version 6.00PG, at least in the case of the GA-78LMT-S2P I bought. Once an OS (or even a boot loader) has booted, the underlying BIOS becomes fairly unimportant. Contrary to the implication of many forum posts I found, Hybrid EFI is much more than just a way to get Windows to boot from a disk that's over 2TiB in size. To boot on such a disk, Windows needs to have a full EFI implementation, and Hybrid EFI delivers that. It also enables booting Linux or other OSes in EFI mode. You can install Linux, Windows, or other EFI-enabled x86-64 OSes in EFI mode even on disks smaller than 2TiB, if you so desire. I suspect that you can install in BIOS mode even on larger disks if your OS supports this, but I haven't tested this supposition.

Unfortunately, Gigabyte's implementation leaves much to be desired. Although OSes can see the firmware as a UEFI, and have access to the usual EFI features, the way it's bolted onto the older BIOS provides the user with few options. The most hyped and user-visible EFI feature, a GUI for setting firmware options, is lacking from Hybrid EFI. (A GUI isn't part of the EFI specification, and GUI BIOSes have been produced in the past, so the GUI is really a side-show in terms of EFI development. A GUI is a major marketing, but not a technical, feature of UEFI.) Furthermore, Hybrid EFI is a finicky implementation, which tends to flake out when presented with configurations that deviate even slightly from the optimum, as described in more detail shortly.

The Hair-Pulling Begins

Because I bought the GA-78LMT-S2P as a replacement board for a previously-working Linux installation, I expected to be able to do the board swap, boot my working Linux installation, and then fiddle with drivers and whatnot as time permitted. (I've followed this procedure many times in the past with Linux, which is much more forgiving of hardware changes than is Windows.) I then hoped to experiment a bit with the BIOS vs. EFI methods of booting. Alas, it wasn't so simple!

The Gigabyte GA-78LMT-S2P is a microATX motherboard, and physically there's not much difference between it and other microATX boards I've used. Thus, I have no real problems or praise on that score. Installing it in my case went as well as could be expected. As soon as I powered it up, however, the problems began. Before proceeding further, I should note that my existing installation was a Gentoo Linux system split across two hard disks, both of which were partitioned with the new GUID Partition Table (GPT). The original motherboard supported only BIOS-style booting, which works fine with GPT and Linux. I admit that this is an unusual configuration, but I've been using similar setups on other computers with few problems, by and large. (My Legacy BIOS Issues with GPT page details the incompatibilities I've encountered or heard about.)

Rather than regale you with the tale of my 7-hour struggle to coax the board to get as far as loading a usable boot loader, much less a Linux kernel, I'll simply point out the impediments it threw up in my path:

• Initially, the computer hung with a "verifying DMI pool data" message on the screen, without even getting as far as the BIOS boot loader that had been installed on the hard disk from before the motherboard swap. This smelled like one of those legacy BIOS issues, so I tried most of the tricks I documented on my page to get around the problem. I eventually discovered that the firmware on this motherboard is very fussy about the state of the FAT filesystem on the EFI System Partition (ESP) on GPT disks; if it doesn't like the state of the filesystem, it hangs with that unhelpful message. Attempting to boot from an optical disc does not bypass this problem, which means that the firmware contains a trap of quicksand for the unwary—or the merely unlucky! I initially concluded that fixing the problem requires either booting with the affected hard disk disconnected and then hot-plugging it, or moving the disk to another computer. Either way, you can copy the data off the partition, create a fresh FAT-32 filesystem on it, and copy the files back. When this problem recurred a few days later, I discovered that the firmware would occasionally skip past the problem, so resetting the computer half a dozen times might result in one good boot. I also found that a filesystem check did not fix the problem—at least not on that one occasion. Whatever causes this flakiness is more subtle than a flat-out corrupt filesystem.
• The board has a hard time remembering the boot options set via the Linux efibootmgr utility, which is the Linux tool that manipulates the firmware's list of installed EFI boot managers. Although I've had the boot manager options "keep" for a few reboots, they often get removed or replaced by references to EFI/Microsoft/Boot/bootmgfw.efi (Microsoft's EFI boot loader). This is despite the fact that Windows is not installed on this computer. Thus, it's prudent to have a valid boot loader of that name or of the standard EFI default boot loader name, EFI/Boot/bootx64.efi. I initially set an EFI shell program to that name. I could then use a startup.nsh shell script in the root of the ESP to launch ELILO. Since then, I finalized my rEFInd boot manager and installed it in this default boot loader location. (More on these approaches later.)
• In a test install in EFI mode on a spare hard disk, Fedora installed OK but failed to boot because of the Hybrid EFI's weird handling of EFI boot loaders. When I worked around that by using an EFI shell, as just described, Fedora's heavily modified GRUB Legacy EFI boot loader worked fine. When I copied that boot loader to my normal installation, though, it caused the board to reboot or to hang with a large number of red coded numbers. I suspect the cause may be the Hybrid EFI's buggy handling of the EFI StriCmp() function, which is supposed to do a case-insensitive comparison of two strings. In developing rEFInd, I discovered that this function does a case-sensitive comparison on this firmware!
• Because of the case-sensitivity issue I just mentioned, rEFIt only detects boot loaders whose names end in an uppercase .EFI extension, and all the program's icons are replaced with generic ones unless you rename the icon files so that they end in uppercase .ICNS strings. My fork of rEFIt, rEFInd, fixes the latter problem, and changes the code so that it finds boot loaders with names that end in lowercase .efi extensions, since those seem a bit more common than uppercase in my experience. (I plan to do a more thorough workaround in future versions of rEFInd.)
• Booting in EFI mode proved unreliable when booting off an ESP on the second disk. The boot process would often simply fail to bring up the boot loader, although other times it would work. This has to do with disk order, not the disk itself; when I juggled the SATA cables so that the boot disk was on the first port, the boot process became more reliable.
• The board responds to its boot-time keystrokes to enter the setup utility or select a boot option (Del or F12) only occasionally. This problem seems to be exacerbated by the KVM switch I use; the motherboard is more reliable when I plug a spare keyboard directly into the computer. Oddly, the keyboard attached via the KVM works fine for everything else, including navigating the firmware menus. In normal use, of course, this will be a minor annoyance; but when trying to diagnose and work around problems that prevent the computer from even reaching a boot loader, this was an infuriating problem, especially before I tried plugging in the spare keyboard directly. Note that this problem (and the next) appear to be related to the underlying Award BIOS rather than to the Hybrid EFI feature it contains.
• All the firmware options reset themselves two or three times in my testing, without my telling them to do so. This is a minor, but somewhat troubling, problem.

It appears to me that Gigabyte rushed out its Hybrid EFI support with very serious bugs and limitations that they must have known about. Presumably the motivation was that providing no way to boot Windows from an over-2TiB disk would have been worse. Early in my testing, I intentionally erased my BIOS boot loader, since I thought that it might have been confusing the computer's firmware, so most of my testing has been done with booting Linux in EFI mode, which highlights the firmware's flaws. Many of these problems would be less important on a Windows-only installation than on my Linux-only installation, and they might be worse on a dual-boot system. Booting in BIOS mode bypasses most of the problems that are related to the Hybrid EFI, too. Booting in BIOS mode from a GPT disk still exposes you to the potential for a system hang if that disk has an ESP that the firmware doesn't like, though. As noted earlier, if you run into this problem, you may have to either hot-plug the disk or move it to another computer to repair it—both very undesirable options!

Fortunately, the firmware seems OK with an ESP that doesn't contain a FAT filesystem. I say this because I successfully installed Fedora 16 in BIOS mode to a GPT disk. This version of Fedora has a bug that causes it to incorrectly mark the Linux /boot partition as an ESP when installing in BIOS mode, so when I was done with the installation, I had a partition that the firmware must have tried to interpret as a FAT-32 ESP, but it failed and continued with the boot process in BIOS mode.

A FAT-16 ESP, on the other hand, seems problematic. Ubuntu 11.04 (and 11.10) in EFI mode creates a dinky FAT-16 ESP, and after my test install of Ubuntu 11.04, the board hung on reboot until I reworked the ESP as FAT-32. Thus, if you plan to install Ubuntu, or any other OS that creates a FAT-16 ESP, be prepared to fix it, preferably before the system reboots!

Using the Board's EFI Features

With the transition from traditional BIOS-based computers to (U)EFI-based computers well under way, (U)EFI support in new computers is important. Even if you plan to use BIOS-mode booting initially, you may want or need to use EFI-mode booting in the future. The most important reason for doing this in the near term is if you want to boot from a disk that's over 2 TiB in size, and particularly if you want to boot Windows from such a disk. Although Gigabyte's Hybrid EFI contains a full-fledged EFI implementation from an OS's perspective, the firmware setup utility provides almost no options to help you use this functionality. Specifically, only one firmware option, entitled "EFI CD/DVD Boot Option," on the "Advanced BIOS Features" menu, relates to this feature. It has three settings, which are poorly described in the manual:

• EFI—This setting causes the firmware to boot optical discs in EFI mode if they've been mastered to support both BIOS-style and EFI-style booting. If a disc is mastered for traditional BIOS-style booting but lacks EFI support, the computer still boots it in BIOS mode. You could use this setting if you want to install Windows to a sub-2TiB GPT disk or if you want to install Linux in EFI mode to a sub-2TiB disk.
• Non-EFI—This setting causes the computer to boot optical discs in BIOS mode rather than in EFI mode if they support both modes. I've not tested to see whether the computer will still boot an EFI-only disc with this option set. You could use this option to ensure that Linux (or some other non-Windows OS) installs in BIOS mode even if you've got an over-2TiB disk. (This should work, but I've not tested it.)
• Auto—This setting, which is the default, causes the behavior to switch between the previous two depending on your installed hard disk sizes; if you've got disks over 2 TiB in size, the firmware favors EFI mode, and if you've got smaller disks, it favors BIOS mode. It's unclear to me if the presence of a single large disk triggers EFI mode even if it's not the first disk or if only the first disk determines the boot mode.

These options don't seem to affect how the computer boots from hard disks; for that, the firmware auto-detects whether you've got a BIOS or an EFI boot loader. Based on tests I've run, the rules seem to be:

• If a valid ESP is present on any disk, the computer boots in EFI mode, even if you also have a valid BIOS boot loader in the MBR of the boot disk. This will create boot problems if you install an OS and partition an ESP for possible future use, or if you transfer a GPT disk from another computer. If you want to use GPT with a BIOS boot, I recommend either not creating an ESP or changing the would-be ESP's type code to something else to keep the firmware from trying to boot from it.
• If a valid BIOS boot loader is present in the MBR of the boot disk, it will be used if there's no ESP. This is true whether the disk is partitioned with MBR or GPT. Thus, you can install Linux, FreeBSD, or other GPT-capable OSes to GPT disks and still boot in BIOS mode, if you like. You can't do this with Windows because of its own limitations.
• Unfortunately, unlike even earlier EFI implementations, such as that in the Intel DG43NB (which I use as a MythTV system), there doesn't seem to be any way to select which of the EFI boot loaders registered with the firmware the motherboard uses, aside from using the crude BIOS-style determination of which physical boot medium to use. This makes the inability of rEFIt to detect other EFI boot loaders doubly troubling.

1. Set the firmware's "EFI CD/DVD Boot Option" to "EFI," if necessary, to force an EFI boot of your installer.
2. Install the non-Microsoft OS normally.

If your non-Microsoft OS creates a FAT-16 ESP, you'll have to manually modify it to use FAT-32 before installing Windows. This can be difficult, since the FAT-16 ESP is likely to cause the Hybrid EFI to hang, as described earlier. You'll need to hot-plug the boot disk after booting a recovery disc, or fix the problem using another computer.

3. If you want to dual-boot with Windows, install Windows.
4. Boot an emergency boot disc, such as Parted Magic or your OS installer in "live CD" mode.
5. (Optional.) If you're dual-booting with Windows, rename the EFI/Microsoft directory on the ESP to something else—say, EFI/MS. You might not need to do this, but I'm not sure whether this firmware favors the Microsoft boot loader or the default EFI boot loader if both are present.
6. Create a new EFI/Boot directory on the ESP.
7. Install my rEFInd boot manager to the disk as EFI/Boot/bootx64.efi, placing its support files in the same directory. (The rEFInd installation Web page describes precisely how to do this.)
8. Review the names of your EFI boot loader files to ensure that they all end in lowercase .efi extensions.
9. Optional: Place the TianoCore EFI shell program in the ESP as EFI/tools/shell.efi (you'll have to rename the file you download). This will give you a fallback should rEFInd fail to locate your boot loaders.
10. Reboot and test your installation; rEFInd should come up and present a menu of your other boot loaders.
11. Debug any problems. Sorry, I know that's vague, but I'm not foolish enough to suggest everything will work fine for everybody at this point.
12. Once everything's working, back up the ESP to an external medium such as a USB flash drive or a CD-R. This step will help simplify recovery if and when something happens that requires restoring the boot loader, such as filesystem damage or a Windows recovery tool overwriting the EFI shell with the Microsoft EFI boot loader.

A variant on this procedure is to store rEFInd as EFI/Microsoft/Boot/bootmgfw.efi rather than EFI/Boot/bootx64.efi. If you do this, the firmware will probably detect it and add an entry to its boot manager list, but you can do this manually with the Linux efibootmgr utility if it doesn't. You must boot using EFI—I find that an Ubuntu installer booted in its "live CD" mode works well for this purpose, since you can install efibootmgr by typing sudo apt-get install efibootmgr. Thereafter, typing sudo efibootmgr -c -l \\EFI\\Microsoft\\Boot\\bootmgfw.efi -L rEFInd as root tells the firmware about the boot manager. (Note the use of double backslashes to separate directory elements with efibootmgr.) Using the default name of EFI/Boot/bootx64.efi is simpler and probably more reliable, but you can try this alternative if you can't get EFI/Boot/bootx64.efi to work.

Another variant on this approach is to store the EFI shell program as /EFI/Boot/bootx64.efi. This will launch your computer straight into the EFI shell rather than into rEFInd. The EFI shell is less user-friendly but more flexible than rEFInd, so if you're having problems with your boot loaders, it can be a useful debugging tool. You must be comfortable with command-line shell programs for this to be a useful strategy, though.

With any luck, this procedure will help simplify your non-Microsoft OS installation to a Hybrid EFI board. If it saves you from the sort of seven-hour hair-pulling session I experienced, then this page has done its job!

Recommendations

If you want an EFI-based computer for any reason, Gigabyte's Hybrid EFI makes a poor choice. It simply gives users inadequate control over EFI features and has bugs that can only be compared to prehistoric dragonflies with 30-inch wingspans. (I like to photograph modern dragonflies, but I don't want a monster like that in my computer!) A Hybrid EFI can do in a pinch if you're desperate for something that can boot Windows from an over-2TiB disk. If you want a more capable EFI implementation, though, you should look elsewhere. ASUS and ASRock have switched to fuller UEFI implementations on most of their new models, for instance, and others (including Gigabyte) have begun rolling out UEFIs that depart more completely from BIOS and that provide better user-level control of EFI features.

In the hours after I began using my GA-78LMT-S2P, I became extremely frustrated with its limitations. Granted, my initial configuration was peculiar, but bugs like hanging with no useful error message because of filesystem problems are close to inexcusable in firmware. I plan to keep my board, but only because the hassle of swapping it again would be too great. Now that I've discovered the board's quirks, I hope that I'll be only slightly inconvenienced by them moving forward. As I type, it's booted in EFI mode, but I'm likely to disable my ESP to force the board to boot in BIOS mode in the near future. I may also look into Coreboot as an alternative to the Award BIOS with Hybrid EFI, although it's not clear if Coreboot will work with this motherboard.

If you end up with a board that uses Hybrid EFI, your best bet is probably to try to use it in BIOS mode, at least if you're installing Linux or have a sub-2TiB hard disk. If you boot in BIOS mode, do not create an ESP on your disk; its presence will cause the board to switch to EFI-mode boot, and damage to it will cause a boot failure. Such a partition is a necessity when booting in EFI mode, though, in which case you should be careful that it doesn't end up getting damaged. (Note that many Linux distributions create FAT16 ESPs, which cause this board to fail to boot, so you'll need to jump through some hoops to correct this problem.) I have a hedge on this advice, though: If you're installing Windows to a sub-2TiB disk and think you'll want to replace that disk with a larger model, installing in EFI mode to GPT now may make the disk upgrade go more smoothly. This is because switching from BIOS-style to EFI-style booting, although possible, is awkward.

On the flip side, if you use the computer with sub-2TiB disks and boot in BIOS mode on MBR disks, you're unlikely to run into most of the problems I encountered. As a BIOS-only firmware, the Award BIOS provided by Gigabyte is fine, with the caveat that you don't create an ESP. I believe the problems I encountered are serious and worth considering, though, because as disk sizes increase, today's purchasers may be forced to enable the board's EFI support in the future, so even if the board is trouble-free when used in a more traditional way, it may become a problem after a disk upgrade or OS re-installation.

For more on the topic of Hybrid EFI, I recommend the following:

• Ask a BIOS Guy: "Hybrid EFI?"
• Is It EFI or Not? Gigabyte's Hybrid EFI BIOS Explained
• Gigabyte Hybrid EFI Technology
• This short blog post by Matthew Garrett (a Fedora developer involved in UEFI issues) summarizes some UEFI bugs. It doesn't mention Hybrid EFI specifically, but it may help you understand why it's so buggy.

Web pages I've written that are relevant to this topic include:

• Managing EFI Boot Loaders for Linux
• The rEFInd Boot Manager
• A BIOS to UEFI Transformation

If you have problems with or comments about this Web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.

Return to my main Web page.