答案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/manjaro
为EFI/BOOT
,然后grubx64.efi
在该目录中重命名为bootx64.efi
。如果您愿意,您可以使用 Manjaro 默认引导加载程序以外的其他东西。请参阅我关于这个主题的页面了解可用信息。 - 您可以使用
fallback.efi
或fbx64.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 失忆”问题的一种方法。.CSV
EFI
第一种方法可能更容易设置,但要注意 GRUB 配置可能比较复杂。如果您grub.cfg
在 ESP 上查找,则必须确保它保留在 GRUB 期望的位置,因此您可能需要或可能不需要移动它。此外,如果您的软件包系统提供了更新的 GRUB,您需要再次复制它才能获得新软件包的好处。第二种方法更难解释,设置起来也更繁琐,但我开始喜欢它,因为它使引导加载程序的更新更容易安装。
还有其他方法可以解决这个问题,比如使用 EFI shell 启动脚本,正如 kyb 建议的那样(但这会导致启动时间比我上面的解决方案更长)。此外,在过去,可以使用 VirtualBox 固件接口本身创建一个新的 NVRAM 条目,并且这将是持久的;但这似乎在某个时候停止了工作——或者至少,上次我尝试的时候,它没有起作用。