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>