VirtualBox

Opened 9 years ago

Closed 4 years ago

#14279 closed defect (fixed)

Switch on permanent NVRAM to fix UEFI boot

Reported by: paddor Owned by:
Component: EFI Version: VirtualBox 4.3.30
Keywords: NVRAM, EFI Cc:
Guest type: Linux Host type: Mac OS X

Description

According to changeset https://www.virtualbox.org/changeset/43256/vbox, the switch for permanent NVRAM save is turned off by default. This breaks UEFI boots which store the location of the OS loader in the NVRAM.

IMHO, it should be persisted by default. It's called non-volatile after all.

If turning it on by default is a problem, a switch in the configuration of the VM would do the job, too.

I just installed a Linux (Funtoo) in the VM, using a VFAT partition as /boot. It was only able to boot after rebooting from within the live CD (or system booted using the kernel from the live CD), but was unable to boot after a complete shutdown (since that clears the NVRAM, apparently).

My current workaround is to provide a startup.nsh (created with the edit command within the EFI shell) which points directly to the OS loader within the ESP, which is fs0:\EFI\FuntooLinux\grubx64.efi in my case.

Change History (21)

comment:1 by Oliver R, 7 years ago

Could you please provide the vboxmanage command for setting "PermanentSave"?

comment:2 by FateRover, 7 years ago

same with this issue ,the new added uefi boot is missing after a completely shut down

comment:3 by Winyl, 7 years ago

have the same issue with version 5.1.28 r117968 (Qt5.6.2). Any OS installed in EFI mode forgets where its bootloader is, because VirtualBox does not save contents of NVRAM although "PermanentSave" option is present in NvRam.cpp code. Why it is not used?

comment:4 by WildCard65, 6 years ago

I feel that lack of permanent NVRAM is a downside to using VirtualBox.

comment:5 by jmorrison, 6 years ago

Can this be fixed? Wasted hours getting an install working because uefi nvram wasn't saved.

comment:6 by antoine2711, 6 years ago

This is very important for Apple virtualization. Please fix it.

in reply to:  6 ; comment:7 by Socratis, 6 years ago

Replying to antoine2711:

This is very important for Apple virtualization.

In what sense? The only real problem so far is the installation of OSX 10.13 but there are workarounds, for example: "HowTo: Install OSX 10.13 in a VM".

Did you have something else in mind?

in reply to:  7 ; comment:8 by Andrey Zentavr, 6 years ago

Replying to socratis:

Replying to antoine2711:

This is very important for Apple virtualization.

In what sense? The only real problem so far is the installation of OSX 10.13 but there are workarounds, for example: "HowTo: Install OSX 10.13 in a VM".

Did you have something else in mind?

MacOS saves some states in NVRAM as well. The very big deal is to save the state for System Integriry Protection. The flag gets lost when you shut down the machine.

in reply to:  8 ; comment:9 by Socratis, 6 years ago

Replying to Andrey Zentavr:

MacOS saves some states in NVRAM as well. The very big deal is to save the state for System Integriry Protection. The flag gets lost when you shut down the machine.

Not true. The SIP is not stored in NVRAM. You simply need to boot into Recovery mode and disable SIP with "csrutil disable". For more details on how to do this for an OSX VM see HowTo: Build VirtualBox ≥ 5.1.2 on OSX ≥ 10.9, section 8. The SIP state is retained until you change it back with the same procedure. Not NVRAM related.

The only thing that you can't do is to boot in Single-user mode.

in reply to:  9 ; comment:10 by libsystem_ethan, 6 years ago

Replying to socratis:

Replying to Andrey Zentavr:

MacOS saves some states in NVRAM as well. The very big deal is to save the state for System Integriry Protection. The flag gets lost when you shut down the machine.

Not true. The SIP is not stored in NVRAM. The only thing that you can't do is to boot in Single-user mode.

