Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Dec 2012 14:36:03 +0100
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Daniel Braniss <danny@cs.huji.ac.il>
Cc:        FreeBSD current <freebsd-current@FreeBSD.org>, FreeBSD Stable <freebsd-stable@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>
Subject:   Re: [HEADSUP] zfs root pool mounting
Message-ID:  <20121201133603.GF1399@garage.freebsd.pl>
In-Reply-To: <E1TeKRw-00088u-Bd@kabab.cs.huji.ac.il>
References:  <50B6598B.20200@FreeBSD.org> <E1TeKRw-00088u-Bd@kabab.cs.huji.ac.il>

next in thread | previous in thread | raw e-mail | index | archive | help

--juZjCTNxrMaZdGZC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 30, 2012 at 08:51:48AM +0200, Daniel Braniss wrote:
> >=20
> > Recently some changes were made to how a root pool is opened for root f=
ilesystem
> > mounting.  Previously the root pool had to be present in zpool.cache.  =
Now it is
> > automatically discovered by probing available GEOM providers.
> > The new scheme is believed to be more flexible.  For example, it allows=
 to prepare
> > a new root pool at one system, then export it and then boot from it on =
a new
> > system without doing any extra/magical steps with zpool.cache.  It coul=
d also be
> > convenient after zpool split and in some other situations.
> >=20
> > The change was introduced via multiple commits, the latest relevant rev=
ision in
> > head is r243502.  The changes are partially MFC-ed, the remaining parts=
 are
> > scheduled to be MFC-ed soon.
> >=20
> > I have received a report that the change caused a problem with booting =
on at least
> > one system.  The problem has been identified as an issue in local envir=
onment and
> > has been fixed.  Please read on to see if you might be affected when yo=
u upgrade,
> > so that you can avoid any unnecessary surprises.
> >=20
> > You might be affected if you ever had a pool named the same as your cur=
rent root
> > pool.  And you still have any disks connected to your system that belon=
ged to that
> > pool (in whole or via some partitions).  And that pool was never proper=
ly
> > destroyed using zpool destroy, but merely abandoned (its disks
> > re-purposed/re-partitioned/reused).
> >=20
> > If all of the above are true, then I recommend that you run 'zdb -l <di=
sk>' for
> > all suspect disks and their partitions (or just all disks and partition=
s).  If
> > this command reports at least one valid ZFS label for a disk or a parti=
tion that
> > do not belong to any current pool, then the problem may affect you.
> >=20
> > The best course is to remove the offending labels.
> >=20
> > If you are affected, please follow up to this email.
>=20
> GREATE!!!!
> in a diskless environment, /boot is read only, and the zpool.cache issue
> has been bothering me ever since, there was no way (and I tried) to re ro=
ute it.

I believe zpool.cache is not required only for root pool anymore and
that you still need it if you want non-root pools to be automatically
configured after reboot. Am I right, Andriy?

Zpool.cache basically tells ZFS which pools should be automatically
imported and file systems mounted. You can have disks in your system
with ZFS pools that should not be auto-imported and zpool.cache is the
way to tell the difference.

--=20
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl

--juZjCTNxrMaZdGZC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlC6B8IACgkQForvXbEpPzQmVQCgwL1RvyYB6HC+2/kcdWN3xLwa
oHgAn2qWqOntsDsfJwjqkiBZtBLDGpVf
=aPgG
-----END PGP SIGNATURE-----

--juZjCTNxrMaZdGZC--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121201133603.GF1399>