Legacy BIOS Issues with GPT

by Rod Smith, rodsmith@rodsbooks.com

Last Web page update: 4/16/2013, referencing GPT fdisk version 0.8.6

I'm a technical writer and consultant specializing in Linux technologies. This Web page, and the associated software, 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 GPT fdisk or 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 $20.00	Donate another value

Note: This page is part of the documentation for my GPT fdisk program.

In theory, a computer using a BIOS can handle disks that use any partitioning system—MBR, GPT, BSD disklabels, or others. In practice, though, there are occasional BIOS/GPT quirks or even downright incompatibilities. Typically, a computer with a GPT disk won't boot or will boot very slowly because the BIOS power-on self-test (POST) takes an inordinately long time to finish. I've seen such reports in online forums and public bug-report systems, one user has e-mailed me with such a report, and I've encountered it at least once, and maybe twice, myself.

Causes of Incompatibility

This behavior is quite peculiar, since as far as I know the BIOS should not attempt to read the disks, beyond verifying their presence and reading the boot code in the MBR. There are two specific bugs I'm aware of that cause this type of problem, but there may be others:

• Some Intel BIOSes (and perhaps others) require that at least one hard disk have at least one MBR partition that's marked as bootable/active. Since the protective MBR's single EFI GPT (0xEE) partition is not normally flagged in this way, the affected BIOSes won't boot from GPT disks.
• At least one computer I owned (using a Biostar PT880 Pro-A7 motherboard with a Phoenix/Award BIOS version 6.00G, dated 7/27/2006) seemed to require CHS geometries that are legal in the peculiar CHS encoding scheme. Unfortunately for this BIOS, the GPT specification explicitly requires its EFI GPT (0xEE) partition in the protective MBR to have CHS values that aren't technically legal. As GPT fdisk conforms to the GPT standard on this score, its partitions cause problems for this motherboard unless they're modified. Most other GPT partitioning tools violate the GPT specification on this score, which makes this motherboard happy.

There may be other problems, too; many reports are vague, and my own ability to investigate is limited to the computers I own. It's conceivable that some boot loaders could become confused by GPT, so a GPT-incompatible boot loader could cause boot problems. My subjective impression is that most of the problems occur on Intel motherboards and can be corrected as described below. Even when I've been in physical possession of a board with a problem, investigations have proved difficult. In one case (a system with a dual-core AMD CPU and an AMI BIOS), booting was sluggish, but sped up when I made a random change to the GPT. To this day I'm not even sure if this was a GPT issue or something else. My attempts to re-create the problem have been unsuccessful.

Broadly speaking, there are two possible ways to work around such problems: Stick with the BIOS or abandon BIOS-style booting.

There are several possible remedies when booting a GPT disk on a BIOS-based computer. If your computer is completely unresponsive, you'll have to disconnect your hard disk from the computer and connect it in some other way or to another computer. I've heard of people successfully hot-plugging SATA drives after booting without the affected disk, but this is very risky with PATA drives. External enclosures or "naked" adapters to plug PATA or SATA disks into USB ports are good options. I recommend you try the following, in more-or-less the listed order, should you encounter such problems (but see below for an entirely different type of possible solution):

1. Particularly if you've got an Intel motherboard, use Linux fdisk or a similar tool to mark the EFI GPT protective partition entry in the MBR as active/bootable. In fdisk, type a followed by the partition number (probably 1), then type p to view the partition table. An asterisk (*) should appear in the Boot column for the relevant partition. You can then type w to save your changes. Do not use GParted, GNU Parted, or another libparted-based tool to make this change; these tools interpret the "boot flag" as being synonymous with an EFI System Partition type code on GPT disks, so changing the "boot flag" with these tools will not have the desired effect. You must use fdisk or some other tool that will alter the MBR data structures, not the GPT data structures!
2. Use the h option on the gdisk experts' menu, or the equivalent -C or --recompute-chs option to sgdisk, to recompute the CHS values for the entries in the protective MBR. This approach works around a bug I've encountered in at least one BIOS, as described earlier. This gdisk option recomputes these values to be more to the BIOS's liking, although it violates the GPT specification. Note that the necessary gdisk and sgdisk option was added with GPT fdisk version 0.6.8.
3. Make a minor change to the GUID partition table and save your changes. Such a change can include changing the name of just one partition, sorting partitions, or transposing one or more partitions. (Adjusting partition numbers so that they begin at number 5 or above rather than at number 1 will move the partition table up one whole sector, which might conceivably help.) Such a change will alter the partition table data, but it will also change the checksums for both the partition table and the main header, which may be enough to work around the problem.
4. Install a second disk that uses an MBR partition table, preferably with a partition marked as active/bootable. Even a USB flash drive might do the trick.
5. Use Linux fdisk or a similar tool to delete the EFI GPT protective partition and re-create it. If you use Linux fdisk for this, you should first type c and u to enable entry of sector values as low as 1. Unfortunately, fdisk versions after 2.17 set the minimum sector value to 2048, so you'll need to use an older version of fdisk. This procedure creates a protective MBR that should be identical to the one created by approach #2; however, you can tweak it in various ways if necessary.
6. Create a hybrid MBR configuration. I recommend creating a hybrid MBR with a large 0xEE (EFI GPT) partition at the start, with just the last GPT partition in the MBR—unless of course you need a hybrid MBR with which to boot Windows or some other GPT-unfriendly OS. Note that hybrid MBRs, at least as generated by GPT fdisk, contain CHS values that a BIOS may find more acceptable than the ones used in technically correct protective partitions, so this option can be very similar to option #2 in many ways.
7. If the problem occurred on a non-boot disk or on a disk that you've just converted from MBR format, try blanking out the boot loader code at the start of the MBR. You can do this in Linux with dd, as in dd if=/dev/zero of=/dev/sda bs=440 count=1 to blank out the boot loader on /dev/sda. Note the unusual 440 block size (bs) option; this is the length of the boot loader code in the MBR. Using a larger value (particularly anything larger than 446) will begin intruding on MBR data structures. Be sure to include both the bs and count options! If you omit them, and especially the count option, you'll erase data well beyond your MBR!
8. If the problem occurred on a boot disk that you've just converted from MBR to GPT format, re-install your boot loader, or install a new boot loader. This may entail two installations, or a wipe and a re-installation, since the computer may need to boot with the disk in its normal position before you'll be able to install the boot loader normally.
9. If you've just converted from MBR to GPT, reverse that process. You can do this with gdisk, as described here.
10. Disconnect the disk, enter the BIOS setup utility, and adjust any options that seem relevant to the boot process. For instance, you might change the boot order. It's conceivable that this will at least enable you to boot an emergency CD with your hard disk connected. You may be able to boot from GRUB placed on a USB flash drive, too.
11. Upgrade your BIOS. Most of these problem are caused by BIOS bugs, and an updated BIOS might conceivably fix the problem. In fact, I found one reference (for a Tyan Tomcat K8E-SLI motherboard) to a BIOS upgrade that fixes a GPT incompatibility bug.

