[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPT Question
From: |
Christian |
Subject: |
Re: GPT Question |
Date: |
Fri, 11 Nov 2011 19:35:42 +0100 |
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.