Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)

[Rod S. <rod...@ro...>]

On 01/25/2014 10:17 PM, Edwin wrote:
> When using gdisk on my disk (in the state as it was pre-installed by OEM
> for Windows 8) I encountered an error writing a new partition table to
> my disk with gdisk.
>
> After creating new partitions and writing to disk (w) I get this error:
>
>  >>Warning! An error was reported when writing the partition table! This
> error
>  >>MIGHT be harmless, or the disk might be damaged! Checking it is
> advisable.
>
> After a bit of debugging this turned out to be caused by WriteMBRData
> returning a failure code.
>
> This is caused by one of the checks in WriteMBRData:
> CreateExtended() -> IsLegal() -> DoTheyFit()
>
> DoTheyFit() returns a failure in this case which is as far as I can tell
> due to the pre-existing protective MBR on my disk.
>
> Printing the MBR using recovery (r) and (o) for the existing MBR gives:
>
>  >>Recovery/transformation command (? for help): o
>  >>
>  >>Disk size is 1000215216 sectors (476.9 GiB)
>  >>MBR disk identifier: 0xB65D55C8
>  >>MBR partitions:
>  >>
>  >>Number  Boot  Start Sector   End Sector   Status      Code
>  >>   1                     1   4294967295   primary     0xEE
>
>
> The End Sector being larger than the disk size causes the DoTheyFit()
> check to fail. Since I am not an expert in this area I am not sure if it
> is safe to remove this check.

No, it's not. Your protective MBR violates the GPT specification. The 
GPT specification (on pp. 97-98 of the EFI 2.3.1 specification) clearly 
states that the protective MBR's 0xEE partition should begin on sector 1 
and have a size of one minus the size of the disk, or 0xFFFFFFFF *if the 
disk is larger than can be represented in that field*. Yours has that 
larger size but the disk is small enough that a smaller protective MBR 
*should have* been used.

That said, gdisk could handle the problem better than it does. I'll look 
into improving it.

> It makes some sense to me to remove this
> check since as far as I understand the protective MBR should cover at
> least the entire disk.

No; as I say, the spec doesn't permit the field to be larger than the 
disk size.

> In fact for the protective MBR a more logical
> check might be to fail if End Sector is smaller than disk size?

That would fail for over-2TiB disks and for disks that use hybrid MBRs. 
(The latter technically violate the GPT spec, but Apple uses them 
heavily on Macs that dual-boot with Windows, and sometimes with other 
OSes. Thus, gdisk supports hybrid MBRs.)

> I assume that gdisk normally creates a new protective MBR on an empty
> disk exactly equal to the size of the disk?

On sub-2TiB disks, yes. On larger disks, it creates a 0xEE partition of 
the maximum possible size, as per the spec.

> Since this error made me nervous about the health of my disk/data at
> first and since my OEM (Lenovo) delivered this MBR in this state from
> factory, this could probably happen to others as well. Therefore I
> wanted to share my findings in the hope that others may benefit.

You might consider filing a bug report with Lenovo, since their 
as-delivered protective MBR was defective. Be sure it was as delivered, 
though; if you used some other tool to resize your Windows partitions, 
THAT tool may have damaged the protective MBR. (Because gdisk can't 
shrink filesystems and most OEMs deliver computers with all but trivial 
amounts of disk space pre-allocated, I suspect that you did use 
something else to resize at least one partition.) Some tools create 
fresh protective MBRs as a matter of course. GParted and parted both do 
this, for instance, although these tools create protective MBRs with 
appropriately-sized 0xEE partitions.

-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com