On 11/11/2011 12:00 PM, Christian <mail.krist...@yahoo.it> 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
rodsm...@rodsbooks.com
http://www.rodsbooks.com
