在尝试恢复我的 ec2 实例时，我注意到如果不使用以下命令生成新的 UUID，则无法将该实例的根卷挂载到其他机器上
xfs_admin -U generate /dev/xdfg。
（这是因为系统说由于 UUID 重复而无法安装驱动器，我仍然不知道为什么会这样说）
这使我可以访问该卷。但是，当尝试将其重新挂载并在原始 ec2 实例上启动时，启动失败并产生错误
unknown filesystem并提示使用 grub rescue。
为了解决这个问题，我将驱动器重新安装到辅助机器上，并将其 UUID 改回原来的状态，幸运的是我的控制台历史记录中有它。
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
这使我能够重新启动机器。
问题
那么，出于好奇，UUID 的哪些方面会阻止系统启动？当使用两个 UUID 安装在单独的机器上时，系统知道文件系统是xfs。
答案1
虽然问题的一部分已经在这里得到回答：https://unix.stackexchange.com/questions/137862/why-does-fstab-use-uuid-instead-of-the-actual-file-system-name
我将尝试提供另一种解释。目前，您正在使用 UUID 通过 fstab 挂载根文件系统。这有一个优点，即在添加硬件时，您始终引用同一磁盘。更改启动盘时，请确保更改 fstab 中的 UUID。使用blkid命令获取新磁盘 UUID。当您将两个磁盘连接到同一个系统时，这相当容易，获取新的 UUID 并在 fstab 中更改 UUID，并且在删除旧磁盘之前，您需要将根文件系统复制到新磁盘。
您可以使用另一种方式，而无需在 fstab 中指定 UUID。例如，您需要引用 /dev/sda 并在 fstab 中指定文件系统。当您连接第二个驱动器并且系统将根磁盘的 /dev/sda 更改为 /dev/sdb 时，您可能会失败。这就是 UUID 派上用场的地方。
嵌入式系统以及其他一些系统可能在自己的分区上将启动目录与 /etc/fstab 一起保存，因此当您在启动时提供错误的 UUID 并且系统找不到它时，系统将无法启动。
因此，在更改磁盘之前，您需要检查启动分区布局、fstab 位置和启动时安装的设备。