From owner-freebsd-fs@FreeBSD.ORG Mon Aug 5 19:20:16 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94CE0375 for ; Mon, 5 Aug 2013 19:20:16 +0000 (UTC) (envelope-from tjg@ucsc.edu) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57D1921CC for ; Mon, 5 Aug 2013 19:20:16 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id fb19so6360955obc.38 for ; Mon, 05 Aug 2013 12:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VlANDonnp4TC0phee9YMFaaJqlESOJu+gNMr/xmvNVI=; b=Ciku8M9tRpJI3K/hkQr6uTzH/XCv27PEF9pGEHYEOGQLupMoMHqIkpiPAR9S01Q1az hn+sdPez2ILJVECZtosqpIDqk3YcHOKeSO6HLQzmqWeDRodWP718pDMJ4TacSPbIHV6U nfEvD35MdG6xc30aD6Fwbya7iOtm6lYknPufo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=VlANDonnp4TC0phee9YMFaaJqlESOJu+gNMr/xmvNVI=; b=kjPF5NbKfZ2RsLSvDLsUUEDmu+JylK0cwZ3uwDkzJiqO5ZRjbhkE7P/UoHifFT8vFi FEUQ2x13p8b5NF0AOHewfx/9vIBxBoa0TY0tg+FL4ZGS+AyMNjNBQcYcogNp56uLmT4l bw6P0POdPpsPbFTX6FuL1mPyfGaekmP3de6jfgqPGrcaLaVg/NuTtTbkl3IbiN+aNoIR zNzqJEBhT7G6ejm9C2wsDZUu3DyKIcEBH+4wn/yAm2XhjVlYFtMLE490EmDsvVZQTQDM cl8KXlZtAvBQXdTr8BEozJ+YoB0Iy7yoFsqoxepaWMYWlASKY2HZqyq2mN2VvJ8VvyNS awyg== MIME-Version: 1.0 X-Received: by 10.42.63.207 with SMTP id d15mr1741298ici.21.1375730415490; Mon, 05 Aug 2013 12:20:15 -0700 (PDT) Received: by 10.42.233.143 with HTTP; Mon, 5 Aug 2013 12:20:15 -0700 (PDT) In-Reply-To: References: <51FBC806.3070500@egr.msu.edu> Date: Mon, 5 Aug 2013 12:20:15 -0700 Message-ID: Subject: Re: ZFS: unsupported ZFS version 5000 (should be 28) From: Tim Gustafson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn2uxU6fXRxSlVV4JYG+UGBuKCpy0v+D5SLBJhXctNoBDDt8typpFRgfKbSXFO5VMwqszRr X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:20:16 -0000 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@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A