Re: grub mishandles corrupt/missing primary GPT

[Chris Murphy]

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