我在双启动系统上运行 ubuntu 18.04（kubuntu，但谁在乎呢）。它的 grub 菜单始终能够启动 windows 7，但突然间，grub 中的 windows 条目不再起作用。当我从 grub 菜单中选择 windows 时，屏幕变黑，什么也没发生。如果我反应足够快，我仍然可以直接从系统的启动菜单启动 windows。但我的 grub 设置出了点问题。
我尝试运行“sudo update-grub”，它似乎成功地重新运行了探测，但行为是一样的。
我没有启用安全启动（在我的 BIOS 中甚至没有看到它是一个选项），并且我已确保完全关闭 Windows 7（没有休眠或睡眠模式）。
更多信息：
我还在这台机器上安装了 refind 启动管理器，如果我将其切换为启动顺序中的第一个，它就可以启动 Windows 7 或 grub。但 Refind 菜单显示了多个 ubuntu 条目，它显示的第一个条目启动 EFI/Boot/fbx64.efi，第二个条目启动 EFI/Boot/bootx64.efi。这两个都无法启动 Windows。事实上，当我选择其中一个并从那里启动 ubuntu 时，它会将 ubuntu 重新放到我的 BIOS 启动顺序中的第一位 - 我又回到了开始的地方。
但是，如果我在 Refind 中将箭头指向 /ubuntu/Boot/grubx64.efi 的 ubuntu 条目，那么它不仅能够启动 ubuntu 或 Windows 7，还会让 Refind 位于我的启动顺序的顶部。因此，这个问题似乎是由于新的 efi 模块被放入 /EFI/Boot 并成为默认 grub 加载程序而引起的。我不知道 fbx64 是什么，但它应该是主要的 grub 启动加载程序吗？如果不是，我如何让 grubx64.efi 成为默认的？这是否只是将 grubx64.efi 模块复制到 /EFI/Boot 的问题？这样安全吗 - 我需要将其重命名为 bootx64.efi 以匹配那里的内容吗？
以下是我的 /boot/efi 中的内容（所有 ubuntu 内容的日期似乎都是 9 月 13 日 09:39 - 大概是 ubuntu 最后一次更新 grub）。Bootx64 的大小与 shimx64 相同 - 我不需要 shim 引导加载程序。ubuntu 更新是否错误地将其复制到那里？：
/boot/efi/EFI/Boot
-rwx------ 1 root root 1334816 Sep 13 09:39 bootx64.efi
-rwx------ 1 root root 1213032 Sep 13 09:39 fbx64.efi
/boot/efi/EFI/ubuntu
-rwx------ 1 root root 108 Sep 13 09:39 BOOTX64.CSV
drwx------ 2 root root 1024 Jan 30 2017 fw
-rwx------ 1 root root 71400 May 22 10:48 fwupx64.efi
-rwx------ 1 root root 126 Sep 13 09:39 grub.cfg
-rwx------ 1 root root 1116024 Sep 13 09:39 grubx64.efi
-rwx------ 1 root root 1269496 Sep 13 09:39 mmx64.efi
-rwx------ 1 root root 1334816 Sep 13 09:39 shimx64.efi
答案1
找到答案（或者至少是发生了什么的解释）。当 EFI VRAM 条目损坏时，“后备”EFI 加载程序将使用 BOOTX64.CSV。后备加载程序将 EFI VRAM 条目重新指向 CSV 文件名中作为默认加载程序的任何内容 - 在我的情况下为 shimx64.efi。这就是为什么每当我让 EFI 系统运行虚假的“ubuntu”填充条目时，它都会重新安装在列表的顶部。
我不知道我的 VRAM 是如何损坏以使用后备功能的，但这就是我尝试修复它时它仍然存在的原因。如果您感兴趣，下面的链接描述了这个过程。
答案2
我以前也遇到过类似的问题。我总是需要从 Ubuntu Live USB 启动，安装一个名为 Boot-Repair 的软件包（或者类似的东西，我的记忆力很差），然后使用它来“刷新” GRUB 看到的内容列表。
有关 Boot-Repair 包的更多信息：https://help.ubuntu.com/community/Boot-Repair （请注意，由于它对引导加载程序执行了一些操作，因此您需要以 root 身份才能安装和运行该程序。）
请务必完整阅读上述网页，因为它会比我更好地解释该过程。如果这有帮助，请告诉我。