From owner-freebsd-fs@FreeBSD.ORG Fri Feb 3 13:46:37 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C33C106566C for ; Fri, 3 Feb 2012 13:46:37 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 056018FC13 for ; Fri, 3 Feb 2012 13:46:36 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0McRqW-1SAqM744YK-00I6ne; Fri, 03 Feb 2012 14:46:36 +0100 Message-ID: <4F2BE53A.2030301@brockmann-consult.de> Date: Fri, 03 Feb 2012 14:46:34 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120203021649.GA87521@server.vk2pj.dyndns.org> In-Reply-To: <20120203021649.GA87521@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:2hl+oHtqEQW+8E8MgYOe+6o8Asr9cP2qSsKwuhyRHHG PiwMQH0yCXcNg+N1nbCA6kdROeoqq0bYfYySSESec5iRRZwUg3 Ak7Oo+QDHtYdRPMgRJbQeSRnnBRIyL5hSrvxNXykmlZwwS1mOh q07X4ovyBUB//sdie0gqV6PGDf8dNZA0Dpp3NXE7PCzPOaoer6 MbFAqPDC0EIyXsVJSLNJ4uvOnJm6xoamiaQJM3evVq323dGPfC XOKSp95LtOOomfKJw/OsyIHY6f8WjZAhGwK6Estaez504mFEI5 iP4AZxmmDP7jOtFnEKkL0p3BotqZjZ0o7aVknDmu9IMHwn/Tsp 20BMMtjPMUe42Xv8y1+Pg7mpfBLcdyUM4IWl8NAUR Subject: Re: ZFS boot problems revisited X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:46:37 -0000 The causes of some zfs boot failures are unknown. I don't know why it does it. I updated 2 nearly identical systems to 8-STABLE from 8.2-RELEASE and (if I remember correctly) got the same error as you on one but not the other. I have only tried 2 way mirrors so far, so I might not know much about this specific issue, but what comes to mind is what I would call the 'standard zfs boot fix', which I first found here: http://freebsd.1045724.n5.nabble.com/Difficulties-to-use-ZFS-root-ROOT-MOUNT-ERROR-td4771828.html It basically goes like this: Boot off of something with zfs support (eg. a DVD). Then run these commands (assuming here your root is named "zroot"). zpool import -o altroot=/z -o cachefile=/tmp/zpool.cache zroot zfs set mountpoint=/ zroot cp /tmp/zpool.cache /z/boot/zfs/zpool.cache shutdown -r now The "mountpoint=/" part is required. And then optionally, you would set it back to "legacy" before the reboot if that is the way you do things. I do not prefer "mountpoint=legacy", which most people seem to have and seems to be in all the howtos, because then if something goes wrong, altroot will work without unmounting /usr, /var, etc. first and remounting it all after / is mounted. (which affects things like chroot, but not simply editing conf if it is in the same dataset). And do not export the pool, or forget/skip the cache file part, or you get the same error that you started with. And if you messed up your config somehow (maybe with mergemaster), you should edit it before the reboot... better double check. /etc/rc.conf: =========== zfs_enable="YES" /boot/loader.conf =========== zfs_load="YES" vfs.root.mountfrom="zfs:zroot" #depending on your install and hardware, maybe you want to load mps (8.2-RELEASE). With 8-STABLE you probably don't need this. I wouldn't just assume the new GENERIC kernel of one version loads the same drivers as your old GENERIC kernel. mps_load="YES" On 02/03/2012 03:16 AM, Peter Jeremy wrote: > I recently ran into the dreaded "all blocks unavailable" error whilst > upgrading to a recent 8-stable with a 3-way mirrored ZFS root. > Installing the latest gptzfsboot helped a bit but still reported > errors and the boot failed. I was under the impression that the > latest boot code had resolved all the problems but it seems there are > still some cases it can't cope with. Comparing the code I built with > the latest head shows no relevant differences (disabling SSE3 & FP and > changing a constant used for RAIDZ parity calculations). > > Are there any known cases that the boot code still doesn't handle? > > The failures led me to investigate zfsboottest & zfsboottest.sh. > Unfortunately, these tools still have some problems: > 1) zfsboottest is still built as native dynamic executable. I'm not > sure if being dynamic presents a problem (I would hope it didn't) > but it should be an i386 executable on amd64. The attached patch > changes it to be a static i386 executable. > 2) vfs.root.mountfrom is documented (in sys/kern/vfs_mountroot.c in > 9.x and later or sys/kern/vfs_mount.c in 8.x and earlier) to take a > space-separated list of :[]. zfsboottest.sh expects > it to be a bare zpool name. The attached patch adds the "zfs:" > prefix but still limits it to a single item. > 3) The "you may not be able to boot" message will never appear because > it's testing the result of the preceeding "rm -f", rather than the > diff (as wanted). The attached patch fixes this. > > I'm still not confident that the flags used to build zfsboottest are > equivalent to those used to build gptzfsboot but will leave that for > later investigation. > > The attached patches are relative to 8-stable CVS but there are no > differences to head. > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de --------------------------------------------