Gigabyte's Hybrid EFI

by Rod Smith,

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
Donate with PayPal


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:

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:

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:

As a practical matter, if you're installing Windows and nothing but Windows to a Hybrid EFI computer, you'll probably do OK with a default setup, provided your ESP doesn't become damaged in a way that causes the firmware to hang. If you're installing another OS, though, and if you have reason to boot in EFI mode rather than in BIOS mode, I recommend you use the following procedure:

  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.
  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!


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:

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

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

Return to my main Web page.