NVRAM settings corrupted in headless VM
itsthejb opened this issue · comments
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
- Populate machine settings into the script
- Install Catalina as standard
- Complete installation
- Reboot, hit esc, run
EFI Internal Shellto populate NVRAM settings:
- Log into macOS
- Run
nvram -x -pto have a look at the NVRAM contents, particularlysystem-id: - A value is populated, base64 encoded. However, decoding the value results in gibberish and definitely not the value I've set for
SystemUUIDin 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!
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...
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.
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.
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 😆
I'll fire up a Linux test machine within the next couple of weeks and try to reproduce the bug.
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
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
The value certainly doesn't look like base64!
It isn't! Sorry, there's no need for the base64 decoding there, whoops.
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.
My system uuid is entered as lower case with no dashes. As far as I could gather from comments on here that’s correct?
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 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
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…
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.
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
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.
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
Closing until the bug is reproduced on a non-headless (headful?) VM