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

or not

[(Anonymous)]

I have been using a GTP disklabel on my lenovo S12 (uses BIOS) under ubuntu for a while. I had to create the disklabel in gparted, but then the ubuntu installer just works with it.

I recently switched it to fedora 16, but the installer refused to proceed with any partitions I made. I even tried making a biosboot partition. in the end I let it create a new disklabel, it made a msdos one, and then let me create partitions and install.

maybe F17 will be better.

[(Anonymous)]

If I am not mistaken, you can also create an MBR partition table that mirrors the information of the GPT partition table. This way, both partition tables will point to the same partitions in the disk. These partition tables do not overlap each other, allowing compatibility with the old BIOS and the new EFI at the same time. I don't know if this somehow violates the EFI specification though. I believe parted already does this!

[mjg59]

It violates the spec and it confuses the majority of partitioning tools. I wrote some code to make parted do it at one point, but I don't believe it was ever merged. It's very difficult to make it work well.

[(Anonymous)]

Following through with this idea, you could also edit the GPT table, and then call the gptsync utility to syncronize the MBR information, providing BIOS compatibility. But as you pointed, this breaks the spec, so it's not such a good solution. =(

[(Anonymous)]

It's unfortunate that this is not supported, because it would allow happy coexistence of different OS on the same computer, some that boot off BIOS and some that boot directly off EFI.

I have managed to get 2 mbr partitions plus extra space, recognized by a booting windows 7 64bit, in the space seen as a single partition in the gpt table. I can not install linux in the empty space as there are already 4 partitions on disk as seen by the mbr (and I can not use an extended mbr patition for linux as it can not boot), and all I can currently try is to sync back the gpt from the mbr and go for a gtp-linux install. But given the support for this kind of setup by parted and other tools, I'm very reluctant...

[(Anonymous)]

Actually, this is pretty much what Mactel uses. They implement a GPT-MBR hybrid, which has frustrated me greatly every time I have tried to work with it. There were two big problems:

1) Because you are mirroring everything on the MBR, you can't have more than 4 bootable partitions. This sounds like plenty, but the bootable ones have to be the first four on the GPT, and Apple--don't ask me why--decided they need the first three (at least on my computer). So you can only dual boot, which is frustrating for those who want Linux, Mac, and Windows (like me).
2) A more specific problem: When I was booting Debian, on install I would have to sync the GPT with the MBR after partitioning so things were lined up, and then install GRUB to the MBR. Didn't realize why I was supposed to do this until I'd made Debian unbootable for the fourth time. Basically, the GPT was getting synced with the MBR after GRUB had been written to the MBR, which overwrote GRUB, and stopped me from booting Linux. This meant that if I wanted to keep Debian (and I'm assuming it would be the same with any Linux distro using GRUB as a boot loader) I had to avoid partitioning again, and avoid Mac updates as the next one included an EFI update (which I eventually installed and, of course, made Debian unbootable with).

So yeah. Doesn't work that well.

[(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.

micro-bootable partition?

[(Anonymous)]

Do the bios that fail, requiring a partition with a bootable flag, require that to be the partition you boot?
Would a small partition (empty or /boot?) set bootable in the MBR help?

Re: micro-bootable partition?

[mjg59]

What we've seen so far is that having a single bootable partition is enough to get them to run the MBR. The partition itself doesn't need a bootsector.

Re: micro-bootable partition?

[(Anonymous)]

[Ben Hutchings:] My recollection is that the check for a bootable (MBR) partition is quite common, and it seems to me that the spec is wrong. But I bet there is now firmware out there that will enable BIOS emulation if it sees the boot flag set in the MBR.

Change the spec?

[(Anonymous)]

If the only problem is that the UEFI specification forbids setting the bootable flag on the protective MBR, wouldn't a simpler fix be to have them change the spec to allow it to be set? This could even be made with an errata or something similar.

Re: Change the spec?

[(Anonymous)]

This is actually what happened.
UEFI 2.3.1B (the first new update since this post) states that behavior for that bit is undefined on legacy systems, the only requirement is for UEFI to ignore it.

Ignore the spec?

[(Anonymous)]

Why not just ignore the spec and set the boot flag? Surely reality > spec?

Re: Ignore the spec?

[mjg59]

Some concerns about that breaking some other scenario. We're trying to work out whether this is an option.

Re: Ignore the spec?

[gwillen.livejournal.com]

I may have a clue on this, or at least a piece of one. My EFI BIOS (or whatever the proper term for it is) has a legacy-MBR mode. The way it decides whether to engage that mode is whether any partitions are marked active. If one is, it executes the MBR; if none are, it demands a GPT partition table to boot from. This seems like it may be related to why the spec forbids marking the protective partition active. If this _is_ the reason, it suggests that it should be safe to mark the protective partition active, as long as the dummy MBR knows how to boot the system anyway, should we find ourselves executing it by mistake on an EFI system.