轉載自：http://ixdba.blog.51cto.com/2895551/566345
root文件系統破壞，導致系統無法啟動
Linux下普遍采用的是ext3文件系統，ext3是一個具有日志記錄功能的日志文件系統，可以進行簡單的容錯和恢復，但是在一個高負荷讀寫的ext3文件系統下，如果突然發生掉電，就很有可能發生文件系統內部結構不一致，導致文件系統破壞。
Linux在啟動時，會自動去分析和檢查系統分區，如果發現文件系統有簡單的錯誤，會自動修復，如果文件系統破壞比較嚴重，系統無法完成修復時，系統就會自動進入單用戶模式下或者出現一個交互界面，提示用戶介入手動修復，現象類似下面所示：
checking root filesystem
/dev/sdb5 contains a file system with errors, check forced
/dev/sdb5:
Unattached inode 68338812
/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
FAILED
/contains a file system with errors check forced
an eror occurred during the file system check
****dropping you to a shell;the system will reboot
****when you leave the shell
Press enter for maintenance
(or type Control-D to continue):
give root password for maintenance
從這個錯誤可以看出，系統根分區文件系統出現了問題，系統在啟動時無法自動修復，然后進入到了一個交互界面，提示用戶進行系統修復。
這個問題發生的機率很高，引起這個問題的主要原因就是系統突然掉電，引起文件系統結構不一致。一般情況下解決此問題的辦法是采用fsck命令，進行強制修復。
根據上面的錯誤提示，當按下“Control-D”組合鍵后系統自動重啟，當輸入root密碼后進入系統修復模式，在修復模式下，可以執行fsck命令，具體操作過程如下：
[root@localhost /]#umount /dev/sdb5
[root@localhost /]#fsck .ext3 -y /dev/sdb5
e2fsck 1.39 (29-May-2006)
/ contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 6833812 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 6833812
Connect to /lost+found<y>? yes
Inode 6833812 ref count is 2, should be 1. Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences: -(519--529) -9273
Fix<y>? yes
…… ……
/: ***** FILE SYSTEM WAS MODIFIED *****
/: 19/128520 files (15.8% non-contiguous), 46034/514048 blocks
上面就是fsck修復受損文件系統的過程，需要注意的是，在執行fsck的時候，一定要先卸載要修復的分區，然后再執行修復操作，切記！
修復前需要將重要數據備份。