我的家庭實驗室里有十幾臺物理計算機以及更多的虛擬機。這些系統中的大多數是我用來進行測試和實驗的。我經常寫使用自動化來簡化系統管理任務的文章。我還在多個地方寫過，我從自己的錯誤中學到的東西比幾乎任何其他方式都多。

在過去的幾周里，我學到了很多東西。

我給自己制造了一個大麻煩。作為多年的系統管理員，我寫了數百篇關于 Linux 的文章和五本書，我應該對 Linux 更了解。話又說回來，我們都會犯錯，這是一個重要的教訓：你永遠不會因為有經驗而不犯錯。

我不打算討論我的錯誤的細節。告訴你這是一個錯誤就足夠了，在我做之前我應該多考慮一下我在做什么。此外，細節并不是重點。經驗不能讓你免于犯下的每一個錯誤，但它可以幫助你恢復。這就是本文要討論的內容：使用現場 USB 發行版啟動并進入恢復模式。

問題

首先，我制造了問題，這本質上是 /etc/default/grub 文件的錯誤配置。接下來，我使用 Ansible 將錯誤配置的文件分發到我所有的物理計算機并運行 grub2-mkconfig。全部 12 個。這真的，真的很快。

除了兩臺之外，所有的都無法啟動。它們在 Linux 啟動的早期階段崩潰，出現各種無法定位 /root 文件系統的錯誤。

我可以使用 root 密碼進入“維護”模式，但是如果沒有掛載 /root，即使是最簡單的工具也無法訪問。直接引導到恢復內核也不起作用。系統真的被破壞了。

Fedora 恢復模式

解決此問題的唯一方法是找到進入恢復模式的方法。當一切都失敗時，Fedora 提供了一個非?？岬墓ぞ撸河糜诎惭b Fedora 新實例的現場 USBLive USB 驅動器。

將 BIOS 設置為從現場 USB 設備啟動后，我啟動到 Fedora 36 Xfce 的現場live用戶桌面。我在桌面上打開了兩個相鄰的終端會話，并在兩者中都切換到了 root 權限。

我在其中一個運行了 lsblk 以供參考。我使用該結果來識別 / 根分區以及 boot 和 efi 分區。我使用了我的一臺虛擬機，如下所示。在這種情況下沒有 efi 分區，因為此 VM 不使用 UEFI。

# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0           7:0    0  1.5G  1 loop
loop1           7:1    0    6G  1 loop
├─live-rw     253:0    0    6G  0 dm   /
└─live-base   253:1    0    6G  1 dm   
loop2           7:2    0   32G  0 loop
└─live-rw     253:0    0    6G  0 dm   /
sda             8:0    0  120G  0 disk
├─sda1          8:1    0    1G  0 part
└─sda2          8:2    0  119G  0 part
  ├─vg01-swap 253:2    0    4G  0 lvm  
  ├─vg01-tmp  253:3    0   10G  0 lvm  
  ├─vg01-var  253:4    0   20G  0 lvm  
  ├─vg01-home 253:5    0    5G  0 lvm  
  ├─vg01-usr  253:6    0   20G  0 lvm  
  └─vg01-root 253:7    0    5G  0 lvm  
sr0            11:0    1  1.6G  0 rom  /run/initramfs/live
zram0         252:0    0    8G  0 disk [SWAP]

/dev/sda1 分區很容易識別為 /boot，根（/）分區也很明顯。

在另一個終端會話中，我執行了一系列步驟來恢復我的系統。特定的卷組名稱和設備分區（例如 /dev/sda1）因系統而異。此處顯示的命令特定于我的情況。

目標是使用現場 USB 引導并完成啟動，然后僅在鏡像目錄中掛載必要的文件系統，并運行 chroot 命令在 chroot 鏡像目錄中運行 Linux。這種方法繞過損壞的 GRUB（或其他）配置文件。但是，它提供了一個完整的運行系統，其中安裝了所有原始文件系統以進行恢復，既是所需工具的來源，也是要進行更改的目標。

以下是步驟和相關命令：

(1) 創建目錄/mnt/sysimage 以提供chroot 目錄的位置。

(2) 將根分區掛載到/mnt/sysimage：

# mount /dev/mapper/vg01-root /mnt/sysimage

(3) 將/mnt/sysimage 設為你的工作目錄：

(4) 掛載/boot 和/boot/efi 文件系統。

(5) 掛載其他主要文件系統。此步驟不需要像/home 和/tmp 這樣的文件系統：

# cd /mnt/sysimage

(6) 綁定已掛載的重要文件系統，它們必須在已經 chroot 的系統和原始的現場系統之間共享，而后者仍然在外部運行：

# mount --bind /sys sys
# mount --bind /proc proc

(7) 一定要最后操作/dev 目錄，否則其他文件系統不能掛載：

# mount --bind /dev dev

(8) chroot 到系統鏡像：

# chroot /mnt/sysimage

系統現在已經準備好了，無論你需要做什么，都可以把它恢復到一個工作狀態。然而，有一次我能夠在這種狀態下運行我的服務器數天，直到我能夠研究測試出真正的修復方法。我并不推薦這樣做，但在緊急情況下，當有任務需要啟動和運行時，這可能是一個選擇。

解決方案

當我讓每個系統進入恢復模式，修復就很容易了。因為我的系統現在就像成功啟動一樣工作，我只需對 /etc/default/grub 和 /etc/fstab 進行必要的更改并運行 grub2-mkconfig > boot/grub2/grub.cfg 命令。我使用 exit 命令退出 chroot 環境，然后重啟主機。

當然，我無法自動從我的意外事故中恢復過來。我必須在每臺主機上手動執行整個過程，這是使用自動化快速和容易地傳播我自己的錯誤的一點報應。

得到教訓

盡管它們很有用，我曾經討厭在我的一些系統管理員工作中舉行的“經驗教訓”會議，但看來我確實需要提醒自己一些事情。因此，這里是我從這場自作自受的慘敗中獲得的“教訓”。

首先，無法引導的十個系統使用了不同的卷組命名方案，而我的新 GRUB 配置沒有考慮到這一點。我只是忽略了它們可能不同的事實。

• 徹底考慮清楚。
• 并非所有系統都相同。
• 測試一切。
• 驗證一切。
• 永遠不要做假設。

現在一切正常。希望我也聰明一點。