On 14 Dec, Scott Long wrote: > 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? I think it might have something to do with chroot. In that case we might need devfs mounted in /mnt/dev in order to mount the installation media. In that case we are really unmounting /mnt/dev and remounting it again. In that case, we may not be getting hurt by the file system mounted on /mnt, but possibly /mnt/usr, since all the file systems except /mnt are mounted using the devices found in /mnt/dev. A quick test would be to not partition the disk and install into one large file system. I don't know why sysinstall wants to use the /mnt/dev devices for the destination file systems anyway. It could just use the /dev devices before it chroots. It would probably still need /mnt/dev for the installation media, and we may still need to fix vfs_subr.c or whatever. >> 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. > > Scott >Received on Sun Dec 14 2003 - 15:34:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC