>Date: Thu, 06 Jul 1995 09:22:07 -0400
>From: "Gary D. Duzan" <gary@wheel.tiac.net>
>
>   I had left a /usr/src "make && make install" running last night,
>with a current kernel. This morning it had completed, and I proceeded
>to reboot to get the new daemons going. I did a "shutdown -r +1" while
>in X, exited X cleanly, did a quick MH inc to get the cron mail, and
>logged out before it shut down. Then I got:
>
>syncing disks... panic: vinvalbuf: dirty bufs
>Stopped at      _Debugger+0x4:    leave
>db>
>
>The stack trace showed: Debugger, panic, vinvalbuf, spec_close,
>ffs_umount, doumount, vfs_unmountall, vfs_shutdown, boot, reboot,
>syscall. I have most of the text of the trace if that would help,
>and I got a dump (accidentally, actually, since I'm not that familiar
>with the debugger) that I could look at if gdb would work with it.
>Any ideas?

Problems like this can occur when you overwrite some binaries.  I've
noticed it with /sbin/init and /sbin/mount_mfs.  I avoid it by doing
the following before before I install new binaries from /usr/src/sbin:

mv /sbin/init /sbin/init.old
mv /sbin/mount_mfs /sbin/mount_mfs.old

The second line isn't necessary if you don't use MFS, or remember to
unmount it before shutting down.

I don't know enough about the kernel's guts to know what the real
problem is.  My guess is that the running init process holds onto a
vnode for its executable image; when you install a new /sbin/init,
that vnode becomes the only thing keeping the old executable's blocks
from being reclaimed by the filesystem.  Apparently vfs_unmountall
doesn't deal with this situation well.

cgd sent in a pair of PRs recently that relate to this situation, and
the fact that fsck -p doesn't clean it up properly when you reboot.
-- 
Mike Long <mike.long@analog.com>           http://www.shore.net/~mikel
VLSI Design Engineer         finger mikel@shore.net for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA                assert(*this!=opinionof(Analog));