我的背景（为了避免XY问题）
我有一个 500GB 的 SSD，可能会失败现在太小了。在进行全面备份后，我将用同一插槽中的 1 TB 驱动器替换它，并将 500GB 移至另一个插槽以备份和不太重要的数据。我将在实时 USB 上使用 Clonezilla 将旧驱动器克隆到新驱动器，但这意味着两个驱动器上的分区将具有相同的 UUID。因此，我将从实时 USB 启动 Kubuntu，并使用 gparted 为旧驱动器上的分区生成新的 UUID。我将安装旧的根分区并进行编辑etc/fstab以将重复的 UUID 更改为新生成的 UUID。
仅供参考，旧驱动器有 4 个分区：nvme0n1p0是/boot/efi、...p1是 Ubuntu 20.04 作为备份（不能有太多）、...p3是 20.04/home和...p4是 Kubuntu 22.04，其中包括一个/home主要与 20.04 符号链接的分区/home。
问题
在同一台 PC 上使用 Clonezilla 复制驱动器、为其中一个驱动器上的分区生成新的 UUID 并更新 后fstab，您仍需要告诉 GRUB 该驱动器上根分区的新 UUID，以便它可以找到/boot。如何安全地做到这一点？
现有问题与答案的研究
有两个问题看上去相似但实际上并不相似，因为 PC 没有相同的、克隆的分区。Clonezilla 之后修复 Grub涉及 PC 之间的传输；使用 clonezilla 镜像恢复 Ubuntu 后如何配置 fstab 和 grub 文件处理恢复分区。
之前最接近的问题问的是将整个 Linux 安装移动到另一个驱动器。答案建议使用 Clonezilla，编辑fstab和更新 GRUB，所以这就是计划，如上所述。但正如托马斯·鲁特放进去其中一条评论, “我觉得这其中 99% 的复杂性都包含在听起来无害的‘将 grub 安装到新驱动器’中。”这个问题更狭义地关注的是 99% 的复杂性，遵循Stack Exchange Meta 上相关问题的最佳答案。
有更多帮助Clonezilla 将 Ubuntu 20.04 安装复制到另一台计算机。唯一的答案解释了如何编辑fstab，但没有解决 GRUB 问题。但是，一条有用的评论指向了之前的一个问题，如何更改 /boot/grub/grub.cfg 中的 UUID。这个从表面上看与这个类似，但有两个显著的区别。
首先，问题假设最好的方法是手动编辑/boot/grub/grub.cfg。但该文件只能由 root 读取，更不用说写入，并且以“请勿编辑此文件”（原文为大写）开头。Ubuntu 的GRUB 文档说“grub.cfg 文件通常不能直接编辑”，并警告“手动编辑可能会被系统覆盖”。这些是 Ubuntu 的警告标志，表示“这里有龙“：编辑此内容应该是最后的手段。因此，这种假设可能是没有根据的，甚至是有害的，而且提问者确实发现他们的编辑被覆盖了。这种假设还意味着这个问题对其他 Ubuntu 用户来说不是最佳选择，因为用户可能直到他们开始走上错误的路时才发现它。其次，接受的答案表示该问题没有准确描述该用户系统的当前状态，从而导致答案出现一些混乱。
用户微软在这些帖子下留言，建议采用完全不同的方法。他们建议不要使用 Clonezilla，而是使用他们编写的 Bash 脚本，该脚本克隆根目录和/home分区，并用于sed编辑fstab和grub.cfg。该脚本是在这个答案中，其中已更新至 20.04 Focal，并且这个 GitHub 存储库。然而，几乎没有证据表明这个脚本经过了良好的测试和维护。最近的一个错误报告报告运行良好，但也有错误报告这引起了人们对这个脚本的关注不是克隆/boot/efi分区，这对于我的用例至关重要，并且脚本的说明在这一点上含糊不清。该错误报告已关闭（由报告者关闭），且说明未更新，这令人担忧。此外，它grub.cfg直接编辑，带来了上述问题。因此，这个问题仅限于与 Clonezilla 的重复。
ioMatrix 的 回答 grub.cfg问题似乎提供了一种更简单的配置 GRUB 的方法。它说将以下行添加到etc/default/grub：
GRUB_DEVICE_UUID=***INSERT NEW UUID HERE***
然后运行sudo update-grub。这看起来很完美！但是，有三个问题。第一个是哪个 /etc/default/grub你应该编辑。如果你用 Clonezilla 复制了一个驱动器，你不应该从任何一个驱动器启动，因为它们具有相同的 UUID，所以你需要从实时系统运行才能生成新的 UUID 并配置 GRUB。如果你在实时系统上应用这个答案，/etc/default/grub复制驱动器上的 保持不变，下次你update-grub使用新的 UUID 在 Ubuntu 系统上运行时，你将丢失更改。所以我认为你至少需要启动实时系统，然后chroot使用新的 UUID 启动根分区。其次，密钥GRUB_DEVICE_UUID根本没有提到GRUB 手册的配置部分也不在任何地方Ubuntu 文档。有几处提到了这一点本网站其他地方，但我对依赖未记录的功能感到不安。第三，答案说“这不会改变搜索的提示条目，但无论如何都不会匹配，所以它应该有效。如果有人想研究改变这一部分的方法，我会很想知道。”我完全不明白这一点，但这表明 ioMatrix 也不完全理解该命令。
即使 GRUB 已使用新的 UUID 更新，也可能会默认启动错误版本的 Ubuntu，但答案在如何更改双启动发行版的顺序。