當一台 Linux 節點因為一次誤操作而拒絕啟動時，啟動鏈往往是首要排查對象。如果你需要在生產環境機器上恢復誤刪的 GRUB 選單，這個問題通常並沒有表面看上去那麼玄乎。多數情況下，故障點位於韌體、引導載入器核心映像、/boot 下的設定，以及根檔案系統之間。對於運行遠端伺服器租用業務的團隊來說，真正的難點不在理論，而在於如何在不進一步破壞磁碟狀態的前提下完成可控恢復。

為什麼缺失 GRUB 選單會破壞啟動路徑

GRUB 充當的是平台韌體與作業系統核心之間的交接層。根據 GNU GRUB 官方手冊，正常啟動依賴於 prefix 和 root 變數、成功載入 normal 模組，然後再讀取 grub.cfg。如果這條路徑斷裂，機器就可能直接掉入救援模式，而不是顯示啟動選單。

從維運視角來看，這意味著「選單被刪除」這一表象，背後實際可能對應多種底層故障：

  • /boot/grub 下的設定檔遺失或損壞。
  • 引導載入器被安裝到了錯誤的磁碟或分割區。
  • 儲存調整後，啟動分割區的位置發生了變化。
  • 伺服器在傳統 BIOS 與 UEFI 啟動預期之間發生了切換。
  • 引導載入器已經無法讀取相關檔案系統。

GRUB 選單遺失的常見表現

引導問題通常不會給出友善的圖形介面提示，而是以非常簡短甚至冷冰冰的錯誤訊息形式出現。GRUB 官方手冊指出，救援模式只提供精簡命令集，通常包括 ls、set、unset 和 insmod。這一點本身就是一個明顯線索。

  • 控制台直接停在 grub rescue>。
  • 畫面出現分割區缺失或未知檔案系統等錯誤。
  • 主機反覆循環，卻始終無法載入核心。
  • 在設定修改或磁碟操作後，啟動選單完全不再顯示。
  • 遠端網路存取已經中斷，但帶外控制台仍然可用。

在遠端伺服器租用和伺服器託管場景中，這些現象尤為關鍵，因為你通常無法直接接觸硬體。恢復工作高度依賴控制台存取、救援媒介，以及對裝置的準確識別。

通常是什麼原因導致故障

有經驗的技術人員都知道，引導故障很少是「無緣無故」發生的。GRUB 選單被刪除，往往只是上一步操作留下的表層症狀。常見觸發原因包括：

  1. 清理系統時誤刪了 /boot 下的檔案。
  2. 修改了分割表或檔案系統 UUID。
  3. 複製磁碟後，沒有重新安裝引導載入器。
  4. 在救援環境中掛載了錯誤的目標系統。
  5. 在根分割區未完整掛載的情況下重新產生設定。
  6. 在 UEFI 機器上套用了 BIOS 風格步驟，或反過來操作。

主流 Linux 官方文件普遍將救援啟動、chroot 以及重新安裝 GRUB 視為標準修復路徑，適用於已安裝引導器不可用的情況。

動磁碟之前，先做這些檢查

不要一開始就執行重裝命令。真正符合極客風格的修復，首先是有紀律的。在寫入磁碟前，應先確認以下事項：

  • 系統韌體目前使用的是 BIOS 還是 UEFI？
  • 哪一個分割區是根分割區？是否存在單獨的 /boot 或 EFI 系統分割區？
  • 維護之後，啟動順序是否被改動？
  • 目標磁碟能否在救援環境中被正常讀取？
  • 如果存在多台相似節點，你是否連到了正確的那一台伺服器？

GNU GRUB 文件特別提醒，不要假設作業系統識別到的磁碟順序一定與韌體中的啟動順序一致。在擁有大量儲存裝置的主機或虛擬化環境中，這個細節尤其容易出問題。

一套實用的恢復流程

最穩妥的修復方式通常是：使用救援環境啟動系統、掛載已安裝的目標系統、透過 chroot 進入原系統，再重新安裝引導載入器。這一方法在 GNU GRUB 指南及企業級 Linux 恢復文件中都屬於標準做法。

  1. 從救援媒介或服務商控制台工具啟動。 使用恢復 ISO 或內建救援模式，使主系統磁碟暫時不作為啟動目標。
  2. 識別分割區。 檢查區塊裝置，明確根分割區、啟動分割區和 EFI 分割區布局後再進行掛載。
  3. 掛載已安裝系統。 先掛載根分割區；如果存在獨立的啟動分割區，也要掛載；若為 UEFI 系統，則還需掛載 EFI 系統分割區。
  4. 綁定執行時目錄。 讓 /dev、/proc 和 /sys 在目標系統中可用。
  5. 進入 chroot。 這樣你是在已安裝系統的上下文中重建引導器，而不是在救援映像環境中操作。
  6. 重新安裝 GRUB 並產生設定。 根據所用發行版家族和韌體模式，執行對應命令。
  7. 退出、規範卸載並重新啟動。 然後透過正常啟動路徑驗證修復結果。

