Don Lewis wrote: > Following up to myself ... > > It looks like we're trying to recycle this vnode because of the > following sysinstall code, in distExtractTarball(): > > if (is_base && RunningAsInit && !Fake) { > unmounted_dev = 1; > unmount("/dev", MNT_FORCE); > } else > unmounted_dev = 0; > > I'm guessing that the purpose of this code is to unmount devfs from /dev > so that when the base distribution is unpacked it can populate /dev from > the tarball. This seems wrong, because it looks like the root file > system is mounted on /mnt, and devfs is also mounted on /mnt/dev ... > > What happens if we forceably umount /dev while /dev/whatever holds a > mounted file system? It looks like this is handled by vgonechrl(). It > looks to me like vclean() is going to do some scary stuff to this vnode. > As Jeff pointed out, vfs_subr.c rev 1.461 might be the immediate problem here. However, I can't believe that umounting devfs while it is in use can possibly be the right thing to do. Does devfs have to be mounted in the /mnt? Is it a chroot issue? > BTW, I think the root vnode is the root of the md file system, not the > root of the file system being populated by sysinstall. I don't know why > there would be anything to sync at this point, though. > > I suspect that removing the above sysinstall code will fix the immediate > problem, but there is still much I don't understand. Removing this code will likely result in sysinstall reporting errors to the user about not being able to unpack the files into /dev. Or even worse, it might succeed and temporarily replace the valid entries with invalid ones. ScottReceived on Sun Dec 14 2003 - 06:59:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC