Legacy BIOS Issues with GPT

by Rod Smith, rodsmith@rodsbooks.com

Last Web page update: 4/18/2022, referencing GPT fdisk version 1.0.9

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

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

Today, new x86-64 computers ship with firmware known as the Extensible Firmware Interface (EFI) or its variant, the Unified EFI (UEFI), which is essentially EFI 2.x. GPT was created as part of the EFI specification, so of course GPT works well with EFI-based computers.

In the past, most desktop, laptop, and server computers used a firmware knwon as the Basic Input/Output System (BIOS). which is so simple that it doesn't understand the partition table type used on the disk — it's the role of the boot loader and subsequent software to interpret the partition table. Thus, in theory there should be no problem using GPT with BIOS-based computers. Unfortunately, in practice, there are occasional BIOS/GPT quirks or even downright incompatibilities. Furthermore, many modern computers with EFIs provide a Compatibility Support Module (CSM), which enables them to boot using BIOS-mode boot loaders. The trouble is that the firmware may use the partition table type as a cue for what type of boot mode to use, thus causing problems when trying to boot in BIOS mode from a GPT disk. In either case, a computer with a GPT disk may not boot or will boot very slowly because the BIOS power-on self-test (POST) takes an inordinately long time to finish. This page exists to help you if you encounter such problems. It must be emphasized that, as of 2022, BIOS is a fading technology; you should not encounter such problems on most computers made since 2011, although enabling the CSM or using a GPT with a hybrid MBR can sometimes cause problems, as described on this page.

Causes of Incompatibility

BIOS problems with GPT are 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. In most cases, incompatibility manifests as an inability to boot the computer — either a BIOS-mode OS won't boot or the computer will freeze during its power-on self-test (POST) when you attach a GPT disk. There are two specific bugs I'm aware of that cause this type of problem, but there may be others:

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 EFI-based computers set to boot in BIOS/CSM/legacy mode. Thus, the problem is most common in computers purchased since 2011; however, some older computers (particularly some Intel motherboards) used EFIs that exhibited these symptoms well before that date. Such problems can usually 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.

Sticking with the BIOS

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. Set the boot flag on the type-0xEE partition in the protective MBR. You can do this with several different programs:
  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.
  3. Ensure that your GPT disk does not have an EFI System Partition (ESP), which is where an EFI stores its boot loaders. Some EFIs use the presence of an ESP as a clue to favor EFI-mode booting, and so such a partition can interfere with BIOS/CSM/legacy-mode booting. Of course, removing the ESP is not an option if you must dual-boot, with one OS in EFI mode and another in BIOS/CSM/legacy mode. Such configurations are inadvisable in most cases. If you really must boot in this way, look into my rEFInd boot manager, which is an EFI boot loader that supports chainloading to BIOS/CSM/legacy boot loaders.
  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 firmware 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 firmware (BIOS or EFI). Most of these problem are caused by firmware bugs, and an updated firmware 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. (Note that most manufacturers refer to their EFIs as BIOSes, so you may need to look for a "BIOS upgrade" even if you know you've got an EFI.)

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.

Abandoning BIOS Booting

An entirely different class of solution is possible with some boards: Abandon BIOS booting in favor of EFI or UEFI booting. Until the spring of 2011, most motherboards did not support EFI booting, so this option may not even be available to you if you're using an unusually old computer. Beginning in the spring and summer of 2011, though, most new computers began to include EFI firmware, although most didn't advertise that fact initially and instead relied on their CSMs for BIOS-mode booting by default. The vast majority of computers sold with Windows 8 or later 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 improved rapidly from 2010 until about 2015, by which time most distributions provided what I would consider mature EFI support. I recommend using the latest version of your chosen distribution if you're planning an EFI-mode boot. For more information on the topic of EFI-mode booting, see my Managing EFI Boot Loaders for Linux and Linux on UEFI: A Quick Installation Guide pages. 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.)

If you have an existing BIOS-mode installation of Windows 10 or later, you may want to check out the Microsoft MBR2GPT utility. As its name implies, this tool converts a disk from MBR to GPT, similar to what GPT fdisk can do; but it also installs Microsoft's EFI boot loader for Windows on the disk. I've never used Microsoft's MBR2GPT, so I can't cover it in detail or provide tips and caveats to get the most from the program. It looks very promising for those moving a disk from an older to a newer computer or for those who had been booting via a CSM and who want or need to enable EFI-mode booting, though.

(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 or X64) installation; however, some older Intel-based Macs use 32-bit EFIs, as do some tablet computers, so installing 32-bit OSes may be best for them. Some of these 32-bit EFIs are run on 64-bit CPUs, which complicates installing 64-bit OSes, since most EFI boot loaders require the same bit depth throughout the boot process. GRUB 2 supports cross-bit-depth booting, but most distributions don't support such configurations, so you'll have to jump through some extra hoops to get it working. Several Web pages cover this topic, but my experience with such configurations is minimal, so I can't provide much guidance on this topic. One of the clearer and more thorough Web pages I found was this one by zedgoat; but I can't promise that it will work for you.

Go on to "Why Use GPT fdisk?"

Return to "GPT fdisk" main page

copyright © 2009–2022 by Roderick W. Smith

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.