Legacy BIOS Issues with GPT

by Rod Smith, rodsmith@rodsbooks.com

Last Web page update: 5/23/2010, referencing GPT fdisk version 0.6.8

In theory, a computer using a BIOS can handle disks formatted with 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.

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. I have several hypotheses about what's happening, including:

1. Some BIOSes may be attempting to read the contents of at least some MBR partitions. When they encounter a GPT disk, they read the first sector (or first few sectors) of the MBR's EFI GPT partition, which corresponds to the GPT's main header (and main partition table, if the BIOS reads more than one sector). This is presumably confusing the BIOS since it doesn't look like any filesystem it understands—or perhaps by chance it sometimes does look like a known filesystem, but only enough to make the BIOS hang or otherwise misbehave when it tries to do more with the data.
2. A GPT-unaware boot loader may be executed and attempt to load its second stage starting from sector 1, but on a disk that's been recently converted from MBR form, this will be the GPT data, which will cause the system to crash.
3. A malformed protective MBR EFI GPT entry might cause the BIOS to flake out. Note that in this context, "malformed" means "unparsable by the BIOS." GPT fdisk adheres strictly to the GPT specifications, except when producing hybrid MBRs, but some BIOSes requires deviations from GPT as defined in the EFI specifications. For instance, this FreeBSD bug report suggests that some BIOSes refuse to boot if they find no active MBR partition. (The GPT 1.x specification does not address the status of the boot flag on the EFI GPT protective partition in the protective MBR, but the 2.x specification says this flag should not be set.) Also, one of my computers, built around a Biostar PT880 Pro-A7 motherboard, requires CHS geometry settings in the MBR that deviate from the GPT specification's requirements.

My two suspected encounters with this problem were on very different systems with different BIOSes—one used an AMI BIOS and the other had a Phoenix/Award BIOS. One system had a dual-core AMD Athlon X2 CPU and the other used a single-core Intel Celeron-D CPU. Both problems went away when I made changes to the GPT layout, as described shortly.

Based on my hypotheses, there are several possible remedies. 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:

• 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. Such changes seemed to fix the problem on one system, but attempts to re-create the problem by restoring the original partition table were not reliably successful.
• Use Linux fdisk or a similar tool to mark the EFI GPT protective partition entry in the MBR as active/bootable. This change has been reported to work on some buggy BIOSes.
• 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 option works around a bug I've encountered in at least one BIOS: This BIOS doesn't like the CHS values required by the GPT specification. 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.
• 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 a slightly older version of fdisk. This procedure creates a protective MBR that should be identical to the one created by the previous approach; however, you can tweak it in various ways if necessary.
• 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 the previous one in many ways.
• 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!
• 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.
• If you've just converted from MBR to GPT, reverse that process. You can use GPT fdisk's zap (z on the experts' menu) option to wipe out the GPT data structures and then restore your MBR partitions from a backup. Attempt this only if you have such a backup! A backup of the MBR made with dd will restore your primary partitions, and if you've made no other changes to the disk, your logical partitions will probably also reappear, since the linked-list data structures that define them are left untouched by GPT fdisk's MBR-to-GPT conversion process. A backup of both primary and logical partitions, as for example made by sfdisk, can be restored with near certainty of recovering both primary and logical partitions.
• 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.
• Upgrade your BIOS. If my primary hypothesis is correct, 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, and some forum posts implicate buggy BIOSes that require active MBR partitions to boot.

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. My most consistent experience was with a system built around a Biostar PT880 Pro-A7 motherboard with a Phoenix/Award BIOS version 6.00G, dated 7/27/2006. This BIOS seems 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 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, as described above. Another of my computers, which was merely sluggish when booting, was helped by changing the GPT name of a partition—but my attempts to recreate the problem for study were not reliably successful.

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. If any of my hypotheses about the cause is correct, 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 twice, I own five 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.