On Fri, 30 May 1997 14:24:45 -0700 
 Nathan Gelbard <gelbard@engr.orst.edu> wrote:

 > /dev/rsd0a had a incorrect free block count, fixed, and fs made clean;
 > 	(this is strange. I did sync;sync;sync;reboot).

...it can happen, though, especially if you had problems with the
file system previously.

 > May 30 14:10:20 myname: arpresolve: can't allocate llinfo

...I'm _still_ curious what was causing this...

 > checking for core dump...
 > savecore: reboot after panic: ffs_valloc; dup_alloc
 > savecore: system went down at Fri May 30 00:22:16 (last night)
 > savecore: writting core to /var/crash/netbsd.1.core

...no biggie... that just means that when you encountered the
dup alloc (which also puzzles me, but given how it occurs, it
could have been something your old kernel did, and the new one
just tripped over), a crash dump was done, and now savecore
is saving it off for you to examine :-)

 > May 30 14:10:21 myname: arpresolve: can't allocate llinfo

...you're probably getting these during the savecore because savecore
uses syslog, and you're using a remote loghost, or something.  But
I honestly don't know why they're occurring...

 > May 30 14:10:21 myname: savecore: reboot after panic: ffs_valloc; dup_alloc
 > 
 > savecore: writting kernel to /var/crash/netbsd.1
 > 
 > and some more demons boot fine, and to the login prompt.
 > 
 > sigh

Don't sigh .. you made it to multi-user mode ... pretty good recovery,
given you were about to reinstall from scratch :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939