Last Web page update: 10/1/2011, referencing GPT fdisk version 0.8.1
Note: This page is part of the documentation for my GPT fdisk program.
One of the challenges of GPT is that of booting from it. In mid-2011, support for booting from GPT is limited compared to support for booting from MBR. This support varies by OS, as well. Following are my notes and general observations on this issue. Keep in mind, though, that these details are likely to change rapidly.
The rest of this page is broken down into three main sections: Information on EFI vs. BIOS booting; booting with EFI; and booting with BIOS.
GPT is part of the EFI specification. EFI includes its own boot loader, so of course booting from GPT disks becomes easier if your computer uses EFI. Unfortunately, EFI is still fairly rare on the installed base of mainstream PCs, but many new PCs are UEFI-capable. Among common computers, Apple Macintoshes are the systems that are most likely to use EFI. Many new motherboards and computers now include Unified EFI (UEFI) support, UEFI being essentially EFI 2.x. Most notably, most motherboards built around Intel's Sandy Bridge CPU line include UEFI support, as do many AMD-based motherboards introduced in 2011. Note, however, that most of these UEFIs include a BIOS support mode that may be enabled by default, so you may need to hunt for a firmware option to explicitly enable UEFI support. One obscure product, UEFI DUET, enables booting an EFI environment on a BIOS-based computer. I have a separate Web page that describes how to set up UEFI DUET; however, the technology is still very "bleeding edge," and so is best used if you're an interested hobbyist or if you're desperate. The upcoming "Windows" section describes the UEFI DUET option, since Windows is the only OS that really needs it.
The EFI specification includes an EFI System Partition (ESP) as a storage place for EFI boot loaders, drivers, and other files. Thus, if you intend to boot a disk using an EFI-based computer, you should create an ESP. Different sources suggest different sizes, but 100-200 MiB seems to be the range. If you intend to boot multiple Linux distributions in EFI mode and use the ELILO boot loader, an ESP even larger than 200 MiB might be appropriate.
Many Internet sources, particularly discussion groups, include assertions that it's impossible to boot a GPT disk on a BIOS computer. This is nonsense—or at least, it's true only of certain OSes. Windows, in particular, is behind the times on this score, as described shortly. I personally have successfully booted both Linux and FreeBSD on GPT-only computers with BIOSes. For the truly adventurous, it's even possible to get Mac OS running on GPT disks on conventional hardware, although this configuration is unsupported by Apple and may even be illegal. UEFI DUET, as already noted, can be used to boot any UEFI-capable OS, Windows included, on BIOS-based hardware. That said, there are some rare BIOS/GPT conflicts; see my Legacy BIOS Issues with GPT page for details.
BIOS-based computers, whether they use MBR or GPT, rely on a boot loader in the first sector of the disk to help get the computer booted. In fact, the first 440 bytes of the MBR data structure are devoted to this boot loader. DOS and Windows place a very simplistic boot loader in this space. Other OSes and third-party utilities enable placing more sophisticated boot loaders in the MBR, although these boot loaders usually rely on multiple stages—the boot loader code loads a secondary boot loader that's located elsewhere, and that boot loader may even load a third stage. In principle, these boot loaders can work just fine when the MBR is in fact a GPT protective MBR. In practice, the boot loader needs to be GPT-aware in order to work. The GRUB 2 boot loader, when used on a GPT disk, works best when you to have a BIOS Boot Partition (GPT fdisk code EF02) on the disk. Most boot loaders, including the patched versions of GRUB Legacy (version 0.97) that include GPT support, don't require a BIOS Boot Partition. If you do need it, the BIOS Boot Partition can be quite small—perhaps as small as 32 KiB, although I recommend making it 100-200 KiB, if possible, and if you align your partitions to 1 MiB boundaries, 1 MiB is the logical size.
Old versions of GNU Parted (such as version 1.7.1) tend to wipe out the MBR boot loader from GPT disks. Thus, you should be very cautious about using GNU Parted on a GPT boot disk if your computer is BIOS-based. (Parted's behavior in this respect shouldn't affect EFI-based systems.) A retest with GNU Parted 1.9.0 produced no such problem, so it seems to have improved in that respect. More recent versions (up to at least version 2.3), though, wipe out the Legacy BIOS Bootable flag that's used by SYSLINUX's GPT loader.
I've seen a few Web pages that suggest that booting from beyond the 2 TiB mark is iffy on BIOS-based systems. I haven't investigated this issue in detail, but I recommend creating the BIOS Boot Partition and any OS boot partitions below the 2 TiB mark. If necessary, create a small partition to hold the /boot directory below the 2 TiB mark.
Booting from GPT with EFI is, in theory, straightforward, since GPT is part of the EFI specification. There are, however, quirks related to specific OS boot loaders and installers. I describe some of these, as well as the process of booting OS X.
I maintain a separate Web page, entitled Managing EFI Boot Loaders for Linux, that goes into much greater detail on ELILO, GRUB Legacy, GRUB 2, rEFIt, and the Linux kernel's EFI boot loader support.
If you've got a (U)EFI-based computer, you'll typically have a separate boot loader for each of your OSes, although some boot loaders can launch multiple OS kernels. Most EFI boot loaders reside in their own subdirectories of the EFI directory on the EFI System Partition (ESP). Some common EFI boot loaders include:
At the moment, my personal preference is to use rEFIt as a boot selector along with OS-specific boot loaders, with ELILO being my choice for the Linux side. This varies from one system to another, though; sometimes other options work better. ELILO seems unreliable on my 32-bit Mac Mini, for instance.
Every OS has installation quirks on any platform, and these can sometimes be frustrating, particularly if you're not familiar with them. I've done a number of test installations and conversions and have a few comments:
Intel-based Macs employ EFI and GPT by default. Thus, as you might expect, booting Mac OS from a GPT disk is not a problem. I've used gdisk to manipulate Mac boot disks, although my tests have been limited since I've got just one Mac Mini. The biggest caveat seems to be following Apple's recommendations for partition sizing and placement. The need for 128 MiB of unpartitioned space after each OS X partition is particularly important; without that space, the OS X installer will refuse to install or upgrade on the partition.
Most OSes have GPT-specific boot quirks on BIOS-based computers. The best, such as Linux, install and boot fine on GPT systems, so long as you follow the advice for creating appropriate partitions. Others, such as Windows, are much more challenging to get booting in this way.
Most modern Linux distributions install GRUB as the boot loader. Currently, GRUB 0.97 (aka GRUB Legacy) is the most common choice. Officially, GRUB 0.97 is not GPT-aware and so can't boot anything from a GPT disk. In practice, though, patched versions of GRUB 0.97 are common, and many distributions ship with them. (Ubuntu 8.04 and Fedora 10 through 15 definitely have GPT-enabled versions of GRUB 0.97, but openSUSE 11.0 does not. Ubuntu switched to GRUB 2 with version 9.10.) If your distribution's GRUB lacks GPT support, you can download the System Rescue CD and apply its version of GRUB to your GPT disk:
Note that if you've converted an MBR disk to GPT format, booting will fail even if you were previously using a GPT-aware version of GRUB. This is because the MBR and GPT boot-time code for GRUB is different; in fact, GRUB installs part of itself just after the MBR on MBR-based disks (when you install it to the MBR), but that space becomes used by GPT on GPT disks, so converting MBR to GPT will wipe out part of GRUB. Re-installing a GPT-aware GRUB, as just described, will correct this problem.
Development on the original GRUB (now known as GRUB Legacy) has officially ceased. A new boot loader, known as GRUB 2, is now under development instead. This boot loader includes GPT support. GRUB 2 works at least as well as GRUB Legacy, although it's more complicated and poses some learning challenges for those already familiar with GRUB Legacy. The GRUB 2 configuration file format is slightly different from GRUB Legacy's. GRUB 2 includes scripts intended to help automate setup, so you shouldn't be editing its main configuration file (/boot/grub/grub.cfg) directly; instead, you should edit files in /etc/grub.d and then re-run grub-mkconfig or some other utility to regenerate the grub.cfg file. The two versions of GRUB identify partitions differently; GRUB numbers them starting from 0, whereas GRUB 2 numbers them starting from 1. Confusingly, GRUB 2 continues to number hard disks starting from 0, so that (hd0,1) is the first partition on the first hard disk. Ubuntu 9.10 has switched from GRUB Legacy to GRUB 2 as its default boot loader, and other Linux distributions are sure to follow eventually.
There's a known bug with older versions of GRUB 2 and systems with multiple disks that use a mixture of GPT and MBR partition tables. On Ubuntu systems (and perhaps others), you can work around this by including the following line in /etc/default/grub:
GRUB_PRELOAD_MODULES="part_msdos"
Information on the old Linux Loader (LILO) and GPT is contradictory. Most sources say the two won't get along, but I've read others who opine that the combination does (or at least should) work fine, since LILO just uses sector maps to point to the kernel file. My one attempt at this combination proved inconclusive. LILO was able to load and run the kernel, but the boot then failed with the kernel message mount: could not find filesystem '/dev/root'. This message followed messages that indicated that the computer's LVM configuration was working fine, but somehow handing off to the LVM-based root filesystem was a problem. A GRUB boot of this system worked fine.
The SYSLINUX boot loader is another Linux boot loader that includes GPT support. This support resides in the MBR and redirects the boot process to a partition with the Legacy BIOS Bootable flag set. AFAIK, no Linux distribution relies on SYSLINUX to boot from a GPT disk, but you could set yours up to use this boot method if you liked.
Beyond the boot loader, Linux requires GPT support in its kernel to work with GPT disks. This support is common, but there's no guarantee that any given kernel will have it. If you've compiled your own kernel, you can check on this detail by entering the kernel configuration utility (make xconfig or similar) and looking under File Systems -> Partition Types. Be sure that the EFI GUID Partition Support option is checked.
FreeBSD supports GPT, and can boot from it; however, this support is very kludgy, as of FreeBSD 7.2. To date, I have been unable to get FreeBSD to boot from a disklabel partition converted from an MBR disk, although the FreeBSD live CD can read that partition just fine. The FreeBSD installer also gets confused by GPT disks; it tends to treat them as MBR disks, which produces a corrupt MBR and a non-working installation.
I have successfully installed FreeBSD on GPT disks twice, but both times involved a conversion process. The simpler procedure, in broad outline, was as follows:
The system was then bootable and FreeBSD worked fine from its converted GPT partitions. To create a multi-booting system with FreeBSD and Linux (which I did on just one of my two tests), I had to jump through additional hoops:
title FreeBSD 7.1
root (hd0,2)
chainloader (hd1,5)/sda.mbr
In this case, (hd0,2) was GRUB's identifier for the FreeBSD
root partition and (hd1,5) was the idenfier for the Linux
/boot partition where I'd stored the MBR copy.
The effect of this configuration is that, when I selected the FreeBSD entry from the GRUB menu, GRUB launched the copy of the MBR as if it were the boot sector on the disk. This code then took over and launched FreeBSD's native boot loader.
For more information, try this page, which provides FreeBSD-specific instructions on installing FreeBSD on a GPT disk.
Note that the gpt utility is FreeBSD's GPT-handling tool. It includes the ability to create GPT partitions and it has its own MBR-to-GPT facility. This facility can nominally split out a BSD disklabel into GPT partitions; however, when I've tried this it's produced overlapping GPT partitions, so it seems to be buggy (or at least, the version shipped with FreeBSD 7.1 for x86-64 is buggy).
I have not attempted to boot NetBSD from a pure-GPT disk. The NetBSD 5.01 installer assumes that the system is using MBR. (In fact, I had some install problems for a test installation that may have been related to some remnants of GPT data on the disk.)
I have discovered this page (see also another page on the same project), which describes a new (beta-level, as of July 2009) GPT-aware boot loader for NetBSD. In theory, it should be possible to follow a procedure similar to that described for FreeBSD, but using this new NetBSD boot loader, to get NetBSD to boot from a GPT disk.
According to Microsoft's Windows and GPT FAQ, no version of Windows through Windows 7 can boot from a GPT disk unless the computer uses UEFI. To boot from a GPT disk, you need a version of Windows for the Itanium CPU or Windows Vista or later on a UEFI-based system.
Microsoft's FAQ is a bit pessimistic. It is possible to boot Windows from a GPT disk on a BIOS-based computer, but the ways to do this are hacks. They fall into two categories:
A hybrid MBR is a modified GPT protective MBR that uses up to three of the MBR's primary partitions to point to up to three GPT partitions. (The remaining MBR primary partition contains an EFI GPT partition entry.) You can create a hybrid MBR using the h option on GPT fdisk's recovery & transformation menu, or you can use the separate gptsync utility, which ships with Fedora's anaconda package and sometimes in other packages with other distributions.
Unfortunately, hybrid MBRs are ugly and dangerous hacks. Apple relies on them to get Windows booting on its EFI-based Macs. (Mac firmware includes a BIOS compatibility mode, so the Mac looks like a BIOS-based computer to Windows, which doesn't support the 1.x version EFI that Macs use.) Many things can go wrong with hybrid MBRs, so I strongly recommend avoiding them if at all possible.
The other option, UEFI DUET, is much more flexible and less dangerous than a hybrid MBR, but it's also much harder to set up. The UEFI DUET software was written as a software development tool and, until fairly recently, was very difficult to get working. Even today (mid-2011), the best package I'm aware of for the job is tedious to set up, as described on my UEFI DUET Web page. If you want to convert an existing system to boot in this way, you can read this article—but be aware that there's a good chance you'll trash your Windows installation, particularly if you're not careful or don't understand what you're doing. If you want to go this route, I strongly recommend you begin by doing a test installation on a spare hard disk and then convert your existing system once you've gotten your test system running in UEFI mode. Even when everything works perfectly, the UEFI DUET path works only with 64-bit versions of Windows Vista or 7; Windows XP and 32-bit versions of Vista and 7 can't be booted in this way. Despite these caveats, UEFI DUET or something like it may become extremely important in the future. An easier-to-install and more reliable version could provide a lifeline for those who need to upgrade their hard disks in the future.
I'm not sure why Microsoft has chosen to limit Windows by not supporting GPT boots on BIOS-based computers. This really is stunningly short-sighted of Microsoft. Do they really expect that nobody will need to replace a failed hard disk on a BIOS-based computer during Windows 7's lifetime, and opt to install an over-2TiB drive? Until a better solution than hybrid MBRs or the current state of UEFI DUET comes along, the combination of GPT, a legacy BIOS, and Windows just isn't a good one.
Hybrid MBRs, described in more detail in the Hybrid MBRs section of this document, can create real boot headaches. This is because boot loaders can often become confused by hybrid MBRs. In my experience, GRUB, GRUB2, and Chameleon can all do strange things, typically ignoring either the MBR or the GPT side of a hybrid configuration, even when the boot loader is nominally capable of handling either type. Thus, you may need to experiment to find a configuration that works for you.
Go on to "Hybrid MBRs"
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.