First thanks to the respondents:
Ken Lalonde <email@example.com>
firstname.lastname@example.org (Marke Clinger)
kensmith@cs.Buffalo.EDU (Ken Smith)
Dan Davison <email@example.com>
Ross A Macintyre <raz%cs.heriot-watt.ac.uk@NSFNET-RELAY.AC.UK>
firstname.lastname@example.org ( Robert M. Enger)
Evidently, the related crash scrod the swap file for the client. The
symptom was that it would boot in vmunix, probe the buss, tell me
where root, swap and dump were and then hang before checking the file
1) cd /export/swap (as root of course). (halt the client first)
2) 'rm clientname' to get rid of the old swap file for client
3) 'mkfile size clientname' to create a swap file of appropriate 'size'
for the client
4) 'exportfs -a' to reinform the export system where the new file is
5) rebooted the client and everything was fine!
I had this as a service call into sun, but the net response beat them
to it (sun took ~20 hours to get back to me). As a plus for sun, this
is the fix they recommended to me when they finally did call.
Several folks recommended the above fix.
One person suggested just letting fsck fix it. Note however, that the
problem I had (couldn't read block) is one fsck can't deal with. It is
a show stopper on a reboot.
One suggestion was latent memory corruption and that a power cycling
worked for them in these instances.
Several mentioned fried init or vmunix. (I tried a different vmunix I
had laying around. No joy. Didn't get around to bringing in an init
from tape. The swap was the easiest next thing to try.)
Someone told of a problem they had with lance chips that got fried
from a nearby lightning strikes. The chip was fine w/ small packets,
but barfed on big ones.
I have the full replies file if anyone wants more details. Just drop
me a line. THANKS AGAIN for all the FAST responses!!!
--bill email@example.com [184.108.40.206]
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:03:55 CDT