Ubuntu 伺服器啟動進入緊急模式：逐步救援指南

範例場景： Casey 維護一台假設的 Ubuntu Server 虛擬機，在一次重新啟動後進入了緊急模式，而/etc/fstab重啟前不久，Casey 剛剛向虛擬機添加了一個可選的資料卷掛載點。 Casey 可以存取控制台，但無法建立 SSH 會話。掛載點的更改只是一個線索，並非確鑿的原因：緊急模式可能在多次啟動失敗後出現，因此 Casey 在進行任何更改之前都會先檢查當前機器的日誌。下面的終端面板顯示的是範例佈局和占位符輸出，並非實際的修復或測試。

緊急模式是什麼意思

在安裝了 systemd 的 Ubuntu Server 上，emergency.target此指令會在主控制台啟動一個最小化的 shell。它的功能比 `sudo apt-get` 更有限rescue.target，`sudo apt-get` 會啟動基本系統和僅包含必要服務的系統掛載點。根據進入緊急模式的路徑，根檔案系統可能已經以唯讀或讀寫模式掛載。請務必檢查根檔案系統的狀態，不要想當然地假設其處於唯讀或讀寫模式。請參閱上游systemd special-target 文件。

首先區分提示符號。 systemd 緊急 shell 通常會顯示“歡迎進入緊急模式！”，並可能要求輸入 root 密碼以進行維護。 BusyBox 提示字元（例如）表示(initramfs)啟動尚未切換到已安裝的根檔案系統；grub>而其他grub rescue>提示符號則表示引導程式出現問題。這些情況需要不同的恢復方法。如果 root 帳戶被鎖定或伺服器位於遠端，請使用主機提供者的串列埠/VNC 控制台或救援環境；此時通常無法使用 SSH。在理解並修復所報告的故障之前，請勿按 Ctrl+D 繼續操作。

逐步救援

1. 保持控制台存取權限並記錄確切的故障訊息

保持在緊急控制台中。記下最後一次掛載失敗的資訊或服務名稱，以及提示符號上方列印的任何裝置路徑或 UUID。 Casey 最近的fstab編輯值得查看，但不要註解所有失敗的行，也不要僅憑「緊急」一詞就運行修復命令。如果系統是虛擬機，請在修復和下次重新啟動期間保持提供者控制台開啟。

2. 讀取目前啟動日誌和失敗單元

在緊急狀態下，運轉：

journalctl -xb -p err --no-pager
systemctl --failed --no-pager

-b將日誌查詢限制在本次啟動過程中，並-p err篩選優先順序較高的錯誤。尋找第一個相關的錯誤，而不僅僅是最後一連串的「依賴項失敗」訊息。如果掛載單元失敗，請記下其轉義後的單元名稱和目標路徑；如果服務失敗，請確定它是掛載失敗的原因還是只是掛載失敗的結果。 Ubuntujournalctl(1)手冊中記錄了啟動和單元篩選的相關內容。

3. 檢查根掛載點和可用空間

在編輯檔案或嘗試修復之前，請檢查根檔案系統的掛載方式以及系統是否已耗盡區塊或 inode：

findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /

在findmnt輸出中，ro`readonly` 表示只讀，rw`readwrite` 表示讀寫。只讀根目錄可能是復原過程中有意為之，也可能反映檔案系統故障。如果核心日誌報告 I/O 或檔案系統錯誤，請勿立即強制以讀寫模式重新掛載。檔案系統已滿或 inode 表已耗盡也可能導致不相關的服務和掛載失敗。 Ubuntu 手冊findmnt(8)介紹如何檢查已掛載的檔案系統。

4. 驗證/etc/fstab和核實設備標識符

由於 Casey 最近進行了更改/etc/fstab，請檢查其語法以及引用的設備是否存在：

findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify --verbose檢查 fstab 條目是否有解析和可用性問題。將UUID=可疑行中的每個條目與 `/ etc/fstab/stabs lsblk -f/` 或`/etc/fstab/stabs/` 顯示的 UUID 進行blkid比較。同時檢查掛載點、檔案系統類型和選項。從其他磁碟複製的 UUID、未連接的裝置或無效的選項都可能導致所需的掛載無法完成。不要猜測分區名稱，例如/dev/sda1`/etc/fstab/stabs/`；裝置名稱在每次啟動之間都可能變更。

5. 僅修正已確認的安裝問題

如果根檔案系統可寫，且 fstab 檢查發現錯誤行，請在編輯前進行備份：

cp -a /etc/fstab /etc/fstab.before-rescue
nano /etc/fstab

