Fedora Live USB发行版为启动和进入恢复模式提供了一个有效的解决方案。
我的家庭实验室里有十几台物理电脑，还有更多的虚拟机。我使用这些系统中的大部分来进行测试和实验。我经常写关于使用自动化来使系统管理员的任务更容易。我也曾在多个地方写过，我从自己的错误中学习到的东西几乎比其他任何方式都要多。
在过去的几周里，我学到了很多。
我给自己制造了一个大问题。我做了多年的系统管理员，写了数百篇关于Linux的文章和五本书，我真的应该知道的更多。然后，我们都会犯错，这是一个重要的教训：你永远不会太有经验，不会犯错。
我不打算讨论我的错误的细节。只要告诉你这是一个错误，而且我在做之前应该对我所做的事情多加考虑就够了。此外，这些细节并不是真正的重点。经验不能把你从你要犯的每个错误中拯救出来，但它可以帮助你恢复。而这正是本文的内容。使用Live USB发行版来启动和进入恢复模式。
问题
首先，我创造了一个问题，基本上是/etc/default/grub 文件的一个错误配置。接下来，我使用Ansible将配置错误的文件分发到我所有的物理计算机上，并运行grub2-mkconfig 。所有的12台电脑。真的，真的很快。
除了两台之外，其他的都没能启动。它们在Linux启动的早期阶段崩溃了，出现了各种错误，表明无法找到/root 文件系统。
我可以使用根密码进入 "维护 "模式，但如果没有安装/root ，就不可能访问甚至最简单的工具。直接启动到恢复内核也不起作用。这些系统真的坏了。
Fedora的恢复模式
解决这个问题的唯一方法是找到一个进入恢复模式的方法。当所有其他方法都失败时，Fedora提供了一个非常酷的工具。用来安装Fedora新实例的同一个Live USB优盘。
在将BIOS设置为从Live USB设备启动后，我启动了Fedora 36 Xfce实时用户桌面。我在桌面上打开了两个相邻的终端会话，并在两个终端中切换到root权限。
我在其中一个中运行了lsblk 以供参考。我使用结果来确定/ 根分区以及boot 和efi 分区。我使用了我的一个虚拟机，如下图所示。在这种情况下没有efi 分区，因为这个虚拟机没有使用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 命令，在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系统和原来的Live系统之间共享，后者仍然在那里运行。
# mount --bind /sys sys
# mount --bind /proc proc
7.确保最后完成/dev 目录，否则其他文件系统将无法安装。
# mount --bind /dev dev
8.将系统镜像转根。
# chroot /mnt/sysimage
现在系统已经准备好了，无论你需要做什么，都可以把它恢复到工作状态。然而，有一次我能够在这种状态下运行我的服务器好几天，直到我能够研究和测试真正的修复措施。我并不推荐这样做，但在紧急情况下，当事情需要启动和运行时，这可能是一个选择，现在就可以了！"。
解决方案
一旦我把每个系统都进入恢复模式，修复就很容易了。因为我的系统现在就像成功启动一样工作，我只需对/etc/default/grub 和/etc/fstab 进行必要的修改，然后运行grub2-mkconfig > boot/grub2/grub.cfg 命令。我使用exit 命令退出chroot，然后重新启动了主机。
当然，我不能自动地从我的错误中恢复。我不得不在每台主机上手动执行整个过程--这是对我使用自动化来快速、轻松地传播自己的错误的恰当报应。
学到的教训
尽管它们很有用，我以前很讨厌在我的一些系统管理员工作中的 "经验教训 "会议，但现在看来我确实需要提醒自己一些事情。因此，这里是我从这场自作自受的惨败中获得的 "教训"。
首先，那十个无法启动的系统使用了不同的卷组命名方案，而我的新GRUB配置没有考虑到这一点。我只是忽略了他们可能是不同的事实。
- 完全想清楚了。
- 不是所有的系统都是一样的。
- 测试一切。
- 验证一切。
- 永远不要做假设。
