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

您的 Ubuntu 伺服器在更新或斷電後重啟，然後停留在「進入緊急模式」提示處。 SSH 不可用，服務已停止，控制台要求維護。這通常表示 systemd 無法完成必要的啟動步驟，通常是因為檔案系統檢查失敗或找不到所需的掛載點。請將此訊息視為線索：在編輯檔案或執行修復命令之前，請先確定故障單元。

本指南適用於使用 systemd 的傳統 Ubuntu Server 安裝。 Ubuntu Core、加密系統、雲端映像檔和營運商託管伺服器上的命令和啟動選單可能有所不同。目前的 Ubuntu 手冊頁將 emergency.target 描述為一個最小化的 shell，它不會啟動常規服務或掛載普通檔案系統；根據存取方式的不同，根檔案系統可能是唯讀的，也可能是讀寫的。因此，第一步是檢查並備份。

1. 在進行任何更改之前，請先閱讀故障碼。

如果提示，請登入本機控制台或提供者控制台。在實體機器上，連接鍵盤和顯示器；在虛擬伺服器上，使用提供者的序列控制台或恢復控制台。拍攝或複製完整的錯誤訊息，特別是單元名稱（例如 `<unit_name>`）systemd-fsck@dev-disk-by-uuid-....service或以 `<mount_unit_name>` 結尾的掛載單元.mount。缺少 UUID、檔案系統檢查失敗和服務故障需要不同的修復方法。

從緊急啟動介面，檢查故障單元和目前啟動日誌：

systemctl --failed
journalctl -xb

尋找第一個有意義的錯誤，而不僅僅是最後一行「依賴項失敗」。如果日誌中標識了掛載點，請記下其掛載點和裝置 UUID。如果日誌中標識了與儲存無關的服務，請勿/etc/fstab隨意變更；請檢查該特定單元systemctl status unit-name及其最近的日誌訊息。

2. 檢查根檔案系統是否允許編輯

在編輯設定檔之前，請先查看根檔案系統的掛載方式：

findmnt /

如果選項顯示ro“唯讀”，則根檔案系統為唯讀。如果檔案系統其他方面正常，而您只需要進行一些小的設定修復，請將其重新掛載為讀寫模式：

mount -o remount,rw /

再次運行findmnt /以確認更改。如果重新掛載失敗，請停止並記錄錯誤。只讀根磁碟區可以作為檔案系統故障的一種保護性措施；強制寫入或重複重試掛載可能會增加復原難度。如果根卷出現損壞，請使用救援環境或尋求服務提供者的支援。

3. 檢查磁碟並將其與 /etc/fstab 檔案進行比較

常見原因是條目/etc/fstab過時：磁碟被移除、UUID 變更或掛載路徑輸入錯誤。首先列出偵測到的檔案系統及其識別碼：

lsblk -f
blkid

然後讀取掛載表配置：

cat /etc/fstab

lsblk -f將每個已配置的 UUID 與 `ls -l`或 `ls -l` 的輸出進行匹配blkid，並檢查掛載點和檔案系統類型是否正確。不要/dev/sdb1僅根據裝置當前字母替換裝置名稱（例如 `/dev/sdev`），因為裝置順序可能會變更。 UUID 通常較穩定，但仍需與實際檔案系統相符。

該/etc/fstab檔案在啟動時會轉換成 systemd 掛載單元。它的欄位和選項都有特定的意義，因此如果某個條目不熟悉，請查閱官方的Ubuntu fstab 手冊。

4. 暫時繞過選購的缺失安裝座

如果故障條目指向一個故意移除的非必要資料磁碟，請備份/etc/fstab該文件，然後在該行開頭新增註解掉該行#。這樣可以測試缺少的掛載點是否為啟動阻塞點。除非您了解系統的儲存佈局，否則請勿註解掉根檔案系統/boot或加密磁碟區條目。

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

或者，如果磁碟在正常運作中應該是可選的，請nofail在驗證預期行為後再考慮掛載選項。僅將其用於真正可選的掛載：將其添加到必需的系統磁碟區可能會掩蓋真正的儲存故障。網路檔案系統可能需要額外的 systemd 特定選項和網路相依性；請勿從不相關的設定複製選項。

編輯完成後，讓 systemd 重新載入產生的單元並測試檔案：

systemctl daemon-reload
mount -a

