Please see my reply below:

Ion-Mihai Tetcu wrote:
On Sun, 08 Feb 2004 21:12:51 -0800
Rishi Chopra <[EMAIL PROTECTED]> wrote:


Here's a summary of my problem so far:

Server was idle (e.g. absolutely no processes running aside from
csh, ttyv0 and ps) when power was cut; server reports a problem mounting /usr partition upon reboot.


I have since tried the following:

(1) Booted into single-user mode and ran 'fsck' - the latest output to the terminal says:

****     FILE SYSTEM MARKED CLEAN     ****
    /dev/da0s1e
    Last Mounted on /usr
    Phase 1 - check blocks and sizes

After letting the system 'do its thing' for 5+ days, the output did not change.

(2) I tried an 'fsck -p' and got the following message:

/dev/da0s1a: 1128 files, 36058 used, 47059 free (261 frags, 58771 blocks, 0.1% fragmentations)


Do you get the prompt back ? Try fsck -p on / then on /var /tmp and last
/usr. At least you will know what partitions are ok. Better yet I
suggest you boot from the second aka Fixit CD and run fsck from there;
you fsck binary may be broken. Also boot verbose (I don't know if
safe-mode applies to SCSI, but if it does, try that also).

This is exactly the problem. The 'fsck' command does not return to a prompt.


The display has been stuck with that same output for countless hours now.


Do you have disk activity when fsck seems to be stuck ?


Questions I have:

(1) Have I suffered a total loss or is this still some way to revover my filesystem? After suffering a similar loss with a hardware raid-0 failure under win2k, I was assuming the FreeBSD setup would be more durable. I would hate to walk away thinking that a simple power loss could wipe out a freebsd server under nothing more than one terminal login.


Generally this doesn't happen. From my experience, it happens if either
there are problems with the disk access infrastructure (a la timeouts,
etc. on ata) or something bad elsewhere in the kernel.


(2) Why would a simple fsck of the filesystem not work in my case?


If you have the kernel with options DDB
options BREAK_TO_DEBUGGER


and no disk activity I suggest that you break to debugger hitting
Ctrl+Esc and try to gather some info from there. Note that in case fsck
is actually running this could further damage you fs, but since you
can't do anything else I would say to give it a try.

To summarize:

1. See if you have disk activity when fsck seems to be stuck.

2. Try fsck (-p) first on root, the on tmp, /var, /usr, /home.

3. Esp. if fsck / doesn't go ok try booting verbose with Fixit CD and
run fsck from there.

4. If 1 gets you the same results try putting the disk in another
machine where you have debugging options in the kernel, break to
debugger and gather info from there (esp. if you're running 5.x try
asking on current@ what exactly to look for in the debugger).




-- Rishi Chopra http://www.ocf.berkeley.edu/~rchopra _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to