On Sun, Dec 23, 2012 at 2:49 PM, Andriy Gapon <[email protected]> wrote: > on 23/12/2012 14:34 Kimmo Paasiala said the following: >> On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon <[email protected]> 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
I can happily report that booting from the ZFS pool works on my 9-STABLE system without the zpool.cache file. Thanks, merry christmas and happy new year! -Kimmo _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
