Re: [HEADSUP] zfs root pool mounting

On Thu, Dec 6, 2012 at 4:55 PM, Garrett Cooper <yanegomi_at_gmail.com> 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 <yanegomi_at_gmail.com>
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 <yanegomi_at_gmail.com>
commit 7a1c6d1a406d78810db56e5a8915d9ec945f546c
Author: avg <avg_at_FreeBSD.org>
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 <avg_at_FreeBSD.org>
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 <andy.lavr_at_gmail.com>
    Tested by:  Andrei Lavreniyuk <andy.lavr_at_gmail.com>
    MFC after:  6 days
commit 574c22111b5590734e10a02b2b7d27a290b38148
Author: avg <avg_at_FreeBSD.org>
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