Date: Fri, 17 Feb 2012 16:04:30 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: fjwcash@gmail.com Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@FreeBSD.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer Message-ID: <20120217.160430.406937514120319292.hrs@allbsd.org> In-Reply-To: <CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.com> References: <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> <CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----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 <fjwcash@gmail.com> wrote in <CAOjFWZ5EhGFr_Vp0+TRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.co= m>: fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <hrs@freebsd.org> wrot= e: fj> > Jeremy Chadwick <freebsd@jdc.parodius.com> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120217.160430.406937514120319292.hrs>