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/BOOTand then rename
grubx64.efiin 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
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.efiand then create a
BOOT.CSVfile 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
bootx64.efi), it looks for
.CSVfiles in the subdirectories of
EFIon 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.