Date: Fri, 10 Aug 2012 12:13:00 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org> Subject: Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader Message-ID: <50246E2C.1070604@freebsd.org> In-Reply-To: <C43A8456-1B69-47BE-AFB5-3288CD16E789@xcllnt.net> References: <50237B73.9040301@freebsd.org> <5023979B.4010903@yandex.ru> <5023A907.7060800@freebsd.org> <C43A8456-1B69-47BE-AFB5-3288CD16E789@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[Note: all mail to Marcel is currently bouncing due to a dsbl entry for xcllnt.net's MX] On 08/10/12 00:38, Marcel Moolenaar wrote: > > On Aug 9, 2012, at 5:11 AM, Lawrence Stewart <lstewart@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... That sounds like reasonable (and better) behaviour to me, but modulo Andrey's comments about some BIOS-based systems not booting without the pmbr partition being set to active, switching to this behaviour seems as though it may cause issues. >>>> - 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. On the HP system I'm seeing this on, it tries EFI boot sources first, then falls back to BIOS boot sources second. As a result of installing Win 7 from the DVD's EFI bootcode, which in turn sets up GPT and installs the Win 7 x64 EFI boot loader, Win 7 will only boot from the EFI boot loader on this system. After the pmbr entry gets the 0x80 active flag set by gpart, all subsequent reboots fall through from the EFI boot sources to the BIOS boot sources i.e. there is no way with this set up that Win is attempting to boot when the firmware switches to BIOS, as the pmbr has no boot code in it. Either the Win 7 EFI bootcode is being run and making a conscious choice to bail, or the HP EFI firmware is seeing the 0x80 in the pmbr and skipping running the Win 7 EFI bootcode. Not sure if there's a way I can tell which one is the case? >>>> - 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. Right, I didn't understand that the pmbr is actually part of the GPT metadata and therefore should always be written to disk as part of any GPT related gpart command. >> 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? I'm not very fluent in all this so I won't answer your question directly, but rather walk through a scenario and hopefully you can comment on how your proposal works in this case... Taking my desired HP configuration as the example: - Win 7 installed as an EFI boot source - FreeBSD doesn't have EFI boot support, so it has to be installed to boot via pmbr bootcode + gpt(zfs)boot in a freebsd-boot GPT partition - In the HP's firmware config, I choose whether to try boot from EFI or "legacy" (BIOS) sources first. Currently I try from EFI first. - In this arrangement, the firmware starts in EFI mode and will always boot Win 7 as it's the only bootable EFI payload installed. - Using the F9 key on boot, I get a menu to choose the boot source, and with FreeBSD installed to boot via pmbr bootcode + gpt(zfs)boot, the only way to get FreeBSD to start is to select "Legacy HDD" as the boot source, which switches firmware to BIOS and boots from the bootcode in the pmbr, which in turn executes gpt(zfs)boot from the freebsd-boot GPT partition. As I understand things, the above scenario ensures FreeBSD always thinks the firmware is BIOS even though an EFI bootloader is installed and functional. Therefore, your proposed tweaks don't handle this case as gpart will think it's running on a BIOS systems and happily tweak the pmbr in ways which can (and in this case do) break the EFI booting. The only way I can see to get smart about this would be to actually look for the existence of an EFI system partition and look to see if there is an active bootloader payload in there. Sounds pretty gross to me but I can't think of a way around this. This of course all gets greatly simplified when FreeBSD grows EFI boot support. However in the meantime, I see the above as the only viable solution to dual boot Win 7 EFI and FreeBSD 9 on the same disk (please suggest alternatives if I'm missing something obvious). Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50246E2C.1070604>