Actually, SIP is stored in NVRAM as the csr-active-config variable (https://gist.github.com/pudquick/8b320be960e1654b908b10346272326b). Without a persistent NVRAM, the changes made to this variable made by running csrutil disable in recovery mode are not saved once you exit the VM. This makes using a macOS guest under VirtualBox for things like kext development (or other activities which require SIP to be off) very frustrating, as every time I start my VM, I have to boot to recovery, disable SIP, and then boot back into macOS.

Last edited 6 years ago by libsystem_ethan (previous) (diff)

in reply to:  10 comment:11 by Socratis, 6 years ago

Replying to libsystem_ethan:

Actually, SIP is stored in NVRAM ... the changes made to this variable made by running csrutil disable in recovery mode are not saved once you exit the VM.

I stand corrected. I never tried to completely shutdown the VM after I made the recovery mode changes. I just tried it again, but this time I completely shut down the VM. It failed to disable SIP. My apologies for the misguiding comment...

in reply to:  8 ; comment:12 by mwaks, 6 years ago

Facing the issue of making the SIP status persistent . Have any workarounds ? I am on a High Sierra host running a Sierra VM

Replying to Andrey Zentavr:

Replying to socratis:

Replying to antoine2711:

This is very important for Apple virtualization.

In what sense? The only real problem so far is the installation of OSX 10.13 but there are workarounds, for example: "HowTo: Install OSX 10.13 in a VM".

Did you have something else in mind?

MacOS saves some states in NVRAM as well. The very big deal is to save the state for System Integriry Protection. The flag gets lost when you shut down the machine.

Last edited 6 years ago by mwaks (previous) (diff)

in reply to:  12 comment:13 by Socratis, 6 years ago

Replying to mwaks:

Have any workarounds?

Don't shutdown the VM. If there was another way, this ticket would have been [Closed]. ;)

comment:14 by Codeguard, 5 years ago

Workaround:
1) Close all VirtualBox windows, or your edits will be reverted automatically.
2) Find your VM's .vbox file and edit it, adding these lines in <ExtraData>:

<ExtraDataItem name="VBoxInternal/Devices/efi/0/LUN#0/Config/Vars/0000/Name" value="csr-active-config"/>
<ExtraDataItem name="VBoxInternal/Devices/efi/0/LUN#0/Config/Vars/0000/Uuid" value="7c436110-ab2a-4bbb-a880-fe41995c9f82"/>
<ExtraDataItem name="VBoxInternal/Devices/efi/0/LUN#0/Config/Vars/0000/Value" value="bytes:dwAAAA=="/>

3) If there are some variables already, renumber '0000'

Version 0, edited 5 years ago by Codeguard (next)

comment:15 by Captain Crunch, 4 years ago

What's the equivalent "magic" (i.e. the ExtraDataItem XML) from Comment 14 to persist "spctl kext-consent disable"? If suffers from the same problem as sip. You have to reboot to disable it, but in my case, reboot hangs and when I reset the machine, the config is lost.

comment:16 by Captain Crunch, 4 years ago

That approach of persisting sip doesn't appear to work in Catalina. I made sure the file handle was free, modified the .vbox file with your ExtraDataItem, but when Catalina boots, nvram -xp reports that csr-active-config still has the default value. "csrutil status" reports that sip is in an unknown state (rather than disabled), so it is doing _something_, but not what's needed.

comment:17 by aeichner, 4 years ago

I'd recommend waiting for the final release of 6.1 or try 6.1 Beta 2 here which has proper NVRAM support included and should fix this ticket.

in reply to:  17 comment:18 by Socratis, 4 years ago

Replying to aeichner:

I'd recommend waiting for the final release of 6.1 or try 6.1 Beta 2 here

Since we're talking about trying, there's also the Development Snapshots which are 6.1.0beta2++...

in reply to:  17 comment:19 by Captain Crunch, 4 years ago

Replying to aeichner:

I'd recommend waiting for the final release of 6.1 or try 6.1 Beta 2 here which has proper NVRAM support included and should fix this ticket.

I installed the official VB 6.1.0 release, but I couldn't boot any of my OSX machines after the upgrade. To recover, I modified the VM definitions to point at the VBoxEFI64.fd efi rom image from VB 6.0.14. After doing that I can boot again, but NVRAM persistance isn't working - tested with "csrutil disable".

Does the nvram fix in VB 6.1.0 require the new efi rom, or should it work without it?

comment:20 by Captain Crunch, 4 years ago

To update, both issues - the failure to boot and the nvram failures - were caused by Clover (a boot manager). The failure to boot just required removing some old drivers, but the nvram failures remain with the latest Clover. (I was not using the Clover with "emulated NVRAM" and I saw no nvram drivers installed nor the nvram.plist file used by Clover to persist nvram.)

That would also explain why even adding the explicit vbox data lines didn't work for me.

comment:21 by aeichner, 4 years ago

Resolution: fixed
Status: newclosed

The NVRAM fix definitely needs the new EFI ROM and the extradata version to supply EFI variables was removed because it was just too broken. I'll close this ticket as fixed for now, please reopen or create a new ticket if there are issues remaining with the new NVRAM implementation.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use