Grub 在自然启动时冻结，但从 EFI 菜单中选择时可以工作

Question 1

不幸的是，Boot Repair 不能正确处理 NVMe 磁盘，因此 BootInfo 报告中缺少大量重要信息；但是，它确实ubuntu在 NVRAM 启动管理器列表中显示了一个条目，因此系统不太可能通过其他路径启动——除了您有一个后备引导加载程序 ( EFI/BOOT/bootx64.efi)，从该目录中的另一个文件 ( fbx64.efi) 来看，它可能是在固件发生故障时恢复引导设置的工具。此工具及其配置和使用方法在我的 rEFInd 文档中进行了描述（尽管它不是 rEFInd 的一部分；该页面只是fbx64.efi我所知道的最完整和最简洁的描述）：

http://www.rodsbooks.com/refind/bootcoup.html#fallback

您的计算机可能丢失了其启动顺序变量，通过 Shim（作为EFI/BOOT/bootx64.efi）和进行启动fbx64.efi，然后将启动过程转移到常规ubuntu条目（启动一个第二如果您在启动时先启动 Shim，然后启动 GRUB），然后 Shim 会挂起；但是当ubuntu直接启动该条目时，它可以正常工作。这可能是因为启动了两个 Shim 副本时存在错误，因为fbx64.efi它本身导致了问题，或者由于其他原因。这个假设只是推测，它基于很少的证据和相当多的假设。它还假设您的固件存在错误，并且很可能在 Shim、fbx64.efi和/或 GRUB 中也存在错误。但是，这与您看到的症状一致，而且这也是您唯一能想到的解释。如果发生了这种情况，您可以尝试以下诊断程序或修复问题：

重命名EFI/BOOTESP 上的目录-- 如果您重命名此目录，问题仍然如旧，那么我的假设就是错误的。（这是因为重命名EFI/BOOT将阻止计算机尝试启动fbx64.efi存储在该目录中的 Shim；因此如果它继续启动，则一定是启动顺序和启动变量被保留并遵守，这与我的假设相反。）但是，如果计算机开始正确启动，或直接启动到 Windows，则这证明它一直以这种方式启动，我的假设就更有可能成立。您应该能够将目录重命名为以EFI/BOOT恢复（失败的）启动操作，这对于接下来的三次修复是必要的......
禁用安全启动-- 禁用安全启动将改变 Shim 的工作方式，如果我的假设正确的话，这可能让一切正常运转——否则可能没有任何效果。即使我的假设是正确的，这种改变也只有在故障是由安全启动导致的情况下才会起作用，而事实可能并非如此。
复制EFI/ubuntu/grub*到EFI/BOOT-- 如果您将 GRUB ( grubx64.efi) 及其配置文件 ( grub.cfg) 从EFI/ubuntu复制到EFI/BOOT，则 Shim in EFI/BOOT(即EFI/BOOT/bootx64.efi) 应直接从启动 GRUB EFI/BOOT，而不必通过fbx64.efi。如果我的假设正确，这应该可以绕过该问题。
使用 rEFInd- 我的rEFInd 启动管理器启动方式与 GRUB 完全不同，因此可能不会受到此问题的影响。但是，在安全启动处于活动状态的情况下，您需要在 MOK 列表中注册一个或两个密钥，如rEFInd 安全启动文档。此外，您可能需要删除或重命名EFI/ubuntu/BOOTX64.CSVESP 上的文件。（将其重命名为不以结尾的文件名.CSV，或任何大小写变体，如.csv。）原因是fbx64.efi查找.CSV文件以重新生成基于 NVRAM 的启动项，因此如果该文件存在，则有 50/50 的机会它会优先于BOOT.CSVrEFInd 为自己创建的文件，从而导致系统启动到 GRUB 并继续以您描述的方式失败。
更新固件-- 如果您的制造商提供了比您现在使用的固件更新的固件（可能称为“BIOS”），您可以升级它。不过，这只是瞎猜；您的问题听起来很奇怪，不太可能在固件更新中得到解决。

我建议您尝试将第一个选项作为诊断。如果启动行为如我所述发生变化，则可以恢复到原来的EFI/BOOT状态，然后尝试接下来的三个选项中的任何一个——或者如果第一次尝试失败，则尝试多个选项。另一方面，如果重命名EFI/BOOT没有效果，那么接下来的两个选项不太可能起作用（尽管禁用安全启动可能会有所帮助）。在这种情况下，安装 rEFInd 成为最有可能起作用的选项，但这真的是盲目的尝试。即使第一个诊断选项不会改变行为，更新固件也可能有效，但正如我所说，这是一个绝望的选择，无论原因是什么都不太可能起作用。尽管如此，如果您没有其他选择，还是值得尝试的（或者即使您有其他选择——固件更新可以修复各种问题、添加功能并提高性能）。

祝你好运解决问题！

Answer

不幸的是，Boot Repair 不能正确处理 NVMe 磁盘，因此 BootInfo 报告中缺少大量重要信息；但是，它确实ubuntu在 NVRAM 启动管理器列表中显示了一个条目，因此系统不太可能通过其他路径启动——除了您有一个后备引导加载程序 ( EFI/BOOT/bootx64.efi)，从该目录中的另一个文件 ( fbx64.efi) 来看，它可能是在固件发生故障时恢复引导设置的工具。此工具及其配置和使用方法在我的 rEFInd 文档中进行了描述（尽管它不是 rEFInd 的一部分；该页面只是fbx64.efi我所知道的最完整和最简洁的描述）：

