GPT - (last) call for action

Matthew Dillon dillon at
Sun Jun 10 17:52:43 UTC 2007

:Technically speaking, the MBR can only have a single partition of
:type 0xEE that covers the whole disk. This is to protect the GPT
:from MBR-specific tools that do not know about the GPT. This is
:not a bootable slice by definition.
:Practice is different. To support bootcamp on Intel-based Macs,
:the MBR will have real partitions that mirror GPT partitions or
:otherwise describe partitions outside the GPT controlled area.
:These can be bootable partitions and the protective partition
:(the one with type 0xEE) will not cover the whole disk anymore.
:The nasty part is keeping MBR and GPT partitions in sync, so it
:may be better to have the MBR partition fall outside the GPT
:controlled area. This can be done because the GPT header contains
:the LBA of the first and last sectors on the disk that can be
:assigned to a partition. You can free up space for MBR partitions
:after the primary GPT table by adjusting the first LBA. In the
:MBR partition you can put a GPT aware boot loader that uses the
:GPT to find the real partitions...
:Marcel Moolenaar

    In the bootcamp approach, is the GPT (0xEE) slice the first slice,
    and the bootcamp slice the second slice?  I'm assuming it is.  Do
    they mirror a GPT partition or do they use the uncontrolled area

    I like the mirroring approach, because I can make the label manager
    just treat the special MBR slice (s2) as being part of the integrated
    GPT spec (which it is).

    From the end-user's point of view he would just do something like
    'gptlabel -e ad0' and one of the GPT partitions listed would be the
    'boot' partition.  gptlabel would recognize the special nature of
    the partition and automatically and silently adjust the special MBR
    slice (s2) to match it.

    I don't like the out-of-band approach... I definitely want the partitions
    to be within GPTs managed area, at least for newly minted disks.  With
    the in-band approach the gpt labeling program can take care of any
    special compatibility cases in a fairly straightforward and controlled

					Matthew Dillon 
					<dillon at>

More information about the freebsd-current mailing list