New BSD Installer

[Hiroki Sato]

Freddie Cash <fjwcash at gmail.com> wrote
  in <CAOjFWZ5EhGFr_Vp0+TRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ at mail.gmail.com>:

fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <hrs at freebsd.org> wrote:
fj> > Jeremy Chadwick <freebsd at jdc.parodius.com> wrote
fj> >  in <20120217030806.GA62601 at 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.  GEOM classes don't
fj> > fr> > lie, they accurately represent the space.  The space provided by a
fj> > fr> > gmirror is one block less than the actual space occupied, to allow
fj> > fr> > for the metadata block at the end.  The problem is that GPT puts
fj> > fr> > backup partition tables at the end of the physical (not logical)
fj> > fr> > device. Create a GEOM device on that drive, and the GEOM metadata
fj> > fr> > overwrites the backup GPT partition table.  Well, the last block of
fj> > fr> > it, anyway.
fj> > fr> >
fj> > fr> > But create the GEOM device inside a GPT partition that spans the
fj> > fr> > drive, and things are fine.  The GPT backup tables are safely
fj> > fr> > outside the GEOM metadata, which is safely outside of the data.
fj> > fr>
fj> > fr> I wasn't aware you could do that.  I was only aware that it was the
fj> > fr> other way around.  That (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 metadata
fj> > fr> >>on last sector.  For 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 behaviour is
fj> > fr> the result of someone doing things "in the wrong order" (for lack of
fj> > fr> better terminology).
fj> >
fj> >  Well, does GPT really depend on the absolute last block?  The header
fj> >  has fields for both the first and the last LBAs and they do not have
fj> >  to be matched with the physical capacity.  Creating a gmirror first,
fj> >  and then creating a GPT on it does not work?  I do not think it is
fj> >  true, and I suspect a description on gmirror recommending
fj> >  kern.geom.debugflags=17 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 GEOM
fj> providers and GPT partition tables are "tasted".
fj> 
fj> You can gmirror two disks, then GPT partition the gm0 device without
fj> any issues.  As you noted, the first/last sectors are 1 less than the
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 size
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 stuff
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120217/d627bc17/attachment.pgp