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.

Some info on my gdisk / partition:

>>GPT fdisk (gdisk) version 0.8.8
>>
>>Partition table scan:
>>  MBR: protective
>>  BSD: not present
>>  APM: not present
>>  GPT: present
>>
>>Found valid GPT with protective MBR; using GPT.

After creating new partitions and writing to disk (w) I get this error:

>>Command (? for help): w
>>
>>Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!!
>>
>>Do you want to proceed? (Y/N): y
>>OK; writing new GUID partition table (GPT) to /dev/sda.
>>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. 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. In fact for the protective MBR a more logical check might be to fail if End Sector is smaller than disk size?

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

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.

Best regards,
Edwin

(I am not subscribed to the mailing list so if you need more information please e-mail me directly)