如何使用 Live USB 设备恢复 Linux 系统

Fedora Live USB 发行版提供了一个有效的解决方案来启动并进入恢复模式。

图片来源：

我在我的家庭实验室里有十几个物理计算机，甚至还有更多的虚拟机。我使用这些系统中的大多数进行测试和实验。我经常写关于使用自动化来简化系统管理员任务的文章。我也在很多地方写过，我从自己的错误中学到的东西比从其他任何方式学到的都多。

在过去的几周里，我学到了很多东西。

我给自己制造了一个大问题。作为一个从事系统管理多年，撰写了数百篇文章和五本关于 Linux 的书籍的人，我真的应该知道得更多。但话说回来，我们都会犯错误，这是一个重要的教训：你永远不会因为经验丰富而不会犯错。

我不打算讨论我的错误的细节。告诉你这是一个错误，并且在做之前我应该对我在做什么进行更多的思考就足够了。此外，细节并不是重点。经验不能让你避免每一个你会犯的错误，但它可以帮助你恢复。而这正是本文的主题：使用 Live USB 发行版来启动并进入恢复模式。

问题

首先，我制造了问题，这本质上是 /etc/default/grub 文件的错误配置。接下来，我使用 Ansible 将错误配置的文件分发到我的所有物理计算机并运行 grub2-mkconfig。所有 12 台。非常非常快。

除了两台之外，所有机器都无法启动。它们在 Linux 启动的早期阶段崩溃，出现各种错误，表明无法找到 /root 文件系统。

我可以使用 root 密码进入“维护”模式，但如果没有挂载 /root，甚至无法访问最简单的工具。直接启动到恢复内核也无效。这些系统真的坏了。

更多 Linux 资源

使用 Fedora 的恢复模式

解决这个问题的唯一方法是找到进入恢复模式的方法。在其他方法都失败时，Fedora 提供了一个非常酷的工具：用于安装 Fedora 新实例的同一个 Live USB 拇指驱动器。

将 BIOS 设置为从 Live 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）将有所不同。此处显示的命令特定于我的情况。

目标是使用 Live USB 启动并完成启动，然后在映像目录中仅挂载必要的文件系统，并运行 chroot 命令以在 chrooted 映像目录中运行 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. 挂载重要但已挂载的文件系统，这些文件系统必须在 chrooted 系统和原始 Live 系统（仍在运行）之间共享

# 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 退出，然后重新启动主机。

当然，我无法自动化从我的错误中恢复。我不得不手动在每台主机上执行整个过程——这是对我使用自动化快速轻松地传播我自己的错误的恰当的因果报应。