我有一个可以正常工作的 Legacy/UEFI 启动棒，上面有 Xubuntu focal。一切正常。现在我正在创建克隆，为此，我在每个克隆上都做了一些更改：
- 主机名
- 分区的 UUID
- /etc/fstab 中列出的这些分区的 UUID。
这些棒子无法启动，因为 GRUB 中的 UUID 没有改变，而且我对 GRUB 记录它们的方式感到相当困惑，并且认为自己更新它们太容易出错了，不值得尝试。
因此，既然我可以在正在运行的系统上安装这些存储棒，我想将 chroot 到存储棒中并在 chroot 进程中运行 update-grub。我看到的示例不允许进程访问设备等，我不知道如何正确设置。我猜我想在 chroot 中访问至少 /dev 和可能 /sys 和/proc。这三个在原始进程中都是“假的”，不是任何驱动器上文件系统的一部分。
有什么建议吗？有没有其他方法可以让这些克隆启动？
有人知道当 GRUB 进入紧急模式时如何让它启动吗？
答案1
嗯。我想我在这个链接里找到了答案：https://docs.rackspace.com/support/how-to/mount-a-partition-and-chroot-into-your-primary-file-system-from-rescue-mode/
它似乎专注于特定类型的服务器集群的细节，但基本功能看起来可用。如果它有效，我会报告。
后来：是的！经过一些调整，忽略不适用的内容，它就起作用了。
简而言之：如果 /etc/hostname 和 /etc/fstab 按照应有的方式设置，（对我来说，这意味着 /etc/fstab 使用 UUID 来识别驱动器，并且它们是准确的）那么这应该可以工作：
确保已完成所有必要的挂载。在我的例子中，这意味着将根分区挂载在 /mnt 上，将启动分区挂载在 /mnt/boot 上。
在 root shell 中输入代码
mount --types proc none /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev
chroot /mnt /bin/bash并且您应该处于 chroot 环境中。您可以通过将 hostname 的输出与 /etc/hostname 的内容进行比较来轻松检查。
我在 chroot 中执行的关键操作是“update-grub”，它将所有正确的 UUID 都放到了设备上。然后我立即退出 chroot，不必担心如何撤消挂载命令，只需重新启动并选择新驱动器即可。一切顺利。
另一件事是在没有任何其他驱动器的情况下运行该驱动器（我只是断开了其他驱动器的电源并执行了“partprobe”）并以这种方式运行“update-grub”以获得干净的启动菜单，而没有我用于所有这些的系统的痕迹。
答案2
我还发现了一个可能更好的解决方案。它解决了另一个驱动器上的问题，由于某种原因，该驱动器无法运行 update-grub，甚至无法从另一个驱动器运行 grub-install。
更改分区的 UUID 并更正 /etc/fstab 以适应这些更改后，我启动了一个具有 GRUB 启动救援功能的 U 盘。瞧，它识别了驱动器，并很快重建了可用的 grub 配置。此后驱动器启动正常。