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

[Kimmo Paasiala]

Altroot does the right thing (tm) and moves all mountpoints to be
relative to the altroot property, in other words the value of the
altroot property is prepended to every mountpoint. Both inherited and
explicitly set mountpoints behave exactly as you expect with altroot.

-Kimmo

On Thu, Nov 13, 2014 at 4:56 PM, Mark Felder <feld at freebsd.org> wrote:
>
>
> 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!
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"