[HEADSUP] zfs root pool mounting

Andriy Gapon avg at FreeBSD.org
Sun Dec 23 12:49:05 UTC 2012


on 23/12/2012 14:34 Kimmo Paasiala said the following:
> On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon <avg at freebsd.org> 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 <disk>' 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


More information about the freebsd-stable mailing list