From owner-freebsd-fs@FreeBSD.ORG Thu Aug 9 12:11:53 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 724BE106566B; Thu, 9 Aug 2012 12:11:53 +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 316E48FC14; Thu, 9 Aug 2012 12:11:52 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 35AE47E896; Thu, 9 Aug 2012 22:11:51 +1000 (EST) Message-ID: <5023A907.7060800@freebsd.org> Date: Thu, 09 Aug 2012 22:11:51 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <50237B73.9040301@freebsd.org> <5023979B.4010903@yandex.ru> In-Reply-To: <5023979B.4010903@yandex.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 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: Thu, 09 Aug 2012 12:11:53 -0000 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 ", but manipulating an existing pmbr for a GPT specific subcommand smells dodgy to me. >> - 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. >> - 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. I would argue it's a POLA violation at the very least to manipulate the pmbr when the user asked for something else. I certainly started my hunting expecting to find the GPT changing in some subtle way when FreeBSD wrote it out compared to what Windows writes. 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. Cheers, Lawrence