ZFS: unsupported ZFS version 5000 (should be 28)

[Tim Gustafson]

I wanted to report back to the group about how I was able to get past
this problem.

A quick re-cap of what happened:

- A few weeks ago, we upgraded from 8.2 to 8.4 using the Subversion
repository at http://svn.freebsd.org/base/releng/8.4

- On Thursday last week, I fat-fingered a command that caused /usr to
be dismounted

- I rebooted into single-user mode, fixed /usr, and rebooted
successfully back into multi-user mode

- Just to make sure that nothing in /usr got clobbered, I did a "make
buildworld buildkernel installkernel installworld"

- Upon rebooting after the buildworld procedure, the system reported
that the zpool version (5000/28) was too new

So, somehow among all that, the zpool got upgraded to a new version.
I'm not sure how that's possible, given that at no time were we
running a beta version of any OS up to this point.

Reinstalling the bootcode (ala "gpart bootcode") from either the
compiled sources or a 9.2-BETA CD didn't help because /boot/loader did
not support the newer version.  I actually needed to upgrade the box
to 9.2-BETA in order to get a version of /boot/loader that could see
the zpool correctly.

So I'm running on 9.2-BETA now, and everything seems OK.  I'm not
thrilled that we're running a beta OS version on a production machine,
but I see no other way unless I rebuild the zpool, which I don't want
to do.  This is several terabytes of data and includes a lot of
snapshots that have to be preserved, and therefore rsync won't do, and
zfs send/receive would preserve the incorrect zpool version (if I
understand things correctly).

So, is there *any* way at all that someone accidentally committed
something to releng/8.4 that should have been committed to stable/8
instead?

-- 

Tim Gustafson
tjg at ucsc.edu
831-459-5354
Baskin Engineering, Room 313A