bug-parted
[Top][All Lists]
Advanced

[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)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]