From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 07:07:05 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 647FC1065674 for ; Fri, 17 Feb 2012 07:07:05 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6F278FC12 for ; Fri, 17 Feb 2012 07:07:04 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H75D7K037408; Fri, 17 Feb 2012 16:05:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H75AJP035952; Fri, 17 Feb 2012 16:05:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Feb 2012 16:04:30 +0900 (JST) Message-Id: <20120217.160430.406937514120319292.hrs@allbsd.org> To: fjwcash@gmail.com From: Hiroki Sato In-Reply-To: References: <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_17_16_04_30_2012_094)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Feb 2012 16:05:29 +0900 (JST) X-Spam-Status: No, score=-104.0 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, MIMEQENC, QENCPTR1, QENCPTR2, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@FreeBSD.org, 000.fbsd@quip.cz, 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 07:07:05 -0000 ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Freddie Cash wrote in : fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato wrot= e: fj> > Jeremy Chadwick wrote fj> > =A0in <20120217030806.GA62601@icarus.home.lan>: fj> > fj> > fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:= fj> > fr> > Sorry, I may be misunderstanding your point. =A0GEOM classe= s don't fj> > fr> > lie, they accurately represent the space. =A0The space prov= ided by a fj> > fr> > gmirror is one block less than the actual space occupied, t= o allow fj> > fr> > for the metadata block at the end. =A0The problem is that G= PT puts fj> > fr> > backup partition tables at the end of the physical (not log= ical) fj> > fr> > device. Create a GEOM device on that drive, and the GEOM me= tadata fj> > fr> > overwrites the backup GPT partition table. =A0Well, the las= t block of fj> > fr> > it, anyway. fj> > fr> > fj> > fr> > But create the GEOM device inside a GPT partition that span= s the fj> > fr> > drive, and things are fine. =A0The GPT backup tables are sa= fely fj> > fr> > outside the GEOM metadata, which is safely outside of the d= ata. fj> > fr> fj> > fr> I wasn't aware you could do that. =A0I was only aware that it= was the fj> > fr> other way around. =A0That (my) misconception seems to also be= relayed fj> > fr> by others such as Miroslav who said: fj> > fr> fj> > fr> >>GPT doesn't play nice with GEOM classes which store their m= etadata fj> > fr> >>on last sector. =A0For example, you can't use gmirror of a = whole drives fj> > fr> >>and use GPT on top of this mirror. (and gmirror is not the = only one) fj> > fr> fj> > fr> So if I read this correctly, it means that the erroneous beha= viour is fj> > fr> the result of someone doing things "in the wrong order" (for = lack of fj> > fr> better terminology). fj> > fj> > =A0Well, does GPT really depend on the absolute last block? =A0Th= e header fj> > =A0has fields for both the first and the last LBAs and they do no= t have fj> > =A0to be matched with the physical capacity. =A0Creating a gmirro= r first, fj> > =A0and then creating a GPT on it does not work? =A0I do not think= it is fj> > =A0true, and I suspect a description on gmirror recommending fj> > =A0kern.geom.debugflags=3D17 in the handbook is the source of the= problem. fj> = fj> It's not the partitioning that's the issue. It's the order that GE= OM fj> providers and GPT partition tables are "tasted". fj> = fj> You can gmirror two disks, then GPT partition the gm0 device withou= t fj> any issues. As you noted, the first/last sectors are 1 less than t= he fj> physical disk (the size of the gmirror provider). fj> = fj> When you boot, though, the gptboot loader only sees the GPT table, = it fj> doesn't know that it's part of a gmirror setup. Thus it loads the fj> GPT, notices that the size of the GPT is 1 less sector than the siz= e fj> of the disk, can't find the secondary GPT table as the last sector = of fj> the disk is gmirror metadata, and complains about corrupted GPT. fj> = fj> Then the kernel loads, gmirror "tastes" the disk, finds the gmirror= fj> metadata, configures the gmirror provider, and now all the GPT stuf= f fj> matches again. And the system carries on correctly. fj> = fj> The issue is that we don't have a GEOM-aware loader. Or, at least,= fj> that the gpt*boot loaders read the GPT table(s) before configuring = the fj> GEOM providers. No, the issue is our gptloader assumes the backup header is always located at the (physical) last sector while this is not mandatory in the UEFI specification. GEOM-based logical volumes suffer from this assumption at boot time. It is not practical (and not necessary) to taste the volumes before loading a kernel. If the primary header is valid, using a lookup order of the hdr_lba_alt(AlternateLBA), the hdr_lba_end(LastUsableLBA), then drvsize() - 1 looks reasonable to me. The current code uses drvsize() - 1 first and then looks up the AlternateLBA only when drvsize() failed. -- Hiroki ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk89+/4ACgkQTyzT2CeTzy0L9ACgh49WyKoJBOT6c4WX2GycFFA9 NIUAoMDIEYLEkcL0yfQedMIiT/y/OgUX =MiHq -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)----