From owner-freebsd-fs@FreeBSD.ORG Thu Aug 9 14:39:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80DD9106564A; Thu, 9 Aug 2012 14:39:02 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7A28FC16; Thu, 9 Aug 2012 14:39:02 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q79Ecowj070803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Aug 2012 07:38:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=koi8-r Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Marcel Moolenaar In-Reply-To: <5023A907.7060800@freebsd.org> Date: Thu, 9 Aug 2012 07:38:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50237B73.9040301@freebsd.org> <5023979B.4010903@yandex.ru> <5023A907.7060800@freebsd.org> To: Lawrence Stewart X-Mailer: Apple Mail (2.1485) Cc: "freebsd-fs@freebsd.org" , Marcel Moolenaar Subject: Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:39:02 -0000 On Aug 9, 2012, at 5:11 AM, Lawrence Stewart = wrote: > Hi Andrey, >=20 > 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: >>>=20 >>> - Should gpart be writing 0x80 (active) in the protective MBR entry? >>=20 >> AFAIK, this was added because some BIOS could not boot without it. >=20 > Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b > /boot/pmbr ", 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... >=20 >>> - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr? >>=20 >> This question you should ask to the Microsoft. :) >=20 > Perhaps I should rephrase my question as: >=20 > 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. >=20 >>> - Should gpart be silently rewriting the protective MBR entry at all = when only asked to make changes >>> to the GPT? >>=20 >> The PMBR is part of GPT metadata described in the UEFI spec. So, I = think it can. >=20 > 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? --=20 Marcel Moolenaar marcel@xcllnt.net