From owner-freebsd-fs@FreeBSD.ORG Thu Apr 4 16:44:13 2013 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B31CAC61; Thu, 4 Apr 2013 16:44:13 +0000 (UTC) (envelope-from jayb@braeburn.org) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4975FFD2; Thu, 4 Apr 2013 16:44:12 +0000 (UTC) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6ddad515.0.202767.00-392.566794.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 04 Apr 2013 16:44:13 +0000 (UTC) X-MXL-Hash: 515daddd4b11a3c9-f2ce2627afef554792a7987dd53e0ace2cc5ccd8 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34Gi6Wq007728; Thu, 4 Apr 2013 12:44:06 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34Ghvrv007570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Apr 2013 12:44:01 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 4 Apr 2013 17:43:46 +0100 Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r34GhkFY029362; Thu, 4 Apr 2013 12:43:46 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r34GhfPT029184; Thu, 4 Apr 2013 12:43:42 -0400 Received: by oz.mt.att.com (Postfix, from userid 1000) id 088FB6807DD; Thu, 4 Apr 2013 12:43:40 -0400 (EDT) X-Mailer: emacs 23.3.1 (via feedmail 8 I); VM 8.2.0b under 23.3.1 (i686-pc-linux-gnu) Message-ID: <20829.44475.910011.453770@oz.mt.att.com> Date: Thu, 4 Apr 2013 12:43:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jay Borkenhagen To: Andriy Gapon Subject: Re: mounting failed with error 2 In-Reply-To: <515DA43D.7070805@FreeBSD.org> References: <20825.59038.104304.161698@oz.mt.att.com> <5159F0C9.9000302@FreeBSD.org> <20825.62329.379765.344231@oz.mt.att.com> <515DA43D.7070805@FreeBSD.org> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public Cc: fs@FreeBSD.org, Niclas Zeising X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jay Borkenhagen List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 16:44:13 -0000 Hi Andriy, Thanks for your response. Andriy Gapon writes: > > My first suggestion would be to try an image with recent stable/9 > if you can find or produce it. A large part of my interest here is in helping Niclas perfect his GPT/ZFS installation instructions, so I'll not pursue the stable/9 approach at this time. (I have two GPT/ZFS systems running 9.1-RELEASE based on earlier instructions from Niclas, so if I absolutely need another such system now I do have a way to get there.) > Failing that, you can set vfs.zfs.debug=1 at loader prompt before > booting. That could shed some light on what is going wrong. The > most likely possibility is that /boot/zfs/zpool.cache in the > boot/root filesystem of the boot/root pool does not have an entry > for the root pool. I just tried 'set vfs.zfs.debug=1' then 'boot' at the loader prompt, and it seems I wound up at the exact same place with no further debug diagnostics. I believe the important part of that error output is this: =============== Trying to mount root from zfs:zroot/ROOT []... Mounting from zfs:zroot/ROOT failed with error 2. Loader variables: vfs.root.mountfrom=zfs:zroot/ROOT =============== If there's something else you'd like me to specify to the boot loader, please let me know and I will give it a try today. > Further, I believe that instructions on the Niclas' page won't > result in a bootable pool with 9.0 or 9.1. With stable/9 they > should work. The problem is that zpool.cache is not populated at > all. You can try to specify cachefile property to zpool create and > then copy zpool.cache to boot/zfs/ on the newly created pool. I would be willing to attempt a re-install using Niclas' instructions plus something to populate the zpool.cache. Can you (or Niclas) suggest what command(s) to add to the process at which stage? Thank you. Jay B.