Not sure if it makes sense for GPT disks, but my existing protective MBR has a non-zero disk signature (the 4-byte one). The auto-correct will change it to a zero disk signature (of course there still is the GPT header disk guid).

Does the MBR disk signature matter for any OS/firmware (perhaps for windows that could have set this in the first place)?

I actually just tried to create a new MBR with a zero disk signature and that caused my laptop not to boot anymore from HD. Somehow the UEFI firmware / boot loader must depend on the disk signature since the machine did not progress past the "bios" screen. Anyway when I reset the disk signature back to what it was earlier the machine booted from HD again. Would it be safer to have the MakeProtectiveMBR function keep the existing signature when it auto-corrects?


On Sat, Jan 25, 2014 at 11:00 PM, Rod Smith <> wrote:
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 <
<>> 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

          >>Warning! An error was reported when writing the partition
        table! This
          >>MIGHT be harmless, or the disk might be damaged! Checking it is

        After a bit of debugging this turned out to be caused by
        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

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

    Rod Smith <>