VirtualBox cannot find .efi file to load

Question

I have recently installed yet another Linux system into VirtualBox. But with EFI. This time it was Manjaro Linux, but this does not really matter.

The problem

VirtualBox EFI bootloader does not see .efi files to continue loading OS.

My workaround was to boot from CD/DVD and then select Detect EFI bootloaders

But using such workaround constantly is not a good way.

The question

How to fix such inconvenient behavior - how to tell VirtualBox EFI where to find .efi files-bootloaders.

Solution 1

Try this sequence:

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

Note \EFI\Manjaro\grubx64.efi can differ depending on concrete system. E.g. \EFI\ubuntu\grubx64.efi

Troubleshooting

If you receive edit: Access Denied - unmount all CDs and DVDs. Than it should work.
Command ls can help to understand what is mounted as fs0, and may be you will want to try other fsX:.

Links

EFI boot configuration cannot be persistent on forums.virtualbox.org
How to Start EFI Vbox host for Ubuntu/ Linux OS on youtube
Thank you guys.

Solution 2

In a normal configuration, EFI firmware keeps track of EFI boot loaders in NVRAM. When you install an OS, it's supposed to register its boot loader with the firmware, and the result is an NVRAM entry that points to the boot loader, and the firmware can launch the boot loader. This normally works OK, although there are problems with NVRAM entries being erased or becoming damaged even on "real" hardware. VirtualBox, unfortunately, does a poor job of storing its "NVRAM" data between uses; it tends to start out with a fresh set of default data every time you launch it. This ends up wreaking havoc with the ability to launch just about anything.

IMHO, the simplest workaround is to store a boot loader using the fallback filename of EFI/BOOT/bootx64.efi (case-insensitive) on the EFI System Partition (ESP) of the virtualized disk. If an EFI can't boot anything else, it will try to boot this boot loader. Broadly speaking, if you're installing a Linux distribution, there are two ways to do this:

• You can store a copy of your regular boot loader there. I don't know what Manjaro uses by default or where it stores it, but supposing it uses EFI/manjaro/grubx64.efi, you'd copy or rename EFI/manjaro to EFI/BOOT and then rename grubx64.efi in that directory to bootx64.efi. You could use something other than Manjaro's default boot loader, if you prefer. See my page on the subject for information on what's available.
• You can use fallback.efi or fbx64.efi (the same program, different names). This EFI program is likely either installed somewhere on your ESP already or at least available in some package in your distribution (maybe GRUB or Shim). You'd copy this file to EFI/BOOT/bootx64.efi and then create a BOOT.CSV file in the directory where the real boot loader exists. This file holds data on the real boot loader's name and related data, such as grubx64.efi,Manjaro,,This is the boot entry for Manjaro. Importantly, this file must be UCS-2 or UTF-16, not plain ASCII. When fallback.efi/fbx64.efi launches (as bootx64.efi), it looks for .CSV files in the subdirectories of EFI on the ESP. If it finds any, it uses them to generate new NVRAM entries. This is intended to help with the recovery of lost NVRAM entries, so it's one way to work around the VirtualBox "NVRAM amnesia" problem.

The first approach is likely to be easier to set up, with the caveat the GRUB configurations can be finicky. If yours looks for grub.cfg on the ESP, you must be sure it remains where GRUB expects it, so you might or might not need to move it. Also, if your package system delivers an updated GRUB, you'll need to copy it again to get the benefits of the new package. The second approach is harder to explain and a bit more tedious to set up, but I'm starting to prefer it because it makes updates to the boot loader easier to install.

There are other approaches to working around the problem, too, like using an EFI shell startup script, as kyb suggests (but this will result in longer startup times than my solution above). Also, in the past, it was possible to create a new NVRAM entry using the VirtualBox firmware interface itself, and this would be persistent; but this seems to have stopped working at some point -- or at least, the last time I tried it, it didn't work.

Comments

[nomadSK25]

I am getting 'edit:Access Denied' issue and if unmount all the CDs/ DVDs then it is not showing any FS

[kyb]

Did you try to type fs0: or fs1:?