On ven, 2011-11-11 at 12:55 -0500, Rod Smith wrote: > 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. >
Thanks for the detailed explanation! :) Christian.