http://www.rodsbooks.com/refind/bootcoup.html#fallback

您的计算机可能丢失了其启动顺序变量，通过 Shim（作为EFI/BOOT/bootx64.efi）和进行启动fbx64.efi，然后将启动过程转移到常规ubuntu条目（启动一个第二如果您在启动时先启动 Shim，然后启动 GRUB），然后 Shim 会挂起；但是当ubuntu直接启动该条目时，它可以正常工作。这可能是因为启动了两个 Shim 副本时存在错误，因为fbx64.efi它本身导致了问题，或者由于其他原因。这个假设只是推测，它基于很少的证据和相当多的假设。它还假设您的固件存在错误，并且很可能在 Shim、fbx64.efi和/或 GRUB 中也存在错误。但是，这与您看到的症状一致，而且这也是您唯一能想到的解释。如果发生了这种情况，您可以尝试以下诊断程序或修复问题：

重命名EFI/BOOTESP 上的目录-- 如果您重命名此目录，问题仍然如旧，那么我的假设就是错误的。（这是因为重命名EFI/BOOT将阻止计算机尝试启动fbx64.efi存储在该目录中的 Shim；因此如果它继续启动，则一定是启动顺序和启动变量被保留并遵守，这与我的假设相反。）但是，如果计算机开始正确启动，或直接启动到 Windows，则这证明它一直以这种方式启动，我的假设就更有可能成立。您应该能够将目录重命名为以EFI/BOOT恢复（失败的）启动操作，这对于接下来的三次修复是必要的......
禁用安全启动-- 禁用安全启动将改变 Shim 的工作方式，如果我的假设正确的话，这可能让一切正常运转——否则可能没有任何效果。即使我的假设是正确的，这种改变也只有在故障是由安全启动导致的情况下才会起作用，而事实可能并非如此。
复制EFI/ubuntu/grub*到EFI/BOOT-- 如果您将 GRUB ( grubx64.efi) 及其配置文件 ( grub.cfg) 从EFI/ubuntu复制到EFI/BOOT，则 Shim in EFI/BOOT(即EFI/BOOT/bootx64.efi) 应直接从启动 GRUB EFI/BOOT，而不必通过fbx64.efi。如果我的假设正确，这应该可以绕过该问题。
使用 rEFInd- 我的rEFInd 启动管理器启动方式与 GRUB 完全不同，因此可能不会受到此问题的影响。但是，在安全启动处于活动状态的情况下，您需要在 MOK 列表中注册一个或两个密钥，如rEFInd 安全启动文档。此外，您可能需要删除或重命名EFI/ubuntu/BOOTX64.CSVESP 上的文件。（将其重命名为不以结尾的文件名.CSV，或任何大小写变体，如.csv。）原因是fbx64.efi查找.CSV文件以重新生成基于 NVRAM 的启动项，因此如果该文件存在，则有 50/50 的机会它会优先于BOOT.CSVrEFInd 为自己创建的文件，从而导致系统启动到 GRUB 并继续以您描述的方式失败。
更新固件-- 如果您的制造商提供了比您现在使用的固件更新的固件（可能称为“BIOS”），您可以升级它。不过，这只是瞎猜；您的问题听起来很奇怪，不太可能在固件更新中得到解决。

我建议您尝试将第一个选项作为诊断。如果启动行为如我所述发生变化，则可以恢复到原来的EFI/BOOT状态，然后尝试接下来的三个选项中的任何一个——或者如果第一次尝试失败，则尝试多个选项。另一方面，如果重命名EFI/BOOT没有效果，那么接下来的两个选项不太可能起作用（尽管禁用安全启动可能会有所帮助）。在这种情况下，安装 rEFInd 成为最有可能起作用的选项，但这真的是盲目的尝试。即使第一个诊断选项不会改变行为，更新固件也可能有效，但正如我所说，这是一个绝望的选择，无论原因是什么都不太可能起作用。尽管如此，如果您没有其他选择，还是值得尝试的（或者即使您有其他选择——固件更新可以修复各种问题、添加功能并提高性能）。

祝你好运解决问题！

Question 2

问题似乎是多个 GRUB 安装不匹配。安装在 /EFI/ubuntu/grubx64.efi 的 GRUB 不起作用，而安装在 /EFI/Boot/bootx64.efi 的 GRUB 起作用。

您应该能够通过将 GRUB 重新安装到 ESP 来纠正此问题。

sudo grub-install --efi-directory=/boot/efi /dev/sda

Answer

问题似乎是多个 GRUB 安装不匹配。安装在 /EFI/ubuntu/grubx64.efi 的 GRUB 不起作用，而安装在 /EFI/Boot/bootx64.efi 的 GRUB 起作用。

您应该能够通过将 GRUB 重新安装到 ESP 来纠正此问题。

sudo grub-install --efi-directory=/boot/efi /dev/sda

Question 3

我在完全相同的硬件型号上遇到了完全相同的问题。正如原始发帖者所说，应用更新后问题消失。不幸的是，问题再次出现。解决方法是按照此页面上的说明禁用安全启动：https://support.hp.com/us-en/document/c04784866

Answer

我在完全相同的硬件型号上遇到了完全相同的问题。正如原始发帖者所说，应用更新后问题消失。不幸的是，问题再次出现。解决方法是按照此页面上的说明禁用安全启动：https://support.hp.com/us-en/document/c04784866

Grub 在自然启动时冻结，但从 EFI 菜单中选择时可以工作

答案1

答案2

答案3

相关内容