From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:25:36 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFE6433A; Mon, 10 Dec 2012 21:25:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDEE8FC08; Mon, 10 Dec 2012 21:25:36 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so3913693oag.13 for ; Mon, 10 Dec 2012 13:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=puQJ8paCKH0/UopSYfLLJtY4A5w7MFlVHgRBEl8sMoo=; b=Jd6g8r4Ep3wYxoJTIpaiW8oZdPPWSIFY/jfeA8+b6ZzlzfduwvaeqvchjSs0nztlqf p4ydNcITrFXB88HIcounV5Fawe1/sPN+G7RprRmwN8q9LcP1kAsgR6VBXN8zB2zMGYs4 43xd+xKA2L5JepoxdFwB3ob5mDfjCS9NIl3eRvS7zXv1j9edNs96G/HtyYlmFXemXA+4 c/Q8eVXWIPi5u2QX3uNJAwCvGc9hKQVwaRvG/rjvjztSOj0NZSDNDwHmLIJGSfjpuafL qo4zFRpNXg4HQhXKl/QjETkm2iQpENbpy28iuQs9eUOLhz3EFUS0hKMROPy2o9eN5ydZ O1lw== MIME-Version: 1.0 Received: by 10.60.25.227 with SMTP id f3mr8319694oeg.17.1355174730246; Mon, 10 Dec 2012 13:25:30 -0800 (PST) Received: by 10.76.143.33 with HTTP; Mon, 10 Dec 2012 13:25:30 -0800 (PST) In-Reply-To: References: <50B6598B.20200@FreeBSD.org> Date: Mon, 10 Dec 2012 13:25:30 -0800 Message-ID: Subject: Re: [HEADSUP] zfs root pool mounting From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:25:37 -0000 On Thu, Dec 6, 2012 at 4:55 PM, Garrett Cooper wrote: ... > (Removing bogus list) > > If I try and let it import the pool at boot it claims the pool is in a > FAULTED state when I point mountroot to /dev/cd0 (one of gjb's > snapshot CDs -- thanks!), run service hostid onestart, etc. If I > export and try to reimport the pool it claims it's not available (!). > However, if I boot, run service hostid onestart, _then_ import the > pool, then the pool is imported properly. > > While I was mucking around with the pool trying to get the system to > boot I set the cachefile attribute to /boot/zfs/zpool.cache before > upgrading. In order to diagnose whether or not that was at fault, I > set that back to none and I'm still running into the same issue. > > I'm going to try backing out your commit and rebuild my kernel in > order to determine whether or not that's at fault. > > One other thing: both my machines have more than one ZFS-only zpool, > and it might be probing the pools in the wrong order; one of the pools > has bootfs set, the other doesn't, and the behavior is sort of > resembling it not being set properly. I reverted the following commits with no change. Thanks, -Garrett commit 969475c599c9cd5095012f47c25faef914b63a45 Author: Garrett Cooper Date: Wed Dec 5 23:48:06 2012 -0800 Don't define the TESTSDIR if it's empty The problem is that items like lib/crypt/tests with empty TESTSDIRS will blow up the build if make installworld is run with the modifications made to bsd.subdir.mk . Signed-off-by: Garrett Cooper commit 7a1c6d1a406d78810db56e5a8915d9ec945f546c Author: avg Date: Sat Nov 24 13:23:15 2012 +0000 zfs roopool: add support for multi-vdev configurations Tested by: madpilot MFC after: 10 days commit 7ad1a2bc4c09f0635d5f7216a8e96703cd70f371 Author: avg Date: Sat Nov 24 13:16:49 2012 +0000 spa_import_rootpool: initialize ub_version before calling spa_config_parse ... because the latter makes some decision based on the version. This is especially important for raidz vdevs. This is similar to what spa_load does. This is not an issue for upstream because they do not seem to support using raidz as a root pool. Reported by: Andrei Lavreniyuk Tested by: Andrei Lavreniyuk MFC after: 6 days commit 574c22111b5590734e10a02b2b7d27a290b38148 Author: avg Date: Sat Nov 24 13:14:53 2012 +0000 spa_import_rootpool: do not call spa_history_log_version The call is a NOP, because pool version in spa_ubsync.ub_version is not initialized and thus appears to be zero. If the version is properly set then the call leads to a NULL pointer dereference because the spa object is still under-constructed. The same change was independently made in the upstream as a part of a larger change (4445fffbbb1ea25fd0e9ea68b9380dd7a6709025). MFC after: 6 days