From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:43:35 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5C2106564A; Fri, 17 Feb 2012 15:43:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4DF78FC0A; Fri, 17 Feb 2012 15:43:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08997; Fri, 17 Feb 2012 17:43:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3E75A4.3040400@FreeBSD.org> Date: Fri, 17 Feb 2012 17:43:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> In-Reply-To: <20120217.232843.2212672671663755444.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:43:35 -0000 on 17/02/2012 16:28 Hiroki Sato said the following: > Andriy Gapon wrote > in <4F3E3000.9000206@FreeBSD.org>: > > av> -----BEGIN PGP SIGNED MESSAGE----- > av> Hash: SHA1 > av> > av> on 17/02/2012 09:04 Hiroki Sato said the following: > av> > No, the issue is our gptloader assumes the backup header is always located > av> > at the (physical) last sector while this is not mandatory in the UEFI > av> > specification. > av> > av> Are you sure? > > Yes, sure. Sorry, I haven't really given a thought to what you wrote below. You said that "this is not mandatory in the UEFI specification" and I gave the quotes which say that it is. Also keep in mind that BIOS and other OSs know nothing about FreeBSD GEOM. > In the gm0->md0+md1 case, the last LBA of the "device" is > changed (growed in size) but they can still have a valid backup > header at "the last LBA - 1" before an attempt to grow the size of > the volume as the last paragraph of your excerpts says. If we > *choose* to grow the device size permanently, the backup header must > be relocated at the new last LBA. However, before the relocation > happens, the specification says both the primary and secondary header > must be valid in the previous device size. This is my understanding. > > This means software should assume the device size can grow and should > not assume the backup header is always located at the last possible > LBA on the device. If AlternateLBA does not match "the device size - > 1", the software should recognize the location of the backup header > based on the information in the primary header first. The gptboot > does not do so currently. I didn't give it a try actually but the > attached patch is what I want to say. > > -- Hiroki -- Andriy Gapon