Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Dec 2003 08:57:49 -0700
From:      Scott Long <scottl@freebsd.org>
To:        Don Lewis <truckman@freebsd.org>
Cc:        alc@freebsd.org
Subject:   Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released
Message-ID:  <3FDC887D.9060605@freebsd.org>
In-Reply-To: <200312140716.hBE7G8eF064492@gw.catspoiler.org>
References:  <200312140716.hBE7G8eF064492@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FDC887D.9060605>