HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released

[Don Lewis]

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
>