From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 10:45:55 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 1B8B91065672; Fri, 10 Aug 2012 10:45:55 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id CB82B8FC18; Fri, 10 Aug 2012 10:45:54 +0000 (UTC) Received: from [172.16.7.56] (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 7577F7E820; Fri, 10 Aug 2012 20:45:53 +1000 (EST) Message-ID: <5024E661.6080202@freebsd.org> Date: Fri, 10 Aug 2012 20:45:53 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <50237B73.9040301@freebsd.org> <5023979B.4010903@yandex.ru> <5023A907.7060800@freebsd.org> <50246E2C.1070604@freebsd.org> <5024C6EB.1040109@FreeBSD.org> In-Reply-To: <5024C6EB.1040109@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net 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: Fri, 10 Aug 2012 10:45:55 -0000 On 10/08/2012 6:31 PM, Andrey V. Elsukov wrote: > On 10.08.2012 6:13, Lawrence Stewart wrote: >>> 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? > > It seems this is not enough. The problem, that Lawrence has, is not > related to BIOS/UEFI. Automatic detection of various standard violation is > handy for our users, but sometimes false positives occur. > > To solve all problems it seems we need to introduce several quirks, e.g.: > > #define GPT_QUIRK_BOOTCAMP 0x0001 /* boot camp supported */ > #define GPT_QUIRK_MSLOADER 0x0002 /* don't set Active flag to the PMBR entry */ > #define GPT_QUIRK_IGNOREPMBR 0x0004 /* don't require PMBR entry */ > > The same quirks should be added to the loader(8). This sounds like a useful proposal. I will note though that I can't be totally sure if my issue is caused by the MS EFI loader or my HP EFI firmware seeing the active flag and failing to boot. My hunch is it's the MS EFI loader because the HP EFI firmware still shows the MS EFI payload as a valid boot option and seems to switch to it temporarily before falling through to legacy BIOS boot. There are no diagnostic messages or anything shown on screen though so that makes it hard to know what's going on. Cheers, Lawrence