Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news2.near.net!news.delphi.com!BIX.com!arog From: arog@BIX.com (arog on BIX) Newsgroups: comp.os.386bsd.misc Subject: Re: Crash! Bang... Oops Date: 19 Aug 94 05:35:14 GMT Organization: Delphi Internet Services Corporation Lines: 121 Message-ID: <arog.777274514@BIX.com> References: <3311uk$t08@csugrad.cs.vt.edu> NNTP-Posting-Host: bix.com jaitken@csugrad.cs.vt.edu (Jeff Aitken) writes: >I'm not sure what happened here, but I'll summarize as best I can: >I moved recently (back to school). Everything worked fine before I >packed up. >Once I got to school, I added 8MB of RAM (to bring my total to 16MB) >Then I booted FreeBSD, and everything seemed to work ok >Then I booted DOS, and things started to go haywire. First, himem >started complaining about memory being bad. Well, OK, lets run a memory >exerciser on it. I assume FreeBSD has one, so I attempt to boot it. I >get something like this >Automatic reboot in progress >/dev/rwd1a >/dev/rwd1e >pid 30: rm: exit on signal 11 >seg fault - core dumped >pid 4: sh: exit on signal 11 >Then I reboot, and there's a rm.core and sh.core file in / (I booted >into single user, BTW, because /dev/rwd1a was modified). I try to rm >rm.core. System crashes, tries to sync disks (and fails), then dumps a >memory image. It then tries to reboot, but now cannot find /dev/wd1a. >I cannot fsck it manually because fsck is not on the bootable floppy! >(Or if it is I cannot find it) When I try to mount either /dev/wd1a or >/dev/wd1e, I get "/dev/wd1x on /mnt: Bogus super block" >Hmmn, looks like the crash was a good one. I yanked the extra 8MB of >memory, and get the same results. Does anyone have any idea what I can >do to remedy this, other than re-install everything? I really don't >want to reconfigure everything. I forget, does the installation muck >with /usr? Or does it just create a usable / ?? >Thanks! >Jeff >-- >Jeff Aitken >jaitken@vt.edu Jeff, I'll assume that you are at FreeBSD-1.1R or -1.1.5.1, the level that I've been working with. fsck lives in sbin and should be run on the character (or 'raw') device. Boot to single user with the -s at the boot prompt. [ah, like I'm in tutorial mode, so I'll be reciting the stuff that everyone knows, just as I did earlier tonight on BIX in one of these on Xenix filesystems.] At this point, the root filesystem should be read-only. This may well explain some of the problems in rming the *core files. Run /sbin/fsck /dev/rwd1a and at /dev/rw1e . If the problem is one of something mucked up in the structure of the fs, then this has a reasonable chance of fixing it. Also, take a look at how things are entered into the machine's cmos ram in terms of the hard.disks. I'll suggest strongly that you go back to documentation to confirm that this is set to the correct values. As I noted some while back and recieved conformation of in mail, ST-506 and IDE drives that are not configured in the cmos of the machine can be mounted by FreeBSD. I regard this a very desirable feature and hope that, if its caused by a 'bug', that it will be retained in the future releases. If you cannot get things to work with wd1 listed in cmos, set that drive to 'none' and try again. Its something of a 'long shot' but it also serves to reduce the chance that its something strange that direction. If it persists, when this is tried, open the system and 'rock' the socketed chips in their sockets and seat them all down... memory, keyboard, anything that is in a socket. After all, a problem at this level would affect both 'dos' and BSD. In that the problem first manifested itself as you booted to 'dos', I'd suggest booting from a dos floppy and running chkdsk at the dos drives and looking at the partition info with the dos fdisk. You might also get a copy of pfdisk (which runs from 'dos' and acts as an equivalent of BSD's disklabel) and see if it reports the info as it should be. I'd probably elect to write the labels again from it as yet.another.place that an invisable glitch might be shot. Last, make a second copy of your BSD filesystem disk, as you did for the original install. From single user or multi-user, this can be mounted and should mount as read/write. Assuming that the problem fs doesnot contain /usr/bin and the other files needed to run the editors [and I'll make an editorial comment here that 'standard' BSD or not, there really needs to be a line.editor in /bin for dealing with problems at this level so that the need to use cat for file creation is reduced]... ah, editors are there, then you can edit the .profile on the mounted filesystem disk, rm the install and *.gz in its root, and move the things that are needed for a panic.disk in. If it is the /usr filesystem thats munged, then you'll need to use cat - > .profile to create a new one... and I'd suggest mving the original one to a new name and making lots of notes as to path and such for the new one. .... I hope that helps and helps enough others to justify the use of bandwidth. ........................................................ Alan Ogden, Moderator of 'nos' on BIX (and lots of other things too) arog@BIX.com