[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19137: mklabel gpt created invalid Protective MBR
From: |
Brian C. Lane |
Subject: |
bug#19137: mklabel gpt created invalid Protective MBR |
Date: |
Fri, 21 Nov 2014 12:36:27 -0800 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Fri, Nov 21, 2014 at 08:50:24AM +0100, Ulrich Windl wrote:
> GNU Parted 2.3 creates an invalid Protective MBR (for a 3MB test image):
> --
> hexdump -C gptgood
> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 000001c0 01 00 ee fe ff ff 01 00 00 00 ff 17 00 00 00 00 |................|
> 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
> [...]
> ---
>
> Partition #1 (or is it #4?) decodes as this:
> --
> Legacy MBR:
> MBR Signature = aa55
> Unique Signature = 00000000
>
> Partition 1:
> Boot Indicator : non-bootable
> Starting Cylinder = 0
> Starting Head = 1
> Starting Sector = 0
> System ID = 0xee
> Ending Cylinder = 1023
> Ending Head = 63
> Ending Sector = 254
> Relative Sectors = 1
> Total Sectors = 6143
> --
> First, UEFI says the StartingCHS should be set to 0x000200, that should be
> 0/0/2, not 0/1/0. Second, UEFI says Ending CHS should be set to the CHS
> address of the last logical block on the disk, _or_ 0xffffff if it's not
> possible to represent the value in the field. For my 3MB image that value is
> not correct.
The code has been like this since the beginning of time :) You're right,
the CHS values aren't exactly correct, but given that they have been
that way for a long time, and nothing we know of is having an actual
problem with them, I'm reluctant to change them for fear that there is
firmware in the wild that expects these values.
In my previous email I said SizeInLBA was correct, which isn't what
you were talking about :)
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)