一套最小化命令流程通常如下：

mount /dev/ROOT_PART /mnt
mount /dev/BOOT_PART /mnt/boot
mount /dev/EFI_PART /mnt/boot/efi
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

grub-install /dev/SYSTEM_DISK
grub-mkconfig -o /boot/grub/grub.cfg

具體路徑會因系統而異。在某些發行版中，設定檔名稱或命令封裝方式略有不同，但恢復邏輯是一致的。無論在 BIOS 還是 UEFI 場景下，官方文件都強調：應在正確掛載後的系統環境中重新安裝引導器。

如果你卡在 grub rescue 提示字元

有時候，你需要先臨時把系統引導起來，再做完整修復。GNU GRUB 手冊說明，如果問題是 prefix 設定錯誤，那麼你可以手動設定 root 和 prefix，載入 normal 模組，並嘗試進入正常模式。

  • 執行 ls 列舉可見裝置。
  • 逐一檢查可能的分割區，直到找到包含 /boot/grub 的那個。
  • 把 root 設定為該分割區。
  • 把 prefix 設定為對應的 GRUB 目錄。
  • 載入 normal 模組並啟動 normal 模式。
set
ls
set root=(hd0,1)
set prefix=(hd0,1)/boot/grub
insmod normal
normal

這只是戰術性過渡方案，不是最終修復。GRUB 官方手冊明確指出，進入 rescue 模式往往說明 GRUB 本身沒有被正確安裝，因此後續仍應執行一次完整的重新安裝。

BIOS 和 UEFI 不能混為一談

維運人員最常見的錯誤之一，就是不檢查啟動模式，直接套用「通用教學」。無論是 Debian 關於 EFI 模式下重裝 GRUB 的指導，還是企業級 Linux 的恢復文件，都會將 UEFI 與 BIOS 的處理流程嚴格區分。原因很簡單：韌體介面不同，啟動資源所在位置和引導器註冊方式也不同。

  • BIOS 系統通常將 GRUB 安裝到整個磁碟裝置，而不是單一檔案系統路徑。
  • UEFI 系統則要求在重裝之前正確掛載 EFI 系統分割區。
  • 混用兩種假設，往往會導致表面看似修好了，重新啟動後卻依然無法啟動。

如果你維護的是伺服器託管環境中的裸機設備，建議為每台節點記錄韌體模式。如果你管理的是伺服器租用環境中的虛擬實例，那麼在進行底層變更前，若平台支援，最好先對磁碟布局進行快照。

面向伺服器租用環境的遠端恢復注意事項

在遠端伺服器上處理引導器問題，與在實驗室工作站上操作完全不同。比起速度，更重要的是流程紀律。較好的實務包括：

  1. 使用帶外控制台，而不是依賴已經中斷的網路服務。
  2. 在修改前記錄目前分割表和掛載資訊。
  3. 透過容量、UUID 和分割區布局確認目標磁碟，而不是靠猜測。
  4. 關鍵系統操作時，最好由一人執行，另一人覆核命令。
  5. 如果主機承載客戶業務，應在有回滾預案的維護窗口內進行修復。

對於面向公網的 Linux 服務來說，這一點尤為重要。一個看似小小的檔案誤刪，完全可能演變成持續時間不短的業務中斷。

如何避免下一次 GRUB 事故

當伺服器恢復正常後，最好花幾分鐘復盤並加固之前出錯的工作流程。預防永遠比再次進入救援模式更划算。

  • 不要把 /boot 當成可隨意清理的儲存目錄。
  • 系統部署完成後，記錄磁碟、分割區和 EFI 布局。
  • 在維護窗口內測試設定重新產生流程。
  • 將救援存取憑證與常規登入路徑分離管理。
  • 對分割區調整和遷移操作實施變更控制。
  • 優先使用標籤或 UUID，而不是脆弱的磁碟順序引用。

最後這一點與 GRUB 官方文件的建議高度一致：不要依賴磁碟順序這類容易變化的假設，因為韌體與作業系統對磁碟的認知並不總是完全一致。

最後總結

要在 Linux 伺服器上恢復誤刪的 GRUB 選單，就要像系統工程師一樣思考：先確認韌體模式，再找準真正的啟動分割區，正確掛載已安裝系統，透過 chroot 重建 GRUB，然後再重新啟動驗證。救援模式可以作為臨時過渡，但要想實現持久恢復，仍然需要乾淨地重新安裝引導器並重新產生設定。在遠端伺服器租用和伺服器託管維運中，精準永遠比倉促更重要，而一份完善的啟動布局文件，往往能把一次高壓故障處理變成一次短時間的例行維護。