Bug 204506 - bsdinstall(8) umount target should be able to unmount zfs filesystems
Summary: bsdinstall(8) umount target should be able to unmount zfs filesystems
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.2-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-sysinstall (Nobody)
URL:
Keywords: install
Depends on:
Blocks:
 
Reported: 2015-11-12 15:41 UTC by fre.fbsdpr
Modified: 2023-06-01 16:42 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fre.fbsdpr 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.
Comment 1 Kamil Czekirda freebsd_committer freebsd_triage 2015-12-20 21:46:05 UTC
Hi,

We can add 'zfs umount -a', but it's not a perfect, because I sometimes use bsdinstall in my workstation which use zfs on root partition, but it's uncommon usecase.

I've reported this to Devin some time ago, could you tell something? Maybe Allan?
Comment 2 fre.fbsdpr 2015-12-21 17:52:31 UTC
Then, how about iterating over filesystems under $ZFSBOOT_POOL_NAME?
Comment 3 Kamil Czekirda freebsd_committer freebsd_triage 2015-12-22 22:00:12 UTC
Revision with 'zfs umount -a' created:
https://reviews.freebsd.org/D4689
Comment 4 Allan Jude freebsd_committer freebsd_triage 2015-12-23 20:27:53 UTC
I think you want to use:


zfs unmount $BSDINSTALL_CHROOT

To only unmount anything mounted under /mnt

Also, you should first check if any ZFS was actually used, as running a zfs command for the first time loads the ZFS kernel module, and you don't want to do that if the user just did a ufs only install
Comment 5 Kamil Czekirda freebsd_committer freebsd_triage 2015-12-29 22:22:50 UTC
Revision updated, any ideas for optimalization?
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:41:25 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 7 Jonathan Reynolds 2023-06-01 16:42:42 UTC
This still happens on 14-CURRENT.


The issue:

/usr/libexec/bsdinstall/umount fails if fstab is emtpty, which happens with ZFS + BIOS boot.
Two dialog box displaying /tmp/bsdinstall_log will be shown in succession (user  input required).
The installation itself does succeed.

Simple fix (main 9a49a3792940497ddf4657f6e5be56d8ef881edc):

--- usr.sbin/bsdinstall/scripts/umount.orig     2023-06-01 18:17:39.482944000 +0200
+++ usr.sbin/bsdinstall/scripts/umount  2023-06-01 18:18:20.275423000 +0200
@@ -46,6 +46,6 @@
 }' > $TMP_FSTAB
 
 umount $BSDINSTALL_CHROOT/dev 2>/dev/null
-if [ -n "$TMP_FSTAB" ]; then
+if [ -n "$TMP_FSTAB" -a -s "$TMP_FSTAB" ]; then
        umount -F $TMP_FSTAB -a 2>/dev/null
 fi


Note:

The described issue does not happen if $debugFile is prepended with a plus `+' sign.

if $debugFile is prepended with a `+' in /etc/rc.local and the `+' sign is removed in /etc/installerconfig, the script will show one dialog box displaying /tmp/bsdinstall_log and an other showing success/reboot.