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:59 PM, Edwin wrote:
> Hi Rod,
>
> Thanks for your quick reply. Your explanation makes sense and it
> explains the error I got.
>
> Is there a way in gdisk to fix my MBR? In other words to set the
> non-compliant end-sector to the right value?

Yes; you just need to re-create the protective MBR. This can be done 
with the "n" option on the experts' menu.

> Actually you might be right about another cause. In hind-sight I did use
> the built-in windows disk management tool to shrink the windows
> partition. Should have thought of that earlier... also did not realize
> that would have changed the MBR but as you said that probably was the
> cause then.

The Windows partitioning tools have many problems, but I don't think 
I've heard of them creating invalid protective MBRs. I don't know 
offhand if they re-create or modify protective MBRs as a matter of 
course, the way GParted and parted do. Of course, this could be a new 
bug -- say, introduced in Windows 8.1.

FWIW, I've just revised gdisk to auto-correct this problem when loading 
the partition table, assuming everything else looks OK. If there are 
other problems when loading, a verify ("v" on any menu) operation should 
display a warning, and a write operation will also warn about the issue. 
The changes are in the GPT fdisk git repository, in case you want to 
check it out.

> On Sat, Jan 25, 2014 at 9:45 PM, Rod Smith <rod...@ro...
> <mailto:rod...@ro...>> wrote:
>
>     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... <mailto:rod...@ro...>
>     http://www.rodsbooks.com
>
>


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