gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

[Marcel Moolenaar]

On Aug 9, 2012, at 5:11 AM, Lawrence Stewart <lstewart at freebsd.org> wrote:

> Hi Andrey,
> 
> On 08/09/12 20:57, Andrey V. Elsukov wrote:
>> On 09.08.2012 12:57, Lawrence Stewart wrote:
>>> After identifying the cause of the problem and a workaround (please see the README.txt at the above
>>> URL for full details and pre/post gpart dumps of the MBR+GPT), I have the following questions:
>>> 
>>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>> 
>> AFAIK, this was added because some BIOS could not boot without it.
> 
> Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
> /boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
> subcommand smells dodgy to me.

Agreed. The original design of gpart was such that it could preserve
what it needed and only limit changes to what it was asked to do.

For the GPT scheme this meant that it would simply read the entire
PMBR, keep it in memory and write it back when updates are made.

etc...

> 
>>>  - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>> 
>> This question you should ask to the Microsoft. :)
> 
> Perhaps I should rephrase my question as:
> 
> Is the MS bootloader's behaviour reasonable/unreasonable based on what
> people know of the relevant specs? My current guess why it behaves like
> this is that if it sees an MBR partition marked active, it simply
> assumes another OS is in charge and therefore bails out at the Windows
> EFI boot stage.

I think the key distinction may be between BIOS and (U)EFI. When BIOS
is the firmware, beaviour is different from when booting (U)EFI. It is
possible (likely?) that Windows has different behaviour based on the
firmware as well.

> 
>>> - Should gpart be silently rewriting the protective MBR entry at all when only asked to make changes
>>> to the GPT?
>> 
>> The PMBR is part of GPT metadata described in the UEFI spec. So, I think it can.
> 
> Can and should are two different things.

It should. The problem is not with geom_part writing the PMBR, it's
with what we write and why. This loops back to the ol' compatibility
discussions.

> We have a specific gpart command to put a pmbr in place so I think it's
> reasonable to expect other GPT specific commands not to fiddle with the
> pmbr.

I beg to differ. The PMBR is an integral part of the GPT spec, so it
is not at all reasonable to expect the GPT scheme to bank on something
or someone else to create or maintain it.

What about the following: We have the kernel keep track of the firmware
used. On x86 this is either BIOS or UEFI in the common case. Other F/W
implementations like U-Boot, OFW, etc are possible as well, especially
on non-x86 machines.

The geom_part scheme uses this information to determine how to behave
with respect to the PMBR. When booted with BIOS, non-standard stuff is
accepted by virtue of what we've seen in the field. With UEFI we can
start off being anal (read: strictly compliant) and extend out based
on what we run into.

In particular: this way we also don't mess up the EFI/GPT support that
is there on ia64.

Thoughts?

-- 
Marcel Moolenaar
marcel at xcllnt.net