我的家庭实验室中有十几台物理计算机和更多虚拟机。这些系统中的大多数都是我用于测试和实验的。我经常写关于使用自动化来简化系统管理任务的文章。我还在多个地方写道，我从自己的错误中学到的东西比几乎任何其他方式都多。在过去的几周里，我学到了很多东西。我给自己制造了一个大问题。作为多年的系统管理员，写过上百篇关于Linux的文章和五本书，应该对Linux了解更多。再一次，我们都会犯错误，这是一个重要的教训：你永远不会因为有经验而停止犯错。我不打算讨论我的错误的细节。告诉你这是一个错误就足够了，我应该在做之前更多地考虑我在做什么。另外，细节不是重点。经验并不能使你免于犯下的每一个错误，但它可以帮助你改过自新。这就是本文的主题：使用实时USB发行版启动进入恢复模式。问题首先，问题是我造成的，它本质上是/etc/default/grub文件配置错误。接下来，我使用Ansible将错误配置的文件分发到我所有的物理机器并运行grub2-mkconfig。全部12个。它真的非常非常快。除了两个以外，其他人都未能启动。它们在Linux引导的早期阶段崩溃，出现各种无法定位/root文件系统的错误。我可以使用root密码进??入“维护”模式，但没有挂载/root，即使是最简单的工具也无法访问。直接引导到恢复内核也不起作用。系统真的崩溃了。Fedora恢复模式解决这个问题的唯一方法是想办法进入恢复模式。当所有其他方法都失败时，Fedora提供了一个非常酷的工具：用于安装Fedora新实例的实时USBLiveUSB驱动器。将BIOS设置为从实时USB设备启动后，我启动到Fedora36Xfce的实时用户桌面。我在桌面上打开了两个相邻的终端会话，并在两个终端会话中都切换到了root权限。我在其中一个上运行lsblk以供参考。我使用结果来识别/root分区以及boot和efi分区。我使用了我的一个虚拟机，如下所示。在这种情况下，没有efi分区，因为此VM不使用UEFI。#lsblkNAMEMAJ:MINRMSIZEROTYPEMOUNTPOINTSloop07:001.5G1looploop17:106G1loop├─live-rw253:006G0dm/└─live-base253:106G1dmloop27:2032G0loop└─live-rw253:006G0dm/sda8:00120G0disk├─sda18:101G0part└─sda28:20119G0part├─vg01-swap253:204G0lvm├─vg01-tmp253:3010G0lvm├─vg01-var253:4020G0lvm├─vg01-home253:505G0lvm├─vg01-usr253:6020G0lvm└─vg01-root253:705G0lvmsr011:011.6G0rom/run/initramfs/livezram0252:008G0disk[SWAP]/dev/sda1分区很容易识别为/boot，根(/)分区也是如此。在另一个终端会话中，我执行了一系列步骤来恢复我的系统。特定的卷组名称和设备分区（例如/dev/sda1）因系统而异。此处显示的命令特定于我的情况。目标是使用liveUSB启动并完成启动，然后只在镜像目录中挂载必要的文件系统，并运行chroot命令以在chroot镜像目录中运行Linux。此方法绕过损坏的GRUB（或其他）配置文件。但是，它提供了一个完整的运行系统，其中安装了所有原始文件系统以进行恢复，既作为所需工具的来源，又作为要进行更改的目标。以下是步骤和相关命令：创建目录/mnt/sysimage以提供chroot目录的位置。将根分区挂载到/mnt/sysimage：#mount/dev/mapper/vg01-root/mnt/sysimage将/mnt/sysimage设置为您的工作目录：#cd/mnt/sysimage挂载/boot和/boot/efi文件系统.挂载其他主文件系统。此步骤不需要像/home和/tmp这样的文件系统：#mount/dev/mapper/vg01-usrusr#mount/dev/mapper/vg01-varvarbindingsarehung必须挂载的重要文件系统必须在chroot之间共享system和原来的live系统，而后者还在外部运行：#mount--bind/syssys#mount--bind/procproc必须在last/dev目录下，否则无法挂载其他文件系统：#mount--bind/devdevchroottothesystemimage:#chroot/mnt/sysimage系统现在已经准备好了，无论你需要做什么，你都可以把它恢复到工作状态。然而，有一次我能够在这种状态下运行我的服务器几天，直到我能够研究和测试真正的修复。我不推荐这样做，但是当有任务需要启动和运行时，它可能是紧要关头的一个选择。解决方案当我将每个系统置于恢复模式时，修复很容易。由于我的系统现在像成功启动一样工作，我只需对/etc/default/grub和/etc/fstab进行必要的更改并运行grub2-mkconfig>boot/grub2/grub.cfg命令。我使用exit命令退出chroot环境并重新启动主机。当然，我不能自动从事故中恢复过来。我不得不在每台主机上手动完成整个过程，这是对使用自动化快速轻松地传播我自己的错误的一种报应。吸取教训尽管它们很有用，但我曾经讨厌在我的一些系统管理员工作中召开“吸取教训”会议，但看起来我确实需要提醒自己一些事情。因此，这是我从这场自我造成的惨败中得到的“教训”。首先，十个无法启动的系统使用了不同的卷组命名方案，我的新GRUB配置没有考虑到这一点。我只是忽略了它们可能不同的事实。考虑清楚。并非所有系统都相同。测试一切。验证一切。永远不要做假设。现在一切正常。希望我也更聪明。
