http://www.rodsbooks.com/gdisk/booting.html
Booting from GPT
Last Web page update: 3/20/2010, referencing GPT fdisk version 0.6.4
One of the challenges of GPT is that of booting from it. In late
2009,
support for booting from GPT was 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.
General Comments: EFI vs. 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 mainstream PCs. Among
common computers, Apple Macintoshes are the systems that are most
likely to
use EFI. A few mainstream motherboard manufacturers are now including
EFI
support in their products. This support is usually of the United EFI (UEFI) variety. One
obscure
product, UEFI DUET, enables booting an EFI environment from a floppy
disk
or USB flash drive on a BIOS-based computer. Unfortunately, I know of
no
easy-to-use download link for UEFI DUET binaries, although you can
obtain
source code from Tianocore.
The EFI specification includes an EFI System Partition (ESP) as a
storage place for EFI drivers. 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.
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. 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. Some boot loaders intended for use with
BIOS-based systems and GPT disks require you to have a BIOS Boot Partition
(GPT fdisk code EF02) on the disk. This isn't true of all such boot
loaders, though (it isn't true of the patched versions of GRUB 0.97
I've
used, for instance), but you may want to create such a partition just
in
case. GRUB2, in particular, places its second-stage boot loader code in
the
BIOS Boot Partition, without a filesystem. Thus, in the case of GRUB2,
the
BIOS Boot Partition can be quite small—perhaps as small as 32KiB,
although I recommend making it 100-200 KiB, if possible.
In my tests, I've found that GNU Parted (version 1.7.1) tends 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.
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.
Linux, GRUB, and LILO
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
definitely have GPT-enabled versions of GRUB 0.97, but openSUSE 11.0
does
not.) 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:
- Mount your /boot partition over the SRCD's /boot
directory, or copy the contents of your /boot/grub directory
over the SRCD's directory.
- If your drives' device filenames are different under SRCD than
under a normal boot of your distribution, edit /boot/grub/devices.map
appropriately.
- Type grub-install /dev/sda or grub-install
/dev/hda to re-install GRUB.
- Reboot. Assuming GRUB is properly configured, your system should
now boot.
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 has officially ceased. A new boot
loader, known as GRUB 2, is
now
under development instead. This boot loader includes GPT support;
however,
it's still officially under development. I've tried it briefly and
after
some initial user-error troubles, it seemed to work as well as legacy
GRUB.
Note that the GRUB 2 configuration file format is slightly different.
The
two versions of GRUB also 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 loaders,
and
other Linux distributions are sure to follow eventually.
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.
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
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:
- I installed FreeBSD as normal on an MBR disk. I ensured that no
vital FreeBSD partitions were at the very start or very end of the
disk, so as to avoid problems during the conversion stage. I also left
a little free space on the disk.
- I used gdisk to convert the disk to GPT format,
including converting the BSD disklabel partitions. I then created a
small (30-sector) GPT partition of type "FreeBSD boot" (0xA501 in gdisk).
This partition would ultimately hold the GPT-aware FreeBSD boot loader.
Note that this partition is not mounted (it's not for the /boot
directory; it's more like FreeBSD's version of a BIOS Boot Partition).
I created the boot partition immediately before the root partition in
one test and immediately after it in another. I don't know if this
ordering is critical, though.
- I booted the FreeBSD live DVD and copied the /boot/pmbr
and /boot/gptboot files from the FreeBSD installation (now in
GPT form) to the temporary live DVD's filesystem. I then unmounted its
filesystem.
- I typed gpt boot /dev/ad0. You might need to
change the device filename for your system and/or use the -b
or -g options to point to the pmbr and gptboot
files, respectively. This command installs FreeBSD's GPT-aware boot
loader. The pmbr file is the MBR boot loader, while the gptboot
file is the GPT-specific second-stage boot loader that ends up in the
FreeBSD boot partition. (A key point is that this partition must be
large enough to hold the gptboot file, but shouldn't be too
much larger, since the whole thing is loaded into memory during boot.)
- I edited /etc/fstab so that the system mounted the GPT
partitions rather than the BSD disklabel partitions.
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:
- Using a Linux live DVD, I copied the MBR from the GPT boot disk
to a file, as in dd if=/dev/sda of=sda.mbr bs=512 count=1.
I placed this file in my Linux /boot partition.
- Using the Linux System Rescue CD, I re-installed GRUB on the boot
disk. I also created an entry for FreeBSD:
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.
Another useful resource is the Installing FreeBSD on GPT
page, which describes using FreeBSD's gpart utility and
manually
running the FreeBSD installation scripts without using the usual
installation front-end utility. I've never tried this method, so I
can't
comment on it.
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).
NetBSD
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.
Windows
According to Microsoft's Windows
and GPT FAQ, no version of Windows through Vista can boot from a
GPT
disk unless the computer uses EFI. To boot from a GPT disk, you need a
version of Windows for the Itanium CPU or Windows Vista or Windows
Server
2008 on EFI-based systems.
My own experiments at working around Microsoft's limitations have
been
unsuccessful, with one partial exception: It's possible to create a hybrid MBR,
which 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.
In my initial experiment, I installed Windows Vista on an MBR disk
and
converted it to GPT, whereupon Windows refused to boot. Using
gptsync restored Windows' bootability; however, the
configuration
was extremely delicate. During my experiments, Windows became
unbootable
again and I was unable to restore it to bootability. I'm still not sure
precisely what happened. In a later experiment, I used GPT fdisk to
create
a hybrid MBR configuration with Windows 7 RC and Linux. This setup has
been
more stable, although it required a lot of fiddling to set it up. (I
was
using this system as a testbed for GPT fdisk's hybrid MBR support.)
Unfortunately, Windows 7 (at least as of the Release Candidate, or
RC,
version) is no better than its predecessors in terms of GPT support. In
my
own tests, Windows 7 RC (x86-64 version) refuses to install on a GPT
disk,
at least on a BIOS-based system. Installing on MBR and converting to
GPT
renders Windows unbootable, even with the help of a patched GRUB 0.97
or
GRUB 2 (Windows loads enough to complain and sulk like a recalcitrant
toddler). Extensive Googling about this problem has turned up no
solution.
My guess (and it's only a guess) is that Windows remains chained,
welded,
and superglued to the BIOS for the initial parts of its boot process,
and
this is preventing it from using GPT. 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? With any luck somebody
will come out with a workaround at some point. (Hybrid MBRs aren't
really a
good option, although they can be barely adequate to achieve certain
multi-booting goals.) In the meantime, the combination of GPT, a legacy
BIOS, and Windows just isn't a good one.
The one ray of hope for booting Windows on a pure-GPT configuration
(without a hybrid MBR) is to employ UEFI DUET. The basic idea is to
have
the BIOS boot the DUET software, which implements an EFI environment.
This
environment can then boot Windows from a GPT disk. This
post on the InsanelyMac forum describes a procedure for converting
an
existing MBR Windows setup to boot from GPT; however, it requires
either a
BIOS with EFI support or a working UEFI DUET system. It will also
reportedly work only with 64-bit versions of Windows Vista or Windows
7,
not with Windows XP or any 32-bit version of Windows. To date, I've
been
unable to get this procedure to work because the UEFI DUET binary I was
given hangs after it loads to a boot menu. With any luck somebody will
come
out with a simple EFI-based boot loader, similar to the ones used to
boot
Mac OS X on non-Apple hardware, that will enable relatively easy
Windows
installation to and booting from GPT disks. If you want to investigate
the
current state of this approach, check the Tianocore Web site, obtain the
EFI
Dev Kit (EDK), compile it, and deploy DUET on a floppy disk or USB
flash
drive.
Mac OS X
As noted earlier, 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.
Although I've tested USB flash drives with GPT partitions on Mac
computers,
I haven't done extensive testing of boot disks manipulated by
gdisk on Macs. Thus, I can't say if there are any caveats for
this
combination.
Hybrid MBR Issues
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
rodsm...@rodsbooks.com. Thanks.
Return to my main web page.
