Re: ZFS: amd64, devd, root file system.

> This is not the first report that it doesn't work as it should.

FWIW, I had some trouble converting my root to ZFS too.

I had load_zfs="YES" and the appropriate vfs.root.mountfrom option in
loader.conf, but the kernel did not know of any available zfs:* devices
that were candidates for root mounts (according to the output of "?").

It may just have been a matter of zpool.cache not being up to date with
the volume I was trying to use for root; I do not remember whether the
version on /boot was recent enough for that.

In general it feels a bit unclear what will happen with zpool.cache when
having root on ZFS. Is it guaranteed that only userland tools modify or
read this file?

In my case the devices in the ZFS pool were glabel:ed, so the issue of
drives moving about and such should not have affected me (plus at the
point where I had this problem I had not yet started shuffling drives).
glabel has successfully loaded and tasted all relevant devices prior to
ZFS loading, judging by the kernel output (glabel label detection prior
to the ZFS pool version output).

In this case I ended up just putting /usr on zfs, leaving / on UFS.
Doing so was no problem; the only snag was that putting /usr in
/etc/fstab would cause some rc script to try to run fsck_zfs. I ended up
not even putting in in /etc/fstab, and having /usr be a symlink to the
ZFS managed mountpoint (in this case, /zpromusr).

> One was
> that /boot/defaults/loader.conf wasn't fresh enough, and there were no:
> 
> zpool_cache_load="YES"
> zpool_cache_type="/boot/zfs/zpool.cache"
> zpool_cache_name="/boot/zfs/zpool.cache"
> 
> lines at the end. Can you verify you have them?

This is confirmed to not be the issue in my case.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey_at_scode.org
E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org