我花了 6 个小时才解决这个问题，然后就放弃了。我找不到恢复被相同 /boot 分区覆盖的 /boot 分区的方法。这不是您通常遇到的 grub 安装问题。这简直是地狱。
我有 2 个系统，A 和 B。这两个系统除了 UUID 和几个特定于各自系统的文件（例如 fstab、crypttab 等）外，其他方面都完全相同。B 是 A 的备份，两个系统都能够在某个时刻成功启动。
现在，B 的 /boot 被 A 100% 覆盖，B 拒绝启动，我已经尝试了所有能想到的可行的办法（但都没有用）。
我已将 /dev/ /dev/pts/ /sys/ /proc/ --bind 挂载到 chrooted 环境并进入 chrooted 环境，然后更新 grub、清除 grub、重新安装 grub、删除内核、更新内核、运行 update-initramfs -k all -c 以及其他选项，并以各种顺序执行其他操作，甚至从头开始。我已使用 --directory 选项从主机运行 grub-update，甚至还求助于 boot-repair，实际上我在 6 小时内可能已经执行了 100 次。
没有什么能够使系统恢复正常运行。
我知道这应该更简单，但我就是运气太差了。我做错了什么？两个系统都使用安装时的全盘加密进行加密。
更新它出现在启动过程中，我应该被提示输入密码来解锁 / 系统挂起，然后进入 initramfs 提示符。我不知道如何解锁 cryptsetup 磁盘，也没有帮助。我没有 initramfs 中的 cryptsetup :/
答案1
我希望这对遇到同样情况的人有所帮助。事实证明，经过 8 多个小时的尝试后，我休息了一下，然后回来在 30 分钟内解决了问题。事实证明，我每次都能找到答案。
在主机系统中，当我安装加密磁盘进行备份时，我执行以下操作
sudo cryptsetup luksOpen /dev/sdd5 kub # a sneaky kind of wrong
事实证明，“kub”这个名字把一切都搞砸了。它应该叫什么名字？为什么我总是使用 kub？名称应该是 /etc/crypttab 中的加密磁盘名称。我总是使用“kub”，因为它总能满足我的需要，但事实证明，不是在 chrooted 系统上使用 update-initramfs 并尝试在其上更新 grub 时。我的 /etc/crypttab 中的正确名称原来是 sdc5_crypt，因此
sudo cryptsetup luksOpen /dev/sdd5 sdc5_crypt # wow, the answer
然后解锁磁盘后正确地并进行相关的挂载（/dev/ /sys/ /run/ /dev/pts/ /proc/）我运行了以下命令
sudo update-initramfs -k all -c
sudo update-grub
然后系统就可以启动了。哇哦，“kub”就像是叫某人叫杰克·鲍比，而杰克从来不会费心去纠正你，所以你以为自己是对的，但结果杰克却因此而恨你。