New BSD Installer

Freddie Cash fjwcash at
Fri Feb 17 05:46:06 UTC 2012

On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <hrs at> wrote:
> Jeremy Chadwick <freebsd at> wrote
>  in <20120217030806.GA62601 at icarus.home.lan>:
> fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:
> fr> > Sorry, I may be misunderstanding your point.  GEOM classes don't
> fr> > lie, they accurately represent the space.  The space provided by a
> fr> > gmirror is one block less than the actual space occupied, to allow
> fr> > for the metadata block at the end.  The problem is that GPT puts
> fr> > backup partition tables at the end of the physical (not logical)
> fr> > device. Create a GEOM device on that drive, and the GEOM metadata
> fr> > overwrites the backup GPT partition table.  Well, the last block of
> fr> > it, anyway.
> fr> >
> fr> > But create the GEOM device inside a GPT partition that spans the
> fr> > drive, and things are fine.  The GPT backup tables are safely
> fr> > outside the GEOM metadata, which is safely outside of the data.
> fr>
> fr> I wasn't aware you could do that.  I was only aware that it was the
> fr> other way around.  That (my) misconception seems to also be relayed
> fr> by others such as Miroslav who said:
> fr>
> fr> >>GPT doesn't play nice with GEOM classes which store their metadata
> fr> >>on last sector.  For example, you can't use gmirror of a whole drives
> fr> >>and use GPT on top of this mirror. (and gmirror is not the only one)
> fr>
> fr> So if I read this correctly, it means that the erroneous behaviour is
> fr> the result of someone doing things "in the wrong order" (for lack of
> fr> better terminology).
>  Well, does GPT really depend on the absolute last block?  The header
>  has fields for both the first and the last LBAs and they do not have
>  to be matched with the physical capacity.  Creating a gmirror first,
>  and then creating a GPT on it does not work?  I do not think it is
>  true, and I suspect a description on gmirror recommending
>  kern.geom.debugflags=17 in the handbook is the source of the problem.

It's not the partitioning that's the issue.  It's the order that GEOM
providers and GPT partition tables are "tasted".

You can gmirror two disks, then GPT partition the gm0 device without
any issues.  As you noted, the first/last sectors are 1 less than the
physical disk (the size of the gmirror provider).

When you boot, though, the gptboot loader only sees the GPT table, it
doesn't know that it's part of a gmirror setup.  Thus it loads the
GPT, notices that the size of the GPT is 1 less sector than the size
of the disk, can't find the secondary GPT table as the last sector of
the disk is gmirror metadata, and complains about corrupted GPT.

Then the kernel loads, gmirror "tastes" the disk, finds the gmirror
metadata, configures the gmirror provider, and now all the GPT stuff
matches again.  And the system carries on correctly.

The issue is that we don't have a GEOM-aware loader.  Or, at least,
that the gpt*boot loaders read the GPT table(s) before configuring the
GEOM providers.

If we had a gloader that understood all the different GEOM classes,
this would be a non-issue.  At least, from my limited understanding of

Freddie Cash
fjwcash at

More information about the freebsd-stable mailing list