Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released

Don Lewis wrote:
> 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.
> 

Back in recent history, devfs was optional and it was deemed necessary
to populate /dev (on the destination media) with static entries in case
the user chose not to use it.  I think that it's fair to say that the
code in question was a hack to allow this to happen; unmounting devfs
exposed /dev so that it could be populated with device nodes from the
dist bits.  I think that it's just a lucky coincidence that  sysinstall
worked as long as it did.

It appears that we no longer put static device nodes into the dist bits,
so this is now moot, so I'm considering removing the hack from
sysinstall.  But as has been pointed out, fixing the underlying vfs
problem is needed too.

Scott