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

[Mark Felder]

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
question:


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!