Date: Sun, 19 Sep 2010 13:24:39 -0500 From: Dan Mack <mack@macktronics.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: jhell <jhell@DataIX.net>, stable@freebsd.org, Martin Matuska <mm@freebsd.org> Subject: Re: MFC of ZFSv15 Message-ID: <CDA4617C-7155-4B8D-B373-E3C7146D39AB@macktronics.com> In-Reply-To: <4C964B49.6080102@infracaninophile.co.uk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CDA4617C-7155-4B8D-B373-E3C7146D39AB>