僅在確認目標設備後才能更正 UUID 或其他欄位。如果掛載點確實是可選的，且伺服器在缺少該磁碟區時仍應啟動，則可以使用支援 systemd 的 fstab 行，nofail並設定有限的裝置等待時間，例如：

UUID=VERIFIED-UUID /srv/archive ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

請將佔位符替換為真實的 UUID 並使用實際的檔案系統類型。請勿將其新增nofail至根檔案系統、引導檔案系統或機器及其應用程式正常運作所需的其他檔案系統。啟用此選項後nofail，即使掛載失敗，啟動程序仍會繼續，因此依賴的服務可能仍需維護。 Ubuntu systemd mount-unit 手冊中記錄了這些 fstab 選項。

編輯完成後，請再次驗證後再嘗試掛載：

findmnt --verify --verbose
systemctl daemon-reload
mount /srv/archive

請使用上一條指令中指定的實際掛載點。如果仍然失敗，請閱讀新的錯誤訊息，並檢查磁碟是否已連接且狀況良好。如果根檔案系統是唯讀的，請勿盲目地強制變更；請使用復原環境或可啟動的 Ubuntu 媒體來安全地檢查和編輯已安裝的系統。

6. 僅當日誌指向某個故障服務時才調查該故障服務。

緊急模式並不意味著每個故障服務都導致了啟動停止。如果相關錯誤訊息指向某個服務，請檢查該服務單元及其日誌，而不是封鎖或停用它：

systemctl status example.service --no-pager
journalctl -u example.service -b --no-pager

請替換example.service為準確的單元名稱。檢查其設定檔、可執行檔、憑證或所需的掛載點是否缺失。如果故障源自於 Casey 缺少的資料卷，請先修復該掛載點，然後再重新評估服務。停用關鍵服務可能會掩蓋故障症狀，但會導致伺服器無法使用。

7. 將檔案系統錯誤視為離線修復任務

如果核心日誌報告檔案系統損壞或儲存 I/O 錯誤，請盡可能停止寫入操作，並在修復前保留備份或提供者快照。使用 `npm run dev` 指令確認特定的設備和檔案系統lsblk -f。對於根檔案系統，請啟動至提供者的救援系統或 Ubuntu 復原/Live 介質，確保目標分割區已卸載，然後使用適用於該檔案系統的檢查工具。對於 ext2/3/4 檔案系統，該工具是e2fsck`npm run dev`；XFS、Btrfs 和其他格式的檢查步驟有所不同。

切勿在已掛載的檔案系統上執行fsck任何e2fsck指令，包括已掛載的唯讀根檔案系統。 Ubuntue2fsck(8)手冊警告稱，檢查已掛載的檔案系統通常是不安全的，且檢查結果無效。如果磁碟報告反覆出現 I/O 錯誤，請優先恢復資料或聯絡儲存服務供應商，而不是重複嘗試修復。

8. 恢復正常啟動並驗證結果

確認故障原因並排除後，請從主機重新啟動：

systemctl reboot

Ubuntu 啟動後，檢查配置的預設目標、目前系統狀態、失敗的單元以及新的啟動項目：

systemctl get-default
systemctl is-system-running
systemctl --failed --no-pager
journalctl -b -p err --no-pager
findmnt --verify --verbose

如果您有意繼續目前啟動，systemctl default則會要求 systemd 啟動已配置的預設目標。僅在阻塞錯誤修復後才使用此功能；它不會修復無效的掛載或損壞的檔案系統。systemctl get-default顯示已配置的預設目標；systemctl is-system-running報告 systemd 認為目前狀態是運行中、降級或其他狀態。乾淨恢復意味著預期的檔案系統已掛載，所需服務已激活，並且重新啟動後不會再次出現相同的緊急情況。

如果提示(initramfs)是

不要盲目地在 BusyBox 的 initramfs 中執行 systemd 緊急 shell 步驟。 initramfs 階段會在將控制權交給已安裝的系統之前，請嘗試尋找並掛載真正的根檔案系統。請記錄確切的錯誤訊息，檢查預期設備是否出現在 `<path>`/dev和 `<path>`中/dev/disk/by-uuid，並將啟動命令列中的root=值與實際的根 UUID 進行比較。如果磁碟或加密/LVM 磁碟區遺失，請使用提供者的儲存和復原工具進行調查。在未識別遺失裝置的情況下重建 initramfs 或變更 GRUB 參數可能會使啟動復原更加困難。

對於 Casey 假設的虛擬機器而言，理想的結果是找到問題根源並進行精準的修復：恢復預期的可選卷、更正其已確認的標識符，或者僅在工作負載確實允許的情況下才將其配置為可選卷。然後在關閉恢復會話之前，從控制台驗證下次啟動是否正常。