unsupported feature: com.delfix and can't find pool by guid after old STABLE10.0-to-RELENG10.0 upgrade

Mark Felder feld at FreeBSD.org
Thu Nov 13 14:56:16 UTC 2014

On Tue, Nov 11, 2014, at 14:38, Zeus Panchenko wrote:
> Mark Felder <feld at FreeBSD.org> wrote:
> > All you should need to do is boot FreeBSD 10.1-RC4 and apply the newer
> > bootcode and put the newer kernel on the system.
> I hoped I could use my old kernel :(
> thanks, I'll try
> > 
> > If this is a zfs-on-root install you may have problems with importing
> > the zpool and getting access to your data. I would advice you import the
> > zpool with the -N option
> > 
> >          -N      Import the pool without mounting any file systems.
> emm ... why a not altroot ?
> zpool(8)
>      altroot
>          Alternate root directory. If set, this directory is prepended to
>          any
>          mount points within the pool. This can be used when examining an
>          unknown pool where the mount points cannot be trusted, or in an
>          alternate boot environment, where the typical paths are not
>          valid.

Altroot looks viable, but I haven't tested how it behaves. This my

tank  mountpoint=/
tank/var  mountpoint=/var (inherited)
tank/tmp mountpoint=/tmp  (directly set)

I expect altroot will correctly move the root (tank) and /var 
(tank/var) to the altroot, but how does it handle other zfs filesystems
that have a very specific mountpoint set like /tmp in this situation?
Does it gracefully mount it into the mountroot, or does that only work
for the root and filesystems that inherit their mountpoint?

As I have not tested it, I do not trust it.  I'll certainly test this in
the near future, though. Thanks for the tip!

More information about the freebsd-fs mailing list