EFI VMs fail to boot

[Nicolas]

Hi,

I juste upgraded to 6.1, and EFI VMs now refuse to boot with the following error:

00:00:00.653540 VMSetError: F:\tinderbox\win-rel\src\VBox\Devices\EFI\DevEFI.cpp(2521) int __cdecl efiConstruct(struct PDMDEVINSR3 *,int,struct CFGMNODE *); rc=VERR_PDM_CFG_MISSING_DRIVER_NAME
00:00:00.653559 VMSetError: Can't attach Nvram Storage driver
00:00:00.653573 PDM: Failed to construct 'efi'/0! VERR_PDM_CFG_MISSING_DRIVER_NAME (-2822) - The attached driver configuration is missing the 'Driver' attribute.
00:00:00.654175 GIM: KVM: Resetting MSRs
00:00:00.938051 ERROR [COM]: aRC=E_FAIL (0x80004005) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Can't attach Nvram Storage driver (VERR_PDM_CFG_MISSING_DRIVER_NAME)}, preserve=false aResultDetail=-2822
00:00:00.938267 Console: Machine state changed to 'PoweredOff'
00:00:00.957749 Power up failed (vrc=VERR_PDM_CFG_MISSING_DRIVER_NAME, rc=E_FAIL (0X80004005))

BIOS VMs seem to work just fine.

Cheers, Nicolas

[Captain Crunch]

I second this ticket!

I was about to report a new bug. My existing MacOS VMs from "El Capitan" to "Catalina" that ran under VB 6.0.14 no longer boot. "Mavericks" and older still boot. Seeing this bug, I double checked "System > Enable EFI" and it matches this ticket. I have "El Capitan" and newer using EFI.

How do you do a release that breaks all EFI machines?

Can we add some additional machine configuration to get this working?

[Captain Crunch]

I've got a workaround for my problem. It's obviously not a "fix". Not sure if it will help the OP.

It looks like the EFI rom got changed in this release. Actually, it's completely gone from the VB installation directory! Could that be the problem? The EFI rom not getting installed? or is it packed into another file?

In any event, my workaround is to point your VM at the version of the EFI rom from VB 6.0.14. In VB 6.0.14, there should be a file VBoxEFI64.dll in your installation directory. You did back it up right? Copy it from your backup disk to somewhere on your machine, and then update your vbox definition file by adding something like this:

<ExtraData>
    <ExtraDataItem name="VBoxInternal/Devices/efi/0/Config/EfiRom" value="C:/temp/VBoxEfi64.fd"/> 
</ExtraData>

[Captain Crunch]

It looks like my problems were due to outdated Clover (boot manager) EFI drivers. Apparently, these were not compatible with the newer EFI rom bundled with 6.1.0. If I boot directly through the VirtualBox UEFI/firmware, then there are no issues.

To the OP, I initially thought we had the same issue, but looks like not. However, you got bumped several times by my updates, so this ticket should be still near the top!

[Nicolas]

Hi,

More info: I'm trying to boot a Debian x64 (not OSX ;) )

[Nicolas]

Hi Again,

I fixed it by removing all nvram storage related extra data (VBoxInternal/Devices/efi/0/LUN#0/Config/*). But had to set up AFI boot manually again.

[Socratis]

@Captain Crunch,
You're complaining about VMs running "El Capitan" to "Catalina" while poinging at an VBoxEFI64.dll? Unless you're booting a real Mac from a Windows Host, you're describing what's commonly known as a "Hackintosh". Another sign is that you're talking about "Clover". You're not seriously asking for Hackintosh support, are you?

Because all my OSX Guests boot just fine on my OSX Host (where they're supported).

@NicolaF_
This is an existing VM or are you trying to install a VM from scratch? In that case, which Debian ISO exactly are you using?

Where/why the extra data came from? If it works now, can the ticket be closed as [WorksForMe] or [Invalid]?

[Socratis]

Oops, sorry, I closed the ticket as [Fixed]. Mea culpa...

[Nicolas]

Hi socratis,

This is an existing VM, where persistence was enabled (VBoxInternal/Devices/efi/0/LUN#0/Config/PermanentSave = 1, set with vboxmanage).

Everything goes fine when creating a new VM from scratch using the mac OSX template (to get everything EFI-related right), and the ​debian stable x64 netinst.

So, this is finally just an upgrade issue.

[aeichner]

The problem is that the old "solution" to store NVRAM content (which didn't even work properly) was removed with VirtualBox 6.1 and a proper solution was implemented instead by emulating a flash device. Extradata config items for a VM are not considered official and can vanish/change in incompatible ways between releases without notice. I'll close this ticket as won't fix as we won't implement an upgrade path for this (only a very small amount of users use this feature and the complexity implementing a solution is far too high).