From owner-freebsd-current@FreeBSD.ORG Sun Dec 14 16:34:15 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19EC316A4CE; Sun, 14 Dec 2003 16:34:15 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD52743D36; Sun, 14 Dec 2003 16:34:12 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hBF0XIeF066055; Sun, 14 Dec 2003 16:33:22 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200312150033.hBF0XIeF066055@gw.catspoiler.org> Date: Sun, 14 Dec 2003 16:33:18 -0800 (PST) From: Don Lewis To: scottl@FreeBSD.org In-Reply-To: <3FDC887D.9060605@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: mckusick@mckusick.com cc: jroberson@chesapeake.net cc: alc@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: mb@imp.ch Subject: Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2003 00:34:15 -0000 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 >