Yuichiro NAITO <[email protected]> wrote:
> bsd.upgrade fails and shows following messages with a single partition disk.
>
> ```
> Force checking of clean non-root filesystems? [no] no
> umount: /mnt: Device busy
> Can't umount sd0a!
OK, we figured out what is going on. During upgrade, the async random
seed feeding code has vnodes open on the bsd.rd ramdisk root filesystem
(mounted as /), and also on the real root (mounted as /mnt, to collect
fstab information). The umount honestly can fail to flush all the vnodes,
I suspect because the random seed generation processes have vnodes on both
filesystems. The EBUSY is true.
The install script can umount /mnt earlier, in fact immediately after it
has collected fstab information, and this is before the cgi fetching and
random feeding.
Yuichiro built a reliable & quick test case, and with this diff (based
upon an earlier proposal from him), doesn't see the problem anymore.
Index: distrib/miniroot/install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1184
diff -u -p -u -r1.1184 install.sub
--- distrib/miniroot/install.sub 2 Nov 2021 16:54:01 -0000 1.1184
+++ distrib/miniroot/install.sub 2 Dec 2021 05:19:45 -0000
@@ -3258,17 +3258,19 @@ do_upgrade() {
# Configure the network.
enable_network
- # Fetch list of mirror servers and installer choices from previous runs.
- start_cgiinfo
-
# Create a skeletal /etc/fstab which is usable for the upgrade process.
munge_fstab
+ # Do not need to look in /mnt anymore
+ umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
+
+ # Fetch list of mirror servers and installer choices from previous runs.
+ start_cgiinfo
+
# fsck -p non-root filesystems in /etc/fstab.
check_fs
# Mount filesystems in /etc/fstab.
- umount /mnt || { echo "Can't umount $ROOTDEV!"; exit; }
mount_fs
rm -f /mnt/bsd.upgrade /mnt/auto_upgrade.conf
