From owner-freebsd-stable@FreeBSD.ORG Sun Dec 23 12:49:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53DE3B1F for ; Sun, 23 Dec 2012 12:49:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBE38FC0C for ; Sun, 23 Dec 2012 12:49:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA24209; Sun, 23 Dec 2012 14:49:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TmkzF-000Fal-OL; Sun, 23 Dec 2012 14:49:01 +0200 Message-ID: <50D6FDBD.6000401@FreeBSD.org> Date: Sun, 23 Dec 2012 14:49:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kimmo Paasiala Subject: Re: [HEADSUP] zfs root pool mounting References: <50B6598B.20200@FreeBSD.org> <50D6F901.7050206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 12:49:05 -0000 on 23/12/2012 14:34 Kimmo Paasiala said the following: > On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon wrote: >> >> I have MFCed the following change, so please double-check if you might be >> affected. Preferably before upgrading :-) >> >> on 28/11/2012 20:35 Andriy Gapon said the following: >>> >>> 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. > > Much appreciated! > > I have verified that my system is not affected. > > One question, do I have to rewrite the zfs gpt boot loader > (/boot/gptzfsboot) onto the freebsd-boot partition to make use of this > change? This change is kernel-level only. There is no interaction with boot blocks. -- Andriy Gapon