[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grub mishandles corrupt/missing primary GPT
From: |
Chris Murphy |
Subject: |
Re: grub mishandles corrupt/missing primary GPT |
Date: |
Thu, 24 Oct 2013 12:17:56 -0600 |
On Oct 24, 2013, at 7:39 AM, "Lennart Sorensen" <address@hidden> wrote:
> On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote:
>> While technically a violation of the UEFI spec, I think this can be worked
>> around by considering the disk GPT if the first entry in the MBR is type
>> 0xEE. I don't know of a hybrid MBR implementation where an entry other than
>> the first is 0xEE.
>
> Well everyone other than Microsoft seems to understand how useful support
> for hybrid setups can be and hence support them.
Support is a very strong word. They're basically a craptastic workaround for
prior unfortunate choices.
Apple uses them, it hardly supports them. Their tools routinely nuke hybrid
MBRs in favor of PMBRs rendering the secondary OS unbootable; if the MBR and
GPT aren't sync'd, they will bone the correct MBR with wrong GPT information,
rendering the secondary OS unbootable and data inaccessible. And it does this
silently.
I think it's OK to tiptoe around hybrid MBRs, and do something sensible, if
possible. Supporting them is out of scope because there's no standard or agreed
upon way to interpret them.
>
>> But if there is no 0xEE entry at all, this is identical to a formerly GPT
>> disk repartitioned as MBR by a utility that doesn't know anything about GPT,
>> and thus doesn't erase the stale GPT data - and therefore must be treated as
>> MBR.
>
> That is true. That does not mean there must ONLY be a 0xEE entry.
Well, there must be only an 0xEE entry to treat the disk as a pure GPT disk.
Once there's 0xEE and 1-3 additional entries, it's a hybrid logic, very few
combinations of which are sane. When the MBR and GPT don't agree with each
other, which on Macs is actually somewhat common once you've used Bootcamp
Assistant, because users think it's OK to resize OS X volumes in OS X Disk
Utility, and then use free space to either create an additional OS X partition,
or grow an existing Windows partition from within Windows. Oops, now the MBR
and GPT don't agree with each other, so which one is correct? Well, it's
ambiguous.
With a few exceptions, there's actually no way to know what's correct, which is
why hybrid MBRs are ultimately shit. But again, I'm fine dodging piles of crap
rather than cleaning up other people's messes.
>
> I do wonder how Windows handles booting with a corrupt primary GPT.
> Would you happen to know? (A quick google search didn't find an answer
> to the question unfortunately).
I haven't tested it because I don't have a UEFI machine here, only Apple EFI.
So I'm stuck with CSM-BIOS mode booting of Windows, which means it will only
use MBR. I haven't figured out UEFI within qemu/kvm, and if that can boot
Windows in UEFI mode.
>
>> The UEFI spec says "Software should ask a user for confirmation before
>> restoring the primary GPT" and yet it also requires the unspecified software
>> fix the primary GPT if corrupt. The spec actually uses the word "must". So
>> per usual, the spec has rather lofty demands.
>
> So it must fix it after asking the user for confirmation?
Yes it's just being silly. But the take away is that (partitioning) tools are
behaving wrongly if they understand GPT, yet ignore or can't fix problems with
either GPT. The spec only says software, it doesn't specify what software, so
I'm assuming partitioning tools. Obviously the kernel is software, but it's not
in a position to ask the user anything.
Chris Murphy