NVRAM settings corrupted in headless VM

[itsthejb]

Hi,

First of all, thanks for this great tool. I understand that it's a little bit unmaintained right now, so posting in the hope that someone can help. This seems to be some issue with the script:

Steps

1. Populate machine settings into the script
2. Install Catalina as standard
3. Complete installation
4. Reboot, hit esc, run EFI Internal Shell to populate NVRAM settings:

5. Log into macOS
6. Run nvram -x -p to have a look at the NVRAM contents, particularly system-id:
7. A value is populated, base64 encoded. However, decoding the value results in gibberish and definitely not the value I've set for SystemUUID in the script:

So it seems something is wrong here? Currently my only issue is regarding failed SmUUID via iMessageDebugv2:

Hope someone can help! Thanks in advance!

[myspaghetti]

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...

[myspaghetti]

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.

[myspaghetti]

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.

[itsthejb]

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 😆

[myspaghetti]

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

[itsthejb]

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

[itsthejb]

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

[myspaghetti]

The value certainly doesn't look like base64!

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

[myspaghetti]

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.

[itsthejb]

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

[myspaghetti]

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.

[myspaghetti]

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

[itsthejb]

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…

[myspaghetti]

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.

[itsthejb]

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

[myspaghetti]

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.

[itsthejb]

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

[myspaghetti]

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