Re: GPT Question

[Rod Smith]

On 11/11/2011 12:00 PM, Christian <address@hidden> wrote:
> On gio, 2011-11-10 at 15:01 +0100, Jim Meyering wrote:
> 
>> Christian wrote:
>>> On mer, 2011-11-09 at 00:16 +0100, Christian wrote:
>>>> Hi,
>>>>
>>>> I created a GPT table on a file (1 MB), using parted 2.2.
>>>> Looking at the hexdump seems that the CHS-start-sector of the GPT
>>>> partition may not be correct. Those are MBR (64 byte) partitions:
>>>>
>>>>   Status  CHS    Type  CHS     LBA start  LBA sectors
>>>>   00      000100 EE    FEFFFF  01000000   FF070000
>>>>   00      000000 00    000000  00000000   00000000
>>>>   00      000000 00    000000  00000000   00000000
>>>>   00      000000 00    000000  00000000   00000000
>>>>
>>>> CHS start bytes are HEAD: 00, SECTOR: 01 CYLINDER: 00.
>>>>
>>>> Using the formula:
>>>>
>>>> LBA = (CYL * NHEADS + HEAD) * NSECTORS + SECTOR - 1
>>>>
>>>> LBA = (0 * 4 + 0) * 32 + 1 - 1
>>>>
>>>> LBA = 0
>>>>
>>>> But the GPT header is at LBA 1 (as the LBA start field 01000000).
>>>>
>>>> This is an error or CHS values ??are ignored?
>>>>
>>>> Many thanks!
>>>>
>>>> Christian.
>>>
>>> Parted 3.0 have this "error" too.
>>
>> Thanks, but it's not an error.
>> That first sector is called the protective MBR.
>> Note the "type" of EE.
>>
>>   https://secure.wikimedia.org/wikipedia/en/wiki/GPT_Disk
> 
> Oh, thanks for your response! :)
> 
> Sorry but I'm a little confused.
> 
> If the value of CHS (0, 0, 1 (wich corresponds to LBA 0)) is correct,
> why the LBA field indicates LBA 1?
> 
> The CHS values ??must be ignored by a partitioning program?

As a practical matter, GPT partitioning tools ignore the CHS values in
the protective MBR because they aren't really relevant for GPT. The
protective MBR's 0xEE entry serves only to identify the disk as a GPT
disk, as far as GPT utilities are concerned. Since GPT doesn't use CHS
at all, the only utility of these values on a CHS disk is to keep very
old partitioning software (that DOES rely on CHS values) from damaging
the disk.

That said, the UEFI specification is quite explicit about how the
protective MBR should be laid out, and you are correct, Christian, in
suggesting that parted does it wrong. The UEFI specification, version
2.3.1, p. 98, lays it out in its Table 15, which describes the layout of
the protective MBR's 0xEE protective partition entry:

Mnemonic         Byte Offset    Byte Length    Description
--------         -----------    -----------    -----------
BootIndicator         0              1         Set to 0x00 to indicate
                                               a non-bootable partition.

StartingCHS           1              3         Set to 0x000200,
                                               corresponding to the
                                               Starting LBA field.

OSType                4              1         Set to 0xEE (i.e., GPT
                                               Protective)

EndingCHS             5              3         Set to the CHS address of
                                               the last logical block of
                                               the disk. Set to 0xFFFFFF
                                               if it is not possible to
                                               represent the value in
                                               this field.

StartingLBA           8              4         Set to 0x00000001 (i.e.,
                                               the LBA of the GPT
                                               Partition Header).

SizeInLBA             12             4         Set to the size of the
                                               disk minus one. Set to
                                               0xFFFFFFFF if the size
                                               of the disk is too large
                                               to be represented in this
                                               field.

Note that I've copied this over by hand, so there could be typos.

In fact, parted makes two errors:

1) The StartingCHS value should be 0x000200, not 0x000100.

2) On disks too big for a valid EndingCHS value (which is anything
   over about 8 GB), the EndingCHS value should be 0xFFFFFF, not
   0xFFFFFE.

Note that for point #2, 0xFFFFFE is the maximum legal CHS value in the
usual MBR scheme; thus, GPT requires an illegal CHS value be placed in
this field. I have no idea if this was intentional or an oversight by
the people who wrote the UEFI spec.

FWIW, most programs get one or both of these items wrong. IIRC, Mac OS
X's Disk Utility uses 0xFFFFFE as both the starting and ending CHS
values! Also, some BIOS-based computers misbehave if these items are set
in the way the spec requires:

- One motherboard that I owned once hung when the EndingCHS value is
  set to 0xFFFFFF; it had to be set to 0xFFFFFE for the computer to
  boot.

- Some motherboards, including many from Intel, won't boot from a GPT
  disk unless the MBR contains a partition with the "boot flag" set,
  so the BootIndicator byte has to be set in violation of the standard
  (or a hybrid MBR must be used) to boot on such disks. Parted follows
  the spec on this score, which is probably the right thing to do, but
  it's something that users and distribution maintainers should keep
  in mind. I'm rather concerned that Fedora is now using GPT by default
  on fresh BIOS-based installations, for instance.

For these reasons, and because most partitioning tools set the ending
CHS value incorrectly and otherwise seem to ignore these values, IMHO
bringing parted into line with the UEFI spec is a pretty low-priority issue.

-- 
Rod Smith
address@hidden
http://www.rodsbooks.com