search

DrDonk / unlocker

VMware macOS utilities
MIT License
3.25k stars 452 forks source link

macOS Ventura + VMware Workstation Player on Linux = Boot error #62

Closed julianxhokaxhiu closed 1 year ago

julianxhokaxhiu commented 1 year ago

Hi,

As previously mentioned in this issue ( https://github.com/DrDonk/unlocker/issues/51#issuecomment-1338316853 ) I've been trying to install macOS Ventura on the latest VMware Workstation Player on Linux on Arch ( https://aur.archlinux.org/packages/vmware-workstation ) and I used your patcher ( https://aur.archlinux.org/packages/vmware-unlocker-bin ) which worked fine, and patched the VMWare binaries.

I can successfully create a new VM choosing macOS ( up to version 14 ) as a confirmation of the patch and I can boot a macOS VM. Although upon using your Intel template and trying to boot the ISO I created using a genuine macOS machine on top of that said template, VMware shows up a screen like this after 30s of loading ( the progress bar moves while the Apple logo is on the screen ):

zMY5VI.png

Any idea how could I approach this and provide additional logs?

Machine spec: CPU: Intel i7-8550U RAM: 8GB DDR4 SSD: 256GB NVMe GPU: Intel UHD 620 + Nvidia MX 130 Linux Kernel: 6.0.11.arch1-1

As an additional note, running the same ISO, on the same machine, but using Windows 11 instead of Linux ( and VMware Workstation 17 patched with your unlocker ) works just fine.

Thank you in advance, Julian

DrDonk commented 1 year ago

Thanks for starting a new issue. Could you zip up vmware.log from Linux and Windows so I can compare them please? They are in the guests’ folder.

julianxhokaxhiu commented 1 year ago

Here you can find the Linux one: vmware-17-linux.zip

I'll post the Windows one later as I need to re-create the medium ( I just wiped the laptop this morning to retry with Linux again ).

DrDonk commented 1 year ago

I can't see anything obvious from the logs. will you be in a position to switch between Linux or Windows easily?

It may be also worth me creating a simple recovery macOS VM with logging to get some details from macOS. It can the be used as a known test.

julianxhokaxhiu commented 1 year ago

I'm currently making a Windows-To-Go SSD so I can use it on the same laptop. Not a big deal :)

Regarding the logging on the VM how can I enable it? And how could I dump the output to a log file in case?

Thanks!

DrDonk commented 1 year ago

Win2Go sounds ideal for this.

The basics are documented here https://github.com/DrDonk/unlocker/wiki/Debugging-macOS-Guests but as you have a VM with recovery OS installed it is simpler to use nvram commands to debug bootargs rather than the EFI stuff in the wiki article.

So using the recovery VM follow these instructions:

  1. Power off and close in VMware
  2. Edit the VMX file and add:
answer.msg.serial.file.open = "Replace"
serial0.fileName = "serial.log"
serial0.fileType = "file"
serial0.present = "TRUE"
serial0.tryNoRxLoss = "FALSE"
serial0.yieldOnMsrRead = "TRUE"
vmx.buildType = "debug"

Just make sure you don't have any duplicate lines before saving, such as the vmx.buildtype line. VMware will complain if you do but it will tell you where the duplicate line is in the error message so no biggie if you do have duplicates..

  1. Power on the VM in Windows (as only one that works) and from recovery open the Terminal and add:

nvram bootargs="-v keepsyms=1 debug=0x108 msgbuf=4194304 serial=1 wdt=-1 -topo -no_panic_dialog"

  1. Now reboot and should see some debug output before it switches to using virtual serial port.

  2. Power the VM down and keep the vmware.log and serial.log files.

  3. Copy the Windows VM to Linux and run it there and again capture the 2 files.

Cheers Dave

julianxhokaxhiu commented 1 year ago

Thanks, I'll try to replicate all the steps and post the logs here.

Regarding the Linux part though, unfortunately I'm not able to set the nvram as not even the recovery boots. But I'll do my best to provide those files to you.

//EDIT: Upon reaching the step 3 and after I added the lines to the vmx file, this shows up upon booting the VM: image Then when I click ok the vm shuts down and nothing happens. I'll try to google for this error.

//EDIT2: If I remove this line

vmx.buildType = "debug"

then the error goes away and the VM starts fine. Something off with it.

//EDIT3: The same vmx file with the debug line in it, crashes vmware upon launching the vm on Linux. Maybe v17 doesn't have support for this buildtype? Not sure.

DrDonk commented 1 year ago

OK interesting. Just remove the line and it will use the release version rather than debug.should stil get good info.

I’ve heard of this problem with debug once before but never got to the bottom of it.

julianxhokaxhiu commented 1 year ago

Ok I'm honestly very confused, I'm not sure what happened today but all my three attempts now seems to have worked, also under Linux. And the best part is that I didn't update literally anything other than testing the vmx from Windows I was able to boot ( I didn't even install macOS, all attempts were made from booting the ISO ).

In order to generate those zips I used the instructions available in your Wiki page.

Here you can find my three attempts:

  1. macOS-Windows-Working.zip
  2. macOS-Linux-from-Wndows-working.zip
  3. macOS-Linux-from-Scratch-working.zip

All of them were done starting from the intel template from your current latest release. I'm honestly puzzled because this is what I've been doing yesterday the whole day and now magically everything works. Please tell me something changed in the environment through the logs you're able to see, because I've got no other explanation. Something must have unlocked on VMWare somehow.

//EDIT: Btw I'd suggest adding this line into your steps

bios.forceSetupOnce = "TRUE"

which will enforce the user to boot into the EFI shell even if not using Workstation Pro. See https://kb.vmware.com/s/article/1004129

DrDonk commented 1 year ago

I'll take at the logs later today, got a family issue to sort out, but does seem odd. I'm going to change the debug method so won't need the EFI method. I will make available 2 macOS recovery VMs one for Monterey and another for Ventura. I did that when the long threads on AMD and also older Intel CPUs were being discussed. By doing that I know everyone is using the same tests.

julianxhokaxhiu commented 1 year ago

Thanks a lot for your time invested and no worries, take your time as this has absolutely no pressure. Hope it is all well on your end! Feel free to ping me if I can help somehow.

//EDIT: I think I found the main difference I did between yesterday and today: in all the tests above the macOS version is set to macOS 11 but yesterday I always set the macOS version to macOS 13. This is I suppose what leads to a crash. I'll try dumping the serial output on both Windows and Linux now that I noticed this and I'll append it here.

//EDIT2: OMG I found it! I'm very sorry but I think this has nothing to do with Windows vs Linux, but on flags I thought they'd work OOB but they don't! I am able to replicate the issue by just ticking ON this option on the CPU settings: Virtualize IOMMU. As soon as I do it, macOS hangs with the startup screen on the OP. I'm very sorry for wasting your time, but that's it. If I untick it ( but I tick the rest ) all works as usual, super fast, super fluid! Thanks a lot, you may now close the issue if you want.

DrDonk commented 1 year ago

Do you know it craps out in Fusion as well if you set that flag to on? One to add to list of required parameters.

vvtd.enable = "FALSE"

I have a bunch of to-dos from recent work and I will re-create template VMs for different versions of macOS.

No problem with the issue it's one of those newer things I found and needs properly documenting.