我有 2 个实例在 AWS 上运行。实例A（主实例）和实例B（救援实例）。
我从实例 A 分离卷并将其附加到实例 B 以执行一些更改，原因是由于 SSH 问题我无法登录实例 A。
对实例 B 进行更改后，PV 和 VG 的 UUID 现在已更改。现在我无法直接将此卷附加回实例 A，因为显然它会失败，因为以前的 UUID 不再存在。如何告诉实例 A 开始使用新的 UUID？
实例 A 中是否有可以直接更新 UUID 的配置文件？
答案1
您可能需要更改该文件/etc/fstab。在这里您可以指定在哪里安装哪个卷。您可以通过执行以下操作查找当前的 uuid lsblk -f。这样您就可以通过 uuid 寻址 LV，并告诉您系统将它们安装在哪里。配置完成后，执行以下/etc/fstab操作mount -a以应用配置。
重要的！/etc/fstab在启动时应用，因此请确保在重新启动之前执行操作时没有任何错误mount -a。否则，您的系统在重新启动时可能会卡住，因为它正在寻找不存在的驱动器。
答案2
LVM UUID
您似乎将其他一些类 UNIX 系统的 LVM 的假设应用到现代（= 内核 2.6.0 或更高版本）Linux LVM。
系统启动时，包含根文件系统的LV未被激活通过UUID， 但按 VG/LV 名称。
在 RHEL 和相关发行版（或者基本上任何用于dracut创建其 initramfs 的发行版）中，您将看到类似这样的内核引导选项rd.lvm.lv=<VGname>/<LVname>- 这是所有 initramfs LVM 工具通常需要查找并激活正确的 LV 来安装根文件系统。 （如果主交换位于 LV 上，通常还有另一个类似的引导选项。）
在 Debian 和相关发行版中，initramfs 中特定于 LVM 的脚本将解析任何root=/dev/mapper/<VGname>-<LVname>或root=/dev/<VGname>/<LVname>启动选项，并尝试查找匹配的 LV，无论它有哪个 UUID。
如果 initramfs 的 LVM 工具恰好找到一个匹配项，则一切正常，并且包含根文件系统的 LV 将被激活。如果它找到多个有效候选者，那么它将检查包含匹配 LV 的 VG 之一是否被标记为出口，如果是这样，它会自动选择非导出的。如果这不能帮助解决冲突，系统将进入 initramfs 紧急模式。
成功挂载真正的根文件系统后，大多数发行版都会执行vgchange -ay或等效的，这通常会导致 LVM 查找并激活所有包含其所有组件的 LV，并大声抱怨任何似乎丢失的 PV。
这些都不需要提前知道 LV/VG/PV UUID。 UUID 仅用于检查发现的 LV/VG/PV 集是否一致。例如，正在使用的每个 PV 将包含 VG 元数据，该元数据将标识同一 VG 的所有其他 PV 的 UUID。
vgchange -ay --activationmode partial如果 VG 丢失了一些 PV，那么即使部分位于这些 PV 上的 LV 也不会自动激活 -如果管理员想要从 VG 恢复数据，则需要使用显式来激活任何丢失部分的 LV。 LV 的剩余部分。
因此，实际上，如果您仅更改了 PV/VG/LV UUID，但保持 PV/VG/LV 名称相同，那么您很可能根本不需要为 LVM 执行任何操作。如果您更改了名称，请检查/etc/fstab内核引导选项。
文件系统 UUID
正如 JadBlackstone 已经回答的那样，如果您更改了任何文件系统UUID，然后您需要编辑/etc/fstab以更改任何UUID=行以匹配相应的新 UUID。
如果您的内核引导选项通过 UUID 指定根文件系统，那么您也必须更改它们。 （但是，如果您在根文件系统上使用 LVM，通常没有理由通过 UUID 引用根文件系统，因为 LVM 已经为您提供了与使用 UUID 在非 LVM 中提供的针对硬件配置更改的基本相同的保护案件。）
如果您正在使用挂起到磁盘/休眠，您应该检查休眠磁盘的配置方式并根据需要进行调整...但通常出现此错误不会阻止系统启动。