GPT disks in a BIOS world

[mjg59]

Starting with Fedora 16 we're installing using GPT disklabels by default, even on BIOS-based systems. This is worth noting because most BIOSes have absolutely no idea what GPT is, which you'd think would create some problems. And, unsurprisingly, it does. Shock. But let's have an overview.

GPT, or GUID Partition Table, is part of the UEFI specification. It defines a partition table format that allows up to 128 partitions per disk, with 64 bit start and end values allowing partitions up to 9.4ZB (assuming 512 byte blocks). This is great, because the existing MBR partitioning format only allows up to 2.2TB when using 512 byte blocks. But most BIOSes (and most older operating systems) don't understand GPT, so plugging in a GPT-partitioned disk would result in the system believing that the drive was uninitialised. This is avoided by specifying a protective MBR. This is a valid MBR partition table with a single partition covering the entire disk (or the first 2.2TB of the disk if it's larger than that) and the partition type set to 0xee ("GPT Protective"). GPT-unaware BIOSes and operating systems will see a partition they don't understand and simply ignore it.

But how do we boot a GPT-labelled disk with a protective MBR on a system that doesn't understand GPT? The key here is that BIOS is pretty dumb. Typically a BIOS will see a disk and just attempt to execute the code in the first sector. This MBR code knows how to do the rest of the boot, including parsing the partition table if necessary. The BIOS doesn't need to care at all.

Of course, some BIOSes choose to care. We've seen a small number of machines that, when exposed to a GPT disk, refuse to boot because they parse the MBR partition map and don't like what they see. This is typically accompanied by a message along the lines of "No operating system found". What we've found is that they're looking for a partition marked with the bootable flag, and if no partitions are marked bootable they assume that there's no OS. This is in contrast to the traditional use of the flag, which is merely a hint to the MBR as to which partition boot code it should execute.

So, should we set that flag? The UEFI specification specifically forbids it - table 15 states that the BootIndicator byte must be set to 0. Once again we're left in an unfortunate position where the specification and reality collide in an awkward way.

If this happens to you after a Fedora 16 install, you have two choices. The first is to reinstall with the "nogpt" boot argument. The installer will then set up a traditional MBR partition table. The second is to boot off a live CD and run fdisk against the boot disk. It'll give a bunch of scary warnings. Ignore them. Hit "a", then "1", then "w" to write it to disk. Things ought to work then. We'll figure out something better for F17.

Comments

[(Anonymous)]

why are you trying to put a GPT on disks < 2.2TB anyway? where is the advantage? assuming that systems which dont need a GPT are also the ones that likely have a BIOS that can not handle it, you can save yourself some trouble..

[mjg59]

How else do you support BIOS booting off >2.2TB disks? There's an argument that it should be size limited, but we'd still stand a decent chance of hitting the same issues - we'd just have fewer reports because of the smaller testing pool. Having everything use the same codepath eases testing somewhat.

That's not to say that we won't end up doing something like that if the problems turn out to be insurmountable...

[(Anonymous)]

"GPT also provides redundancy, writing the GPT header and partition table both at the beginning and at the end of the disk." -wp
which I assume means that if a chunk of you disk becomes unreadable, you have a much better chance of recovering some of the partitions.

and lots more partitions than msdos. sometimes its hndy to have more than 16 partitions on a disk.

[martzin]

It also removes that annoying limitation of four "real" partitions, which occasionally causes problems when you hit the limit of four and don't have an extended partition yet, or when you split a partition near the beginning. Not as good as LVM, but more convenient than the dos format.