NVRAM settings corrupted in headless VM about macos-virtualbox HOT 18 CLOSED

Hi, thanks for the bug report!

It's very possible VirtualBox changed the behavior of dmpstore, I'll go have a look. Might take me a couple of weeks, this script is not a priority for meat the moment...

from macos-virtualbox.

I'll fire up a Linux test machine within the next couple of weeks and try to reproduce the bug.

from macos-virtualbox.

From a cursory glance the issue could be that VBox is running in headless mode. This causes issues with the script, but I don't see how that would affect the EFI and NVRAM.

I've attached my own troubleshoot.txt if you want to vimdiff for issues through it...
macOS_troubleshoot.txt

from macos-virtualbox.

The command nvram 7C436110-AB2A-4BBB-A880-FE41995C9F82:system-id | base64 -d | xxd in the VM should show you the value you entered in the script if writing to NVRAM was successful.

from macos-virtualbox.

dmpstore appears to be the same as before. What version of VirtualBox are you using? Would you mind running macos-guest-virtualbox.sh troubleshoot on the host and attaching the resulting file here? Please mind that it contains personal information like directory names and parameters that have been set in the script.

from macos-virtualbox.

Hi there,

Thanks for taking a look! Happy to assist in getting this resolved at some point (no urgency for me either; this is a nice-to-have style project!).

I should have provided environment info:

» vboxmanage --version
7.0.6_Ubuntur155176
» cat /etc/os-release
PRETTY_NAME="Ubuntu 23.04"
NAME="Ubuntu"
VERSION_ID="23.04"
VERSION="23.04 (Lunar Lobster)"
VERSION_CODENAME=lunar

I'm currently reinstalling a Catalina VM, since it seems I left it in some unclear state.

Happy to look into this right now since I'm stuck in the house today 😆

from macos-virtualbox.

I had considered just creating the VDI using a mac - but I've only got access to M1 machines, which seems a non-starter?

More debug info coming asap

from macos-virtualbox.

Alright, further info:

$ nvram 7C436110-AB2A-4BBB-A880-FE41995C9F82:system-id | base64 -d | xxd
Invalid character in input stream.

The value certainly doesn't look like base64!

Attaching the troubleshooting log in the next comment

from macos-virtualbox.

The value certainly doesn't look like base64!

It isn't! Sorry, there's no need for the base64 decoding there, whoops.

from macos-virtualbox.

I think the issue is with the dashes in the UUID, but I haven't used the script for so long that I'm not sure. I'll get back to you within the next couple of weeks.

from macos-virtualbox.

My system uuid is entered as lower case with no dashes. As far as I could gather from comments on here that’s correct?

from macos-virtualbox.

Alright, I dug a machine from under a stack of clothes in the closet, installed Ubuntu Desktop 23.04 and VirtualBox 7.0.6_Ubuntur155176

Couldn't reproduce the bug, NVRAM reports the same values as entered in the script.

I'll look into the troubleshooting log.

from macos-virtualbox.

Thanks very much for taking a look! Yes, headless mode seems like an obvious culprit, but very strange… perhaps I can rent an AWS GUI instance or something and try some debugging…

from macos-virtualbox.

Before you spend any money on this, consider fiddling around with the UEFI boot environment manually, and if that doesn't work you can create a VMDK macOS image instead of a VDI image and then boot it with OpenCore on QEMU/KVM in Proxmox or your preferred distro.

from macos-virtualbox.

OK thanks. I assume then that creating the disk image elsewhere wouldn’t do anything for me, and that the problem lies with the NVRAM binaries / UEFI?

I suppose there are some clues now and I can debug further

from macos-virtualbox.

Couldn't find any clues and didn't attempt to reproduce the bug on a headless VM because the script doesn't officially support headless VMs. It doesn't necessarily mean that the bug is caused by the headless-ness, but it would help if you could reproduce the bug on a non-headless VM.

from macos-virtualbox.

No worries. It’s a bit of a head scratcher right now! I’ll see if I can come up with anything in the near future, and please share if you have any other ideas

from macos-virtualbox.

Closing until the bug is reproduced on a non-headless (headful?) VM

from macos-virtualbox.