bsdinstall(8) umount target should be able to unmount zfs filesystems

[kczekirda]

Summary

It's not a perfect, but it's enough for 99% use cases.

From Bugzilla:

[e-mail] 2015-11-12 15:41:13 UTC
Hi,

When calling the script target with the ZFSBOOT_DISKS variable set, the zfsboot target will be run. This logic should also be used for the umount target, choosing 'zfs umount -a' to be run.

[nwhitehorn]

The use case when installing multiuser is not that uncommon and is something that needs to continue working. One of two things needs to happen here before being committed:
(a) it needs to use only those ZFS filesystems previously mounted
(b) the zfsboot script should use the ZFS support in partedit, which already works with umount

[allanjude]

usr.sbin/bsdinstall/scripts/umount

43 ↗

(On Diff #11620)

in multiuser mode, this command will fail, because you can't umount / while your CWD is / or a subdirectory of it.

When bsdinstall sees an error, it will prompt the user to start the entire install over again.

Wouldn't 'zfs unmount $BSDINSTALL_CHROOT' work here? ($BSDINSTALL_CHROOT = /mnt)

It would unmount only the file systems mounted under the chroot and their descendants.

[kczekirda]

In D4689#98951, @nwhitehorn wrote:

The use case when installing multiuser is not that uncommon and is something that needs to continue working. One of two things needs to happen here before being committed:
(a) it needs to use only those ZFS filesystems previously mounted
(b) the zfsboot script should use the ZFS support in partedit, which already works with umount

I can do (a), but I'm not able to work on (b).

[allanjude]

scripts/umount

49

If this were to return an error, wouldn't it cause bsdinstall to prompt the user to start the installation over again?

Also, if there is somehow a mountpoint that will not unmount because it is in use (say, the shell on console #4 was in that directory), this will loop forever.