From owner-freebsd-current@FreeBSD.ORG Fri Nov 30 07:06:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 514C9FDE; Fri, 30 Nov 2012 07:06:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EC7068FC0C; Fri, 30 Nov 2012 07:06:39 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TeKRw-00088u-Bd; Fri, 30 Nov 2012 08:51:48 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andriy Gapon Subject: Re: [HEADSUP] zfs root pool mounting In-reply-to: <50B6598B.20200@FreeBSD.org> References: <50B6598B.20200@FreeBSD.org> Comments: In-reply-to Andriy Gapon message dated "Wed, 28 Nov 2012 20:35:55 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Nov 2012 08:51:48 +0200 From: Daniel Braniss Message-ID: Cc: FreeBSD current , FreeBSD Stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 07:06:40 -0000 > > Recently some changes were made to how a root pool is opened for root filesystem > 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 could also be > convenient after zpool split and in some other situations. > > The change was introduced via multiple commits, the latest relevant revision in > head is r243502. The changes are partially MFC-ed, the remaining parts are > scheduled to be MFC-ed soon. > > 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 environment and > has been fixed. Please read on to see if you might be affected when you upgrade, > so that you can avoid any unnecessary surprises. > > You might be affected if you ever had a pool named the same as your current root > pool. And you still have any disks connected to your system that belonged to that > pool (in whole or via some partitions). And that pool was never properly > destroyed using zpool destroy, but merely abandoned (its disks > re-purposed/re-partitioned/reused). > > If all of the above are true, then I recommend that you run 'zdb -l ' for > all suspect disks and their partitions (or just all disks and partitions). If > this command reports at least one valid ZFS label for a disk or a partition that > do not belong to any current pool, then the problem may affect you. > > The best course is to remove the offending labels. > > If you are affected, please follow up to this email. 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 route it. thanks, danny