閱讀所有輸出。雖然返回結果為空並不代表所有應用程式都能使用已掛載的數據，但報告的 UUID、語法錯誤或掛載錯誤會告訴你還需要修復哪些問題。 systemd -fstab-generator 手冊解釋了 systemd 如何將 fstab 條目轉換為掛載單元。

5. 修復錯誤的 UUID、路徑或掛載選項

如果磁碟存在但其 UUID 不同，請在更新符合UUID=...欄位之前確認已識別正確的檔案系統。確認掛載點目錄存在、檔案系統類型準確，且選項對此檔案系統有效。一次更正一個條目，然後重新systemctl daemon-reload運行mount -a。

對於可選的可移動磁碟或輔助資料磁碟，設定適當的可選掛載策略可防止裝置缺失導致啟動失敗。對於關鍵卷，應修復設備、線纜、加密映射或標識符，而不是掩蓋故障。如果故障單元指向 LUKS 或 LVM 設備，請檢查相關的對應和磁碟區狀態；不要將其 UUID 替換為名稱相似的分割區。

6. 僅當目標設備卸載後才執行檔案系統檢查

如果控制台明確報告檔案系統錯誤，請在修復之前確定檔案系統類型和裝置。切勿對已掛載的檔案系統（尤其是活動根檔案系統）執行修復工具。 Ubuntu fsck 手冊中描述了包裝命令；正確的檢查器和修復選項取決於檔案系統。

對於 ext2、ext3 或 ext4 資料分割區，首先確認它未掛載findmnt。如果已掛載，請先卸載再進行檢查。在適當的救援環境中，典型的 ext4 檢查命令如下：

sudo e2fsck -f /dev/DEVICE

/dev/DEVICE僅在匹配到正確的分區後才進行替換lsblk -f。請仔細閱讀檢查器的問題和狀態；切勿在未了解資料遺失風險的情況下，自動選擇「全部是」。對於無法從正在運行的緊急 shell 中卸載的根檔案系統，請啟動 Live 或提供者復原環境，並在離線狀態下進行檢查。 Btrfs、XFS 和其他檔案系統使用不同的工具和修復程式。尤其需要注意的是，不要將通用fsck命令視為所有檔案系統類型都已修復的證明。

7. 僅當 shell 不可用時才使用 GRUB 或外部復原。

如果伺服器始終無法進入緊急 shell，請開啟 GRUB 選單，並在發行版提供復原選項時嘗試使用。在標準的 Ubuntu 系統中，通常可以透過在傳統 BIOS 系統上按住 Shift 鍵或在 UEFI 系統上按 Esc 鍵來開啟選單，但託管的虛擬機器可能會使用不同的控制台流程。對於一次性的 systemd 緊急啟動，管理員可以編輯選取的 GRUB 條目，並將其新增systemd.unit=emergency.target至 Linux 核心命令列。此變更僅適用於本次啟動；在下次正常啟動之前，請將其刪除。請參閱官方的GNU GRUB 選單參考文件。

如果無法掛載啟動卷，請使用 Ubuntu Live 環境或雲端服務供應商的救援系統進行檢查。僅當與安裝環境匹配時才解鎖加密儲存並啟動 LVM。從復原模式掛載伺服器根檔案系統有額外風險；在確定磁碟和檔案系統之前，請勿對其進行寫入操作。 Ubuntu Core 使用自己的復原流程，不能盲目地依照桌面或常規伺服器 GRUB 步驟進行修復。

8. 重新啟動並驗證修復是否成功

當報告的問題原因得到修正且掛載測試通過後，重新啟動電腦：

reboot

啟動後，驗證主機是否達到通常的多用戶目標，預期的檔案系統是否已掛載，以及重要服務是否已啟動：

systemctl is-system-running
systemctl --failed
findmnt --target /

使用 `<command>` 檢查預期的資料掛載點findmnt /path/to/mount，並使用 `<command>` 確認關鍵服務systemctl status service-name。如果緊急模式再次出現，請重新檢查新啟動時的首次故障，而不是重複相同的修復步驟。成功救援意味著伺服器完成正常啟動，所需的儲存和服務可用；僅僅到達登入提示符號是不夠的。

有關 systemd 的目前行為，請參閱 Ubuntu特殊單元手冊。軟體包版本和復原選單可能會因 Ubuntu 版本和託管平台而異，因此，如果命令或單元有所不同，請使用已安裝版本的文件。