Linux 無法啟動常見的幾種原因及解決辦法

導致 Linux 無法啟動的原因有很多，下面良許小編就將常見的幾種原因及解決辦法進行詳述，希望對大家有所幫助。

1. 文件系統配置不當，如 /etc/inittab文件、/etc/fstab 文件等配置錯誤或丟失，導致系統出現故障，以至於無法啟動。
2. 非法關機，導致 root 文件系統破壞，也就是 Linux 根分區破壞，系統無法正常啟動。
3. 硬件故障，如主板、電源、硬盤等出現問題，導致 Linux 無法啟動。 系統引導程序出現問題，如 grub 丟失或者損壞，導致系統無法引導啟動。

從這些常見的故障中可以看出，導致系統無法啟動的原因主要有兩個，即硬件和操作系統。對於硬件出現的問題，只需通過更換硬件設備，即可解決，而對於操作系統出現的問題，雖然出現的問題可能千差萬別，不過在多數情況下都可以用相對簡單統一的方法來恢復系統。

下面我們就針對上面提出的幾個問題，給出一些常用的、普遍的解決問題的方法。

1、/etc/fstab文件丟失，導致系統無法啟動

/etc/fstab 文件存儲了系統中文件系統的相關信息。如果正確的配置了該文件，那么在 Linux 啟動時，系統會讀取此文件，自動掛載 Linux 的各個分區；如果此文件配置錯誤或者丟失，就會導致系統無法啟動，具體的故障現象會在檢測 mount partition 時出現 starting system/logger，此后系統啟動就停止了。

針對這個問題，第一思路就是想辦法恢復 /etc/fstab 這個文件的信息。如果恢復了此文件，系統就能自動掛載每個分區，正常啟動。可能很多讀者首先想到的是將系統切換到單用戶模式下，然后手動掛載分區，最后結合系統信息，重建 /etc/fstab 文件。

但是，這種方法是行不通的，因為 fatab 文件丟失導致 Linux 無法掛載任何一個分區，即使 Linux 還能切換到單用戶下，此時的系統也只是一個 read-only 的文件系統，無法向磁盤寫入任何信息。

注意，系統正常時，要將 /etc/fstab 文件中的內容做成文檔，當然一些重要的系統中的配置信息也要記錄在文檔之中，這樣在系統出問題時就可以方便地知道系統正常時的正確配置了。

2、root文件系統破壞，導致系統無法啟動

Linux 下普遍采用的是 ext 3 文件系統。ext 3 是一個具有日志記錄功能的日志文件系統，可以進行簡單的容錯和恢復，但是在一個高負荷讀寫的 ext 3 文件系統下，如果突然發生掉電，就很有可能發生文件系統內部結構不一致，導致文件系統破壞。

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 .ext 3 -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 ? yes
Unattached inode 6833812
Connect to /lost+found ? yes
Inode 6833812 ref count is 2, should be 1. Fix ? yes
Pass 5: Checking group summary information
Block bitmap differences: -(519--529) -9273
Fix ? yes

3、開機以及文件系統故障排查

如果 Linux 不能正常開機，排除故障的操作步驟有以下3點：

1. 檢查是不是開機管理程序的問題，在 RHEL4 或者以上的版本（也包括 Oracle Linux）中是使用 GRUB 作為默認的開機管理程序。

2. 如果開機管理程序沒有問題，就檢查是否載入了正確的內核（Kernel）。

3. 如果開機時出現 panic 的錯誤，則是根目錄沒有掛載成功。這時要檢查 /sbin/init 及 /etc/inittab 兩個系統文件中的配置有沒有錯誤，並且還要檢查根目錄有沒有損壞。

   上述的步驟雖然看起來十分簡單，但是理想和現實往往具有差別，真正做起來並不是那么簡單。不過 Linux 是一個十分穩健的操作系統，在平時的工作狀態中很少出事。偶爾出事，也是在情理之中的，此時就體現出了作為系統管理員的重要之處。

   文件系統的故障通常是由於系統當機（如突然斷電）或者非正常關機造成的文件損壞而引起的。當一個文件系統出現故障時，進行文件系統修復的步驟如下：

   • 使用 umount 命令卸載有問題的文件系統。
   • 使用 fsck -y 命令測試和修復文件系統。
   • 當這個文件系統修復成功之后，使用 mount 命令重新掛載該文件系統。

   下面我們就通過實例進行演示以上修復文件系統故障的操作，在圖 1 中，df 命令列出目前系統上所掛載的文件系統。

   【例 1】查看掛載命令。命令如下：

   [root@liangxu ~ ]# df -h

   【例 2】umount/oradata 命令的使用。命令如下：

   [root@liangxu ~ ]# umount /oradata

umount/oradata 命令執行之后系統不會給出任何信息，所以我們要使用 df 命令重新列出目前系統上所有掛起的文件系統，以確認 /oradata 文件系統已經卸載。

當確認 /oradata 文件系統已經成功的卸載之后，就可以使用例 3 中的帶有 -y 選項的 fsck 命令檢測和修復 /dev/md0 這個文件系統。

【例 3】fsck -y /dev/md0 修復系統。命令如下：

[root@liangxu ~ ]# fsck -y /dev/md0

當輸入此命令時，就可以確認 /dev/md0 文件系統已經修復成功。接下來我們就可以使用例 4 中的 mount 命令將 /dev/md0 這個文件重新掛載到 /oradata 目錄之下。

【例 4】完成修復工作操作。命令如下：

[root@liangxu ~ ]# mount /dev/md0 /oradata

通過以上命令就可以完成對文件系統的修復工作了。

​ 以上就是良許教程網為各位朋友分享的對於Linux 無法啟動常見的幾種原因及解決辦法。

本文由博客一文多發平台 OpenWrite 發布！