Date: Thu, 5 Oct 1995 06:57:07 -0400 From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ic.net!rdm@dg-rtp.dg.com, freebsd-hackers@freefall.FreeBSD.org Subject: Re: system crash - help! Message-ID: <199510051057.GAA21537@lakes>
next in thread | raw e-mail | index | archive | help
Rob Misiak (<dg-rtp!ic.net!rdm@dg-rtp>) writes:
> Terry Lambert ("Re: system crash - help!") wrote:
> >
> > > Ok, in case anyone is interested, I fixed the problem. What happened is
> > > fsck (I think that's what did this) marked some files - including /etc/ttys
> > > (causing the login problem) and /etc/hosts - character devices. I luckily
> > > had the 2.0.5-release CD lying around, so I replaced all of the messed up
> > > files
> >
> > What do you mean "marked"... you mean "moved to lost+found"? I hope?
> >
> >
>
> Unfortunately, no. The files were in the same places that they normally were,
> except (according to ls -l) they were character devices. It happened to many
> random files all over the / partition. Fortunately, I kept backups and I was
> able to restore the files.
>
> Rob
>
I have just had a recent confirmation of this phenomena (much to
my chagrin.)
On a FreeBSD 2.0.5 system, running the distributed GENERIC kernel;
on a 386dx-33 with 8meg, NE2000 ether, HGA screen, AHA1542B w/
an old micropolis 635meg driver.
I walked in the office and the machine had mysteriously rebooted,
although the machine next to it hadn't.
The fsck during the reboot had failed, dropping me into the `sh'.
When running the fsck myself, I discovered that just about every
file in /dev had been scribbled over (like the inode for the
directory had been mucked-around.)
This wasn't so bad, since I could recover MAKEDEV and reconstruct
the /dev directory.
Interestingly enough, several files become immutable in this
process, making it a pain to get rid of the old /dev directory
when everything was back up-and-running.
I just wanted to echo Rod's observations.
Also, I wanted to make sure there wasn't a problem with the drive
itself. I dropped into the Adaptect BIOS routines and asked for
a SCSI verify. No problems on the driver were located/remapped.
Finally, the machine has been running since a week after the 2.0.5
release, without seeing this problem. It saw this problem about
once a month with the 2.0 release.
Of course, this could all be associated with an aging drive dropping
bits every-now-and-then.
- Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510051057.GAA21537>