On 01/25/2014 10:59 PM, Edwin wrote:Yes; you just need to re-create the protective MBR. This can be done with the "n" option on the experts' menu.
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?
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.
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
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 <firstname.lastname@example.org@rodsbooks.com <mailto:email@example.com><mailto:firstname.lastname@example.org>> 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
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
>>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
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
>>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
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