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>