I can't guarantee that any of these actions will do any good on any particular system. These problems are rare and are not as yet well documented, at least not that I've found, so some of these suggestions are speculative.

An entirely different class of solution is possible with some boards: Abandon BIOS booting in favor of Extensible Firmware Interface (EFI) or Unified EFI (UEFI) booting. This option exists with many Intel motherboards (in the firmware setup utility, check the Boot menu for an option called UEFI Boot), sold in the past couple of years, and a few others. Until the spring of 2011, though, most motherboards did not support EFI booting, so this option may not even be available to you. Beginning in the spring and summer of 2011, though, most new computers began to include EFI-capable firmware, although most didn't advertise that fact initially. The vast majority of computers sold with Windows 8 are also EFI-enabled, and in fact they ship configured to boot Windows in EFI mode. If an EFI option is available, then in EFI mode, the motherboard handles GPT partitions just fine, since GPT is part of the EFI specification. This method is easiest to implement with a fresh OS installation—but only if the OS provides good EFI installation support. Fedora 14 and later, Ubuntu 11.04 and later, and OpenSUSE 11.4 and later all work (and some earlier versions may, too). As a general rule, Linux distributions' EFI support has been improving rapidly, so using the latest version available is worthwhile if you're planning an EFI-mode boot. For more information on the topic of EFI-mode booting, see my EFI Boot Loaders for Linux page. Note also that I maintain the rEFInd boot manager, which you may want to use to enable EFI-mode booting of Linux.

If you've got an existing OS installation, switching to (U)EFI booting will require changing your boot loader configuration. This is easy to do for Linux, provided you understand the needs and quirks of your (U)EFI-capable boot loader. (See the "Booting from GPT" page of this document or my EFI Boot Loaders for Linux page for some comments on this issue.)

(U)EFI installations work best when the OS architecture is matched to the (U)EFI architecture. For most systems, this means using an x86-64 (aka AMD64) installation; however, some older Intel-based Macs use 32-bit EFIs.

Should You Put Off Trying GPT?

If you're considering an MBR-to-GPT conversion, or even using GPT on a "fresh" disk that's never been partitioned, the fact that there can be problems such as I've described may give you pause. You may want to proceed with using GPT only if you have a ready means of recovery, such as access to a USB adapter so that you can plug the disk into the computer after it's booted another OS or a recovery CD. It should then be possible to recover the disk by making small changes to the partition table or boot loader, as described above. Keep in mind that, although I've encountered these problems once or twice, I own or owned six BIOS-based computers that use one or more GPT disks, and I've booted most of these with at least two or three different GPT layouts, so the incidence of problems seems to be no more than about 10%, and probably less than that. GPT-partitioned disks have been used for years on BIOS-based computers, particularly in some communities, such as the Hackintosh (Mac OS X on commodity PC hardware) community. Reports of GPT/BIOS incompatibilities in such communities are rare, suggesting that even a 10% problem incidence is a gross overestimate. On the other hand, it's possible that users are misattributing problems to other causes, such as boot loader bugs. Also, hybrid MBRs are common on Hackintoshes, which could help keep BIOS incompatibility problems in check.

Overall, I recommend you keep the potential for problems in mind, and have a recovery plan ready, but don't abandon plans to move to GPT if such a move presents real benefits to you.

If you've encountered this problem and have additional information to contribute concerning its causes or how to fix it, I'd like to hear from you. You can e-mail me at rodsmith@rodsbooks.com.

Go on to "Why Use GPT fdisk?"

Return to "GPT fdisk" main page

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.