fsck lasting several hours (and then forever) after crash
Hello lists (sorry for crossposting), This is kind of serious for me. Here is what happened: I portupgraded the native version of mozilla to 1.1 and fired it up. It crashed and took X with it. Keyboard and mouse where dead, I had to press the reset button. So the system rebooted and reached automatic fsck. Checked /, /var, /tmp and then, when going to /usr it stopped. And stood stopped. I've had it running 17 hours now, nothing. Booting into single user I do /sbin/fsck, which works nicely until here: Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=1702863 (4 should be 0) CORRECT [yn] No matter what I enter (tried both y and n) it goes on and then lasts forever. No harddisk-noise, no nothing. I really don't know why this is happening. fsck does not bail out or say anything, it just does nothing after above message. No CTRL-C, no CTRL-ALT-DEL, no nothing helps. Since I needed the system I edited /etc/rc and commented out the exit 1 part where it refuses going to multiuser when any of the file systems is marked 'dirty', then added the -f flag to mount. That way I got it back running, but how do I repair my /usr partition now without fsck failing to do its job? Has anybody a pointer for me, an idea or anything else I could try to repair /usr? I know that what I did is quite a dirty workaround. Thanks in advance, anything is greatly appreciated. regards -- Andreas ant Ntaflos | A cynic is a man who knows the price of [EMAIL PROTECTED] | everything, and the value of nothing. Vienna, AUSTRIA | Oscar Wilde To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: fsck lasting several hours (and then forever) after crash
On Thu, Oct 24, 2002 at 11:40:43AM -0500, Matthew Reimer wrote: Andreas Ntaflos wrote: Is there anything else I could do to help solving this problem? regards We had a problem like this when an ATA disk went bad--the kernel would seem to hang while trying to read the bad part of the disk. Try booting into single-user mode (boot -s) and then try reading all the disk's blocks. If it hangs doing this, then you know it's not fsck's fault: dd if=/dev/ad0s1c of=/dev/null bs=64k Now that is a good idear! Thanks. I dropped to single user mode and did dd if=/dev/ad4s1h of=/dev/null bs=64k. It appears that fsck is not the problem but my disk is going bad. It turned out that our disk just needed a low-level format. Apparently, writing zeroes to (some) disks effects a low-level format, so I zeroed the entire bad disk (dd if=/dev/zero of=/dev/ad0s1c) and then I could read all the disks's blocks without problems. Of course zeroing the disk will destroy all your data. If you knew which blocks were bad you could try zeroing just those blocks; if they weren't holding real important information (like a superblock) then you might be able to save your files. I am not sure how to interpret the error message I get: ad4s1h: hard error reading fsbn 61857135 of 28752640-28752767 (ad4s1 bn 61857135; cn 3850 tn 109 sn 18) status=69 error=40 Does that indicate which blocks are bad? If so, how could I try zeroing out just those blocks? And if not, is there a way to tell which are the real bad blocks? Sorry for sounding newbie'ish, but I've never dealt with something like that before, at least not with a bad disk. thanks and regards -- Andreas ant Ntaflos | A cynic is a man who knows the price of [EMAIL PROTECTED] | everything, and the value of nothing. Vienna, AUSTRIA | Oscar Wilde To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
