Stuck at "last" nvram.sh
binerf opened this issue ยท 19 comments
Hi,
First of all, thanks for this script !!
I've just downloaded the last version of the script and executed it.
Unfortunately, at the last nvram.sh
execution (when 2 terminals are open), script stuck while the other command in the second terminal is successfully executed.
Don't know what to do next.
Hi, thanks for the detailed bug report. I misread the report and marked it as "duplicate" and "wontfix", I thought the installer failed to execute and not the NVRAM script, but it's the other way around!
If the macOS installer (startosinstall
) completed successfully, then the virtual machine will reboot itself. The NVRAM part is not necessary to run the macOS guest and the script just ignores it if it fails and waits five minutes to reboot into the last part of the macOS installation process.
If the startosinstall
process didn't complete successfully and didn't reboot the virtual machine, then it's likely due to a CPU incompatibility (which is what I originally thought this report is about and why I marked it "duplicate" and "wontfix"). The incompatible CPU possibly misleads the macOS installer to use some CPU instruction that's not available on the host, resulting in startosinstall
not working properly.
If that's the case, I would recommend assigning a CPU profile that's closer to the host's CPU and then resuming the script:
VBoxManage modifyvm "macOS" --cpu-profile "Intel Core i5-3570"
./macos-guest-virtualbox.sh populate_macos_target_disk
Or:
VBoxManage modifyvm "macOS" --cpu-profile "Intel Core i7-5600U"
./macos-guest-virtualbox.sh populate_macos_target_disk
Though I feel an i7 is less likely to be compatible with an i5 (but it's generationally closer so maybe it'll work).
If these don't work, you'll have to feed VirtualBox custom CPUID settings. No support is offered for CPUID configuration.
Many thanks for your feedback and time spent on my issue.
Ok, so I've tested with the 2 suggestions:
- Intel Core i5-3570: VM doesn't start at all
- Intel Core i7-5600U: VM starts but process stuck at the same point.
Feed VB with custom CPUID settings looks more difficult to me... I'll search for another option.
Thanks again !!
Would you mind running VBoxManage modifyvm "macOS" --cpu-profile host
and then resuming the script, and taking a screenshot when the process gets stuck?
Seems like startosinstall
doesn't even get started. If you still want to troubleshoot this, after startosinstall.sh
terminates, run bash -x /Volumes/target-sh/startosinstall.sh
and screenshot the output. This should tell us exactly which command fails to execute. (If I had to guess, the previous stage, populate_bootable_installer_virtual_disk
, silently failed, possibly due to CPU incompatibility, and the bootable installer is missing some files and startosinstall
can't start)
Thanks. startosinstall
isn't starting. While you could troubleshoot why that is, it should be simpler to run the script from a few stages back:
./macos-guest-virtualbox.sh populate_bootable_installer_virtual_disk and_all_subsequent_stages
I suspect something went amiss with populate_bootable_installer_virtual_disk
which left out files required for startosinstall
. If you can keep an eye on the stage populate_bootable_installer_virtual_disk
we might be able to find the point of failure.
Sorry, didn't get it...
From VB host:
$ ./macos-guest-virtualbox.sh populate_bootable_installer_virtual_disk and_all_subsequent_stages
The command "VBoxManage list extpacks" either does not list the Oracle VM
VirtualBox Extension Pack, or lists one or more extensions as unusable.
The virtual machine will be configured without USB xHCI controllers.
Catalina selected to be downloaded and installed
stage: populate_bootable_installer_virtual_disk
Could not configure virtual machine storage controller. Exiting.
Strange:
$ VBoxManage list extpacks
Extension Packs: 1
Pack no. 0: VNC
Version: 6.1.16
Revision: 140961
Edition:
Description: VNC plugin module
VRDE Module: VBoxVNC
Usable: true
Why unusable:
Virtual machine macOS is still up...
The error message means the VM was not powered off before the script was started. Make sure it's powered off so the script can configure it.
The extpacks error message is fine, macOS works with or without xHCI support.
Thank you so much for taking the time to troubleshoot. I made a mistake, the current error is caused by the VM booting from the bootable installer (disk0
) which is why it can't partition it. The script needs to be resumed from one stage earlier:
./macos-guest-virtualbox.sh create_bootable_installer_virtual_disk and_all_subsequent_stages
The script will prompt to delete the existing bootable installer virtual disk and then continue. This should give you the correct error message... sorry for the mistake.
Oh man I'm leading you down lots of errors... anyway the reason the EFI shell doesn't boot is because the NVRAM can't find the bootable installer any more... You could boot it manually or you could run the script from the beginning. You'll be prompted to delete the virtual machine, but thankfully you won't have to download macOS again.
ANYWAY.
Run the script with no specified arguments (./macos-guest-virtualbox.sh
) and watch for any errors during the create_bootable_installer_virtual_disk
stage.
Sorry for not thinking things through before asking you to run a certain command. However, this time I'm sure that if the script deletes the virtual machine, you won't get stuck on intermediate errors. Hopefully you'll get stuck on the initial error that brought you here.
This time it appears the dmg2img
failed to run properlyBaseSystem.img
failed to boot properly. I'm afraid I can't troubleshoot that. I suspect something similar happened with the original error. My guess is disk read/write errors but I really can't tell.
OK thanks.
You think it might be caused by my computer disk ?
It seems unlikely, because the md5 checksums for all the files are fine. Virtual machine disk issues are usually the fault of incompatible CPU instruction sets.
I got this problem recently, turns out the download speed is so slow, that it kinda hangs out in the middle but the code just continue its business without minding that I skipped 80% of the required installation data.
The download speed using the apple CDN during my first 2 tries was 50KB/s (!!!), much lower than my actual net speed. So what I did was just rerun the process (basically just repeatedly run & quit .sh
) until I got one that gave me full speed during the downloading stage. And everything is smooth sailing since.