ZFS Is there a way to turn on canmount property for root volumes?

As the FreeBSD team's decision to turn canmount property off for the root filesystem, argumenting that the access to the root filesystem respective the boot environments should be limited to the beadm program, I would like to reverse that decision for my own computers.

Reasons:

So, how can I turn on the canmount property after installing the system?
 
See zfs(8).

It's merely a filesystem setting so # zfs inherit canmount zroot/root/DEFAULT should be enough to sort that out. I'm not sure from mind but it is possible that this setting was also applied to zroot/DEFAULT, so if that's the case you'll need to turn that on as well.

Check using zfs get -rt filesystem canmount zroot, then set the inherit option accordingly.

You could even consider using: # zfs inherit -r canmount zroot, this would reset everything to default.
 
So you would like it to mount over your root filesystem when you import it from a rescue device?

You can check for differences with zfs diff and the appropriate snapshots, or look into beadm mount to your non-active be and use other tools. Or use a tool that looks at differences for a file through time/snapshots.
 
So you would like it to mount over your root filesystem when you import it from a rescue device?
Thank you, but I think you misunderstood me.

I have (had) two use cases now:
1.
I have newly installed 11.1Release on my desktop to a new pool and wanted to transfer some configuration data in /boot and /etc onto the new system from the old pool containing the old RC2 system.
However, as I could not mount the root (ofc to an alternate mountpoint) I was forced to boot the old system to copy the data to an usb stick. So this is solved for now.
2.
I want to take out the disk from my laptop (which does no longer boot, possibly caused by some beadm hiccup), copy the stuff onto my desktop, repair it, and then copy it back onto a bigger laptop disk to put back into my laptop.
With UFS this would be easy as snap.
So pointing me to beadm is no "solution".
Putting beadm between the user and his files imho sucks, mutating a simple task into a horrible, tedious and error-prone challenge. (If it is actually at all possible to handle with beadm the scenario I described, fixing the environment of a system disk of another system...)

You can check for differences with zfs diff and the appropriate snapshots, or look into beadm mount to your non-active be and use other tools. Or use a tool that looks at differences for a file through time/snapshots.
I wonder whether it justifies to force such tedious, frustrating, time-consuming chores upon the user by insisting on a such un-unix-ish behavior of the root filesystem respective boot environments being unmountable?
 
You can mount other boot environments without beadm if you like:


$ zfs list -ro canmount,mountpoint,mounted,name system/ROOT
CANMOUNT MOUNTPOINT MOUNTED NAME
on none no system/ROOT
noauto / no system/ROOT/11.1-p1
noauto / yes system/ROOT/11.1-p1v2
$ mkdir /tmp/oldbe && sudo mount -t zfs system/ROOT/11.1-p1 /tmp/oldbe
$ mount | grep oldbe
system/ROOT/11.1-p1 on /tmp/oldbe (zfs, local, noatime, nfsv4acls)


This is a pretty unix-ish way to do things. :)
 
Thank you, but I think you misunderstood me.

I have (had) two use cases now:
1.
I have newly installed 11.1Release on my desktop to a new pool and wanted to transfer some configuration data in /boot and /etc onto the new system from the old pool containing the old RC2 system.
However, as I could not mount the root (ofc to an alternate mountpoint) I was forced to boot the old system to copy the data to an usb stick. So this is solved for now.

And for this one, I'm not quite sure where the difficulty lied. If there was a filesystem set to canmount=on with mountpoint=/, what you would want to do (to avoid mounting over your other system) would be to import it with an -o altroot=/tmp/oldpool or similar (as part of the zpool import command.) If it is set to noauto, you can use the unix-traditional mount command like I demonstrated above after importing the pool. (I would still use the altroot option if I'm going to have two bootable zpools imported at the same time to avoid any other unintentional mounts.)

That said, boot environments are incredibly powerful once you get the hang of them. Throwing out the capability just because it is new and different would be a real step back. See my post over here: https://forums.freebsd.org/threads/63263/#post-365745 for how I use them for clean (revertable) system upgrades. I'm certainly not the only one doing this, I just know where this post is. :)

I'll (shameless plug of free software) also point you to my zfs_versions script for looking at changes of a file (or files) over time; this may also help for some of your use cases.
 
If there was a filesystem set to canmount=on with mountpoint=/, what you would want to do (to avoid mounting over your other system) would be to import it with an -o altroot=/tmp/oldpool or similar (as part of the zpool import command.)
Much easier: # zpool import -R /mnt zroot.

With a normally set up ZFS system (so: default as initially designed by Sun) this would make the pool accessible under /mnt.
 
Back
Top