VirtualBox 找不到要加载的 .efi 文件

VirtualBox 找不到要加载的 .efi 文件

我最近在 VirtualBox 中安装了另一个 Linux 系统。但带有 EFI。这次是 Manjaro Linux,但这并不重要。

问题

VirtualBox EFI 引导加载程序没有看到.efi继续加载操作系统的文件。

EFI壳还有什么?

我的解决方法是从 CD/DVD 启动,然后选择检测 EFI 引导加载程序

但不断使用这样的解决方法并不是一个好方法。

问题

如何修复这种不便的行为 - 如何告诉 VirtualBox EFI 在哪里找到.efi文件引导加载程序。

答案1

尝试以下顺序:

Shell> fs0:
edit startup.nsh
\EFI\Manjaro\grubx64.efi
ctrl-s <cr>
<enter>
ctrl-q <cr>
reset

注释\EFI\Manjaro\grubx64.efi可能因具体系统而异。例​​如\EFI\ubuntu\grubx64.efi

故障排除

如果您收到edit: Access Denied- 卸载所有 CD 和 DVD。那么它应该可以工作。
命令ls可以帮助您了解已安装的内容fs0,并且您可能想要尝试其他fsX:

链接

EFI 启动配置无法持久 在 forums.virtualbox.org 上
如何为 Ubuntu/Linux 操作系统启动 EFI Vbox 主机 在 youtube 上
谢谢大家。

答案2

在正常配置中,EFI 固件会跟踪 NVRAM 中的 EFI 引导加载程序。当您安装操作系统时,它应该向固件注册其引导加载程序,结果是指向引导加载程序的 NVRAM 条目,固件可以启动引导加载程序。这通常可以正常工作,尽管即使在“真实”硬件上也存在 NVRAM 条目被删除或损坏的问题。不幸的是,VirtualBox 在每次使用之间存储其“NVRAM”数据方面做得很差;它倾向于每次启动时都从一组新的默认数据开始。这最终会破坏启动几乎所有东西的能力。

EFI/BOOT/bootx64.efi在我看来,最简单的解决方法是使用后备文件名(不区分大小写)存储引导加载程序EFI 系统分区 (ESP)虚拟磁盘。如果 EFI 无法启动其他任何东西,它将尝试启动此引导加载程序。一般来说,如果您要安装 Linux 发行版,有两种方法可以做到这一点:

  • 您可以在那里存储常规引导加载程序的副本。我不知道 Manjaro 默认使用什么或将其存储在哪里,但假设它使用EFI/manjaro/grubx64.efi,您可以复制或重命名EFI/manjaroEFI/BOOT,然后grubx64.efi在该目录中重命名为bootx64.efi。如果您愿意,您可以使用 Manjaro 默认引导加载程序以外的其他东西。请参阅我关于这个主题的页面了解可用信息。
  • 您可以使用fallback.efifbx64.efi(相同的程序,不同的名称)。此 EFI 程序可能已安装在您的 ESP 上的某个位置,或者至少在您的发行版中的某个软件包中可用(可能是 GRUB 或 Shim)。您将此文件复制到,EFI/BOOT/bootx64.efi然后BOOT.CSV在实际引导加载程序所在的目录中创建一个文件。此文件包含有关实际引导加载程序的名称和相关数据的数据,例如grubx64.efi,Manjaro,,This is the boot entry for Manjaro。重要的是,此文件必须是 UCS-2 或 UTF-16,而不是纯 ASCII。当fallback.efi/fbx64.efi启动(作为)时,它会在 ESP 上的 子目录中bootx64.efi查找文件。如果找到任何文件,它会使用这些文件来生成新的 NVRAM 条目。这旨在帮助恢复丢失的 NVRAM 条目,因此这是解决 VirtualBox“NVRAM 失忆”问题的一种方法。.CSVEFI

第一种方法可能更容易设置,但要注意 GRUB 配置可能比较复杂。如果您grub.cfg在 ESP 上查找,则必须确保它保留在 GRUB 期望的位置,因此您可能需要或可能不需要移动它。此外,如果您的软件包系统提供了更新的 GRUB,您需要再次复制它才能获得新软件包的好处。第二种方法更难解释,设置起来也更繁琐,但我开始喜欢它,因为它使引导加载程序的更新更容易安装。

还有其他方法可以解决这个问题,比如使用 EFI shell 启动脚本,正如 kyb 建议的那样(但这会导致启动时间比我上面的解决方案更长)。此外,在过去,可以使用 VirtualBox 固件接口本身创建一个新的 NVRAM 条目,并且这将是持久的;但这似乎在某个时候停止了工作——或者至少,上次我尝试的时候,它没有起作用。

相关内容