vermaden/beadm

Activating BE with extra datasets in the root

Closed this issue · 4 comments

bdrewery commented

Current BE: zroot/ROOT/freebsd83
Activating BE: zroot/ROOT/freebsd90

# zfs get -r -H -o name,value -s local mountpoint zroot/ROOT/freebsd83
zroot/ROOT/freebsd83    legacy
zroot/ROOT/freebsd83/tmp        /tmp
zroot/ROOT/freebsd83/usr        /usr
zroot/ROOT/freebsd83/var        /var

As you see, I created /tmp, /usr and /var datasets in my BE pool. I'm now finding that due to the legacy mountpoint on the root, I'll need to manually move these when activating.

I haven't quite figured out the best way to handle this yet as changing the mountpoint immediately mounts it.

# touch /tmp/8
# zfs set mountpoint=/tmp zroot/ROOT/freebsd90/tmp
# ls -al /tmp/8
ls: /tmp/8: No such file or directory

I might have to just move these to my /etc/fstab, but I'll likely need to add all of their children there as well.

I believe that moving the root to mountpoint=/ would yield the same problem as it would remount the new BE ontop of the current BE before rebooting.

vermaden commented

Ok, I will look into that problem tomorrow.

"Bryan Drewery" reply@reply.github.com pisze:

Current BE: zroot/ROOT/freebsd83
Activating BE: zroot/ROOT/freebsd90

# zfs list -H -o name -t filesystem -r zroot/ROOT/freebsd83 | while read I; do zfs get -H -o name,value -s local mountpoint $I; done
zroot/ROOT/freebsd83    legacy
zroot/ROOT/freebsd83/tmp        /tmp
zroot/ROOT/freebsd83/usr        /usr
zroot/ROOT/freebsd83/var        /var

As you see, I created /tmp, /usr and /var datasets in my BE pool. I'm now finding that due to the legacy mountpoint on the root, I'll need to manually move these when activating.

I haven't quite figured out the best way to handle this yet as changing the mountpoint immediately mounts it.

# touch /tmp/8
# zfs set mountpoint=/tmp zroot/ROOT/freebsd90/tmp
# ls -al /tmp/8
ls: /tmp/8: No such file or directory

I might have to just move these to my /etc/fstab, but I'll likely need to add all of their children there as well.

I believe that moving the root to mountpoint=/ would yield the same problem as it would remount the new BE ontop of the current BE before rebooting.

Reply to this email directly or view it on GitHub:
#5

...

bdrewery commented

I played with this more and I think the only way to make it work is via manual management in /etc/fstab.

I tried canmount=noauto with mountpoint=/ on both environments, they overlapped on reboot and still resulted in both being mounted. Plus I had to grab a livecd to fix that mess. Nor did this provide a good way to activate the environment.

It looks like "manageBE" handled this via /etc/fstab as well:

vermaden commented

I could not wait until tomorrow as You specified /etc/fstab as the only possible solution ;)

I fixed it without using the /etc/fstab, the ZFS canmount=noauto property is used instead,
in short, every dataset that is not activated has canmount=noauto and all datasets that are
part of active BE have canmount=on property.

I tested it with multiple reboots and works ok for me but You may also want to check it.

I increased the tag to 0.2 because of these changes, I also made several other 'light' fixes.

Regards,
vermaden

"Bryan Drewery" reply@reply.github.com pisze:

I played with this more and I think the only way to make it work is via manual management in /etc/fstab.

I tried canmount=noauto with mountpoint=/ on both environments, they overlapped on reboot and still resulted in both being mounted. Plus I had to grab a livecd to fix that mess. Nor did this provide a good way to activate the environment.

It looks like "manageBE" handled this via /etc/fstab as well:

Reply to this email directly or view it on GitHub:
#5 (comment)

...

bdrewery commented

Thanks, I'll check it out.

Yeah this is a semi-production server, so I only had about 30 minutes to
try things out.

Bryan

On 4/29/2012 7:53 PM, vermaden wrote:

I could not wait until tomorrow as You specified /etc/fstab as the only possible solution ;)

I fixed it without using the /etc/fstab, the ZFS canmount=noauto property is used instead,
in short, every dataset that is not activated has canmount=noauto and all datasets that are
part of active BE have canmount=on property.

I tested it with multiple reboots and works ok for me but You may also want to check it.

I increased the tag to 0.2 because of these changes, I also made several other 'light' fixes.

Regards,
vermaden

"Bryan Drewery" reply@reply.github.com pisze:

I played with this more and I think the only way to make it work is via manual management in /etc/fstab.

I tried canmount=noauto with mountpoint=/ on both environments, they overlapped on reboot and still resulted in both being mounted. Plus I had to grab a livecd to fix that mess. Nor did this provide a good way to activate the environment.

It looks like "manageBE" handled this via /etc/fstab as well:

Reply to this email directly or view it on GitHub:
#5 (comment)