我的家庭實(shí)驗(yàn)室里有十幾臺(tái)物理計(jì)算機(jī)以及更多的虛擬機(jī)。這些系統(tǒng)中的大多數(shù)是我用來進(jìn)行測試和實(shí)驗(yàn)的。我經(jīng)常寫使用自動(dòng)化來簡化系統(tǒng)管理任務(wù)的文章。我還在多個(gè)地方寫過，我從自己的錯(cuò)誤中學(xué)到的東西比幾乎任何其他方式都多。

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

我給自己制造了一個(gè)大麻煩。作為多年的系統(tǒng)管理員，我寫了數(shù)百篇關(guān)于 Linux 的文章和五本書，我應(yīng)該對(duì) Linux 更了解。話又說回來，我們都會(huì)犯錯(cuò)，這是一個(gè)重要的教訓(xùn)：你永遠(yuǎn)不會(huì)因?yàn)橛薪?jīng)驗(yàn)而不犯錯(cuò)。

我不打算討論我的錯(cuò)誤的細(xì)節(jié)。告訴你這是一個(gè)錯(cuò)誤就足夠了，在我做之前我應(yīng)該多考慮一下我在做什么。此外，細(xì)節(jié)并不是重點(diǎn)。經(jīng)驗(yàn)不能讓你免于犯下的每一個(gè)錯(cuò)誤，但它可以幫助你恢復(fù)。這就是本文要討論的內(nèi)容：使用現(xiàn)場 USB 發(fā)行版啟動(dòng)并進(jìn)入恢復(fù)模式。

問題

首先，我制造了問題，這本質(zhì)上是 /etc/default/grub 文件的錯(cuò)誤配置。接下來，我使用 Ansible 將錯(cuò)誤配置的文件分發(fā)到我所有的物理計(jì)算機(jī)并運(yùn)行 grub2-mkconfig。全部 12 個(gè)。這真的，真的很快。

除了兩臺(tái)之外，所有的都無法啟動(dòng)。它們?cè)?Linux 啟動(dòng)的早期階段崩潰，出現(xiàn)各種無法定位 /root 文件系統(tǒng)的錯(cuò)誤。

我可以使用 root 密碼進(jìn)入“維護(hù)”模式，但是如果沒有掛載 /root，即使是最簡單的工具也無法訪問。直接引導(dǎo)到恢復(fù)內(nèi)核也不起作用。系統(tǒng)真的被破壞了。

Fedora 恢復(fù)模式

解決此問題的唯一方法是找到進(jìn)入恢復(fù)模式的方法。當(dāng)一切都失敗時(shí)，F(xiàn)edora 提供了一個(gè)非?？岬墓ぞ撸河糜诎惭b Fedora 新實(shí)例的現(xiàn)場 USBLive USB 驅(qū)動(dòng)器。

將 BIOS 設(shè)置為從現(xiàn)場 USB 設(shè)備啟動(dòng)后，我啟動(dòng)到 Fedora 36 Xfce 的現(xiàn)場live用戶桌面。我在桌面上打開了兩個(gè)相鄰的終端會(huì)話，并在兩者中都切換到了 root 權(quán)限。

我在其中一個(gè)運(yùn)行了 lsblk 以供參考。我使用該結(jié)果來識(shí)別 / 根分區(qū)以及 boot 和 efi 分區(qū)。我使用了我的一臺(tái)虛擬機(jī)，如下所示。在這種情況下沒有 efi 分區(qū)，因?yàn)榇?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 分區(qū)很容易識(shí)別為 /boot，根（/）分區(qū)也很明顯。

在另一個(gè)終端會(huì)話中，我執(zhí)行了一系列步驟來恢復(fù)我的系統(tǒng)。特定的卷組名稱和設(shè)備分區(qū)（例如 /dev/sda1）因系統(tǒng)而異。此處顯示的命令特定于我的情況。

目標(biāo)是使用現(xiàn)場 USB 引導(dǎo)并完成啟動(dòng)，然后僅在鏡像目錄中掛載必要的文件系統(tǒng)，并運(yùn)行 chroot 命令在 chroot 鏡像目錄中運(yùn)行 Linux。這種方法繞過損壞的 GRUB（或其他）配置文件。但是，它提供了一個(gè)完整的運(yùn)行系統(tǒng)，其中安裝了所有原始文件系統(tǒng)以進(jìn)行恢復(fù)，既是所需工具的來源，也是要進(jìn)行更改的目標(biāo)。

以下是步驟和相關(guān)命令：

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

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

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

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

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

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

# cd /mnt/sysimage

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

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

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

# mount --bind /dev dev

(8) chroot 到系統(tǒng)鏡像：

# chroot /mnt/sysimage

系統(tǒng)現(xiàn)在已經(jīng)準(zhǔn)備好了，無論你需要做什么，都可以把它恢復(fù)到一個(gè)工作狀態(tài)。然而，有一次我能夠在這種狀態(tài)下運(yùn)行我的服務(wù)器數(shù)天，直到我能夠研究測試出真正的修復(fù)方法。我并不推薦這樣做，但在緊急情況下，當(dāng)有任務(wù)需要啟動(dòng)和運(yùn)行時(shí)，這可能是一個(gè)選擇。

解決方案

當(dāng)我讓每個(gè)系統(tǒng)進(jìn)入恢復(fù)模式，修復(fù)就很容易了。因?yàn)槲业南到y(tǒng)現(xiàn)在就像成功啟動(dòng)一樣工作，我只需對(duì) /etc/default/grub 和 /etc/fstab 進(jìn)行必要的更改并運(yùn)行 grub2-mkconfig > boot/grub2/grub.cfg 命令。我使用 exit 命令退出 chroot 環(huán)境，然后重啟主機(jī)。

當(dāng)然，我無法自動(dòng)從我的意外事故中恢復(fù)過來。我必須在每臺(tái)主機(jī)上手動(dòng)執(zhí)行整個(gè)過程，這是使用自動(dòng)化快速和容易地傳播我自己的錯(cuò)誤的一點(diǎn)報(bào)應(yīng)。

得到教訓(xùn)

盡管它們很有用，我曾經(jīng)討厭在我的一些系統(tǒng)管理員工作中舉行的“經(jīng)驗(yàn)教訓(xùn)”會(huì)議，但看來我確實(shí)需要提醒自己一些事情。因此，這里是我從這場自作自受的慘敗中獲得的“教訓(xùn)”。

首先，無法引導(dǎo)的十個(gè)系統(tǒng)使用了不同的卷組命名方案，而我的新 GRUB 配置沒有考慮到這一點(diǎn)。我只是忽略了它們可能不同的事實(shí)。

• 徹底考慮清楚。
• 并非所有系統(tǒng)都相同。
• 測試一切。
• 驗(yàn)證一切。
• 永遠(yuǎn)不要做假設(shè)。

現(xiàn)在一切正常。希望我也聰明一點(diǎn)。