Re: GPT Question

[Christian]

On ven, 2011-11-11 at 12:55 -0500, Rod Smith wrote:

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

Thanks for the detailed explanation! :)

Christian.