我如何使用現場 USB 設備恢復我的 Linux 系統

Fedora 現場 USB 發行版為引導和進入恢復模式提供了有效的解決方案。

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

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

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

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

問題

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

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

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

Fedora 恢復模式

解決此問題的唯一方法是找到進入恢復模式的方法。當一切都失敗時，Fedora 提供了一個非常酷的工具：用於安裝 Fedora 新實例的 現場 USB Live 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 設為你的工作目錄：

# cd /mnt/sysimage

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

# mount /dev/mapper/vg01-usr usr

# mount /dev/mapper/vg01-var var

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 配置沒有考慮到這一點。我只是忽略了它們可能不同的事實。

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

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

via: https://opensource.com/article/22/9/recover-linux-system-live-usb

作者：David Both 選題：lkxed 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive