Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to di
Brought to you by:
srs5694
Menu
▾
▴
Re: [Gptfdisk-general] GPT fdisk: problem with pre-existing Protective MBR when writing table to disk (w)
|
From: Edwin <edw...@gm...> - 2014-01-26 06:55:55
|
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?
Edwin
On Sat, Jan 25, 2014 at 11:00 PM, Rod Smith <rod...@ro...> 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 <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
>
|
