From owner-freebsd-stable@FreeBSD.ORG Sun Sep 19 18:24:42 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CADCB106566B; Sun, 19 Sep 2010 18:24:42 +0000 (UTC) (envelope-from mack@macktronics.com) Received: from coco.macktronics.com (coco.macktronics.com [209.181.253.65]) by mx1.freebsd.org (Postfix) with ESMTP id 86E9E8FC13; Sun, 19 Sep 2010 18:24:42 +0000 (UTC) Received: from [172.22.30.42] (dulse.macktronics.com [209.181.253.69]) by coco.macktronics.com (Postfix) with ESMTPA id D51994AC41; Sun, 19 Sep 2010 13:24:39 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dan Mack In-Reply-To: <4C964B49.6080102@infracaninophile.co.uk> Date: Sun, 19 Sep 2010 13:24:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201009152007.17320.Pascal.Stumpf@cubes.de> <201009151830.o8FIUWEZ021844@lava.sentex.ca> <4C911AB0.6090901@delphij.net> <4C91AEBF.50502@FreeBSD.org> <201009161355.o8GDtroR028629@lava.sentex.ca> <4C923557.40004@DataIX.net> <201009161543.o8GFhJnh029157@lava.sentex.ca> <4C923ECD.8020809@FreeBSD.org> <38552F13-7E0C-4B18-B274-C88D7CE1F04F@macktronics.com> <4C964B49.6080102@infracaninophile.co.uk> To: Matthew Seaman X-Mailer: Apple Mail (2.1081) Cc: jhell , stable@freebsd.org, Martin Matuska Subject: Re: MFC of ZFSv15 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Sep 2010 18:24:42 -0000 Thanks for the confirmation. This worked fine and I did notice that = "zpool upgrade zroot" was nice enough to emit the reminder: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 which is slightly different than the recipe given in /usr/src/UPDATING: "gpart bootcode -p /boot/gptzfsboot -i 1 ad0" Since the recipe for my root/zfs system included pmbr and gptzfsboot, I = used the example emitted from the zpool command instead of the one from = UPDATING. e.g. pool: zroot state: ONLINE status: The pool is formatted using an older on-disk format. The pool = can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 errors: No known data errors (zfs) ~ # zpool upgrade zroot This system is currently running ZFS pool version 15. Successfully upgraded 'zroot' from version 14 to version 15 If you boot from pool 'zroot', don't forget to update boot code. Assuming you use GPT partitioning and da0 is your boot disk the following command will do it: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4 ad4 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad5 ad5 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad6 ad6 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad7 ad7 has bootcode (zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad8 ad8 has bootcode (zfs) ~/zfs # reboot Dan On Sep 19, 2010, at 12:41 PM, Matthew Seaman wrote: > On 19/09/2010 17:36:01, Dan Mack wrote: >> But I should be able to boot my ZFSv14 root pool using the ZFSv15 >> build of FreeBSD, correct? But the problem scenario would be when >> I've upgraded my root pool to v15 and I attempt to boot it with v14 >> boot loader. At least that is what I think ... >=20 > Yes. The bootloader is not prescient, so bootloader compiled against > v14 can't cope with a zpool using v15. It's only the on-disk format > that counts in this: zfs software will operate perfectly well with = older > on-disk data formats. >=20 >> I guess what I'm getting at is ... you should be able to buildworld, >> installkernel, reboot, installworld, reboot without worry. But >> after your run 'zpool upgrade', you will need to re-write the >> bootcode using gpart on each of your root pool ZFS disks. >=20 > If you want to be completely paranoid, you could update the bootcode = on > your boot drive (or one out of a mirror pair, if that's what you're > using) at the point of running installkernel and way before you run > 'zpool upgrade'. In theory, should this go horribly wrong and you end > up with an unbootable system, you can recover by booting the 8.0 = install > media into FIXIT mode and reinstalling the bootblocks from there (or > booting from the other disk in your mirror set). Once you've got a > system you know will reboot with the new bootblocks, then go ahead and > with installworld and updating the zpool version. >=20 >> Am I understanding this correctly ? >=20 > Yep. That's quite right. Running 'zpool upgrade -a' is one of those > operations you can't easily reverse, so designing an upgrade plan = where > you can stop and back-out at any point is quite tricky. Fortunately, > the risk of things going wrong at the point of running zpool upgrade = is > really very small, so for most purposes, just ploughing ahead and > accepting the really very small risk is going to be acceptable. >=20 > Cheers, >=20 > Matthew >=20 > --=20 > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > JID: matthew@infracaninophile.co.uk Kent, CT11 9PW >=20 Dan -- Dan Mack mack@macktronics.com