How to properly set up VM parameters for Ventura guest?

[Cubytus32]

Hi there,

I'm attempting to install macOS Ventura on a Mojave host inside VirtualBox 6.1.32. This is on a MacBook Pro, so no licensing issue here.

I have an ISO for the installer. I followed instructions I could get from the Internet, but for whatever reason, the installer always crashes and reboots about 1/3 to 1/2 of the install process, without any error message popping up. I left everything at the recommended defaults for Mac OS X 64 bits.

So what would be the proper way to configure the virtual machine in order for it to accept macOS guest?

[mpack]

Please provide a VM log file. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[Cubytus32]

Here it is. I had to forcibly shut down the VM since it would reboot in a loop.

macOS 13-2023-03-14-16-14-34.log.zip

(30.44 KiB) Downloaded 47 times

[mpack]

So what would be the proper way to configure the virtual machine in order for it to accept macOS guest?

The proper way would be to select the Ventura template when creating the VM, and don't mess with it too much (push the spec up if you can afford it, not down). However the CPU is not virtualized, so there is no guarantee that Ventura will install on an old 3rd gen i7.

That said, I would certainly try giving the VM 2 CPU cores. You can disable 3D acceleration since it doesn't exist for MacOS guests.

If it still doesn't work then I'd try Apple support.

[Cubytus32]

Thanks for the answer, however, there's no Ventura template, only generic macOS 64 bits:

Captura de Pantalla 2023-03-16 a la(s) 18.36.06 .png (41.37 KiB) Viewed 7186 times

Tried pushing up the specs of the VM, to no avail. I was able to capture macOS' boot screen just before it crashed:

Captura de Pantalla 2023-03-16 a la(s) 18.39.45 .png (58.64 KiB) Viewed 7186 times

[mpack]

Obviously you need a version of VirtualBox that post-dates Ventura. Try updating to 6.1.42.

[fth0]

FWIW, VirtualBox 6.1.42 and 7.0.6 also do not have any newer macOS templates than macOS 10.13 High Sierra (64-bit).

[Cubytus32]

Hmm, no luck with 6.1.42 version, same crash as the 6.1.32 version. Here's log:

macOS 13-2023-03-16-21-16-42.log.zip

(35.35 KiB) Downloaded 25 times

Any ideas?

[fth0]

I don't know if it can work at all, but you should at least change the following:

1. In the VM configuration, set General > Basic > Version to macOS 10.13 High Sierra (64-bit). This is the newest available template and probably the best selection. Generic selections like Mac OS X (64-bit) usually provide a more basic (older) setup and are therefore less likely to work.

2. Do not provide fake host CPUID values advertising CPU features that your host CPU does not provide. The guest OS will try using them, and if your host CPU doesn't provide them, problems will be inevitable. Providing fake host CPUID values is meant to downgrade from the host CPU to the virtual guest CPUs. On the other hand, the guest OS will require some CPU features and if your host CPU doesn't provide them, you're out of luck.

00:00:03.401162 Host RAM: 16384MB (16.0GB) total, 6208MB (6.0GB) available

3. Do not provide more memory to the VM than is available. You can try if starting the VM early after booting the host is a solution to that.

[Cubytus32]

Just tried that:

changed template to 10.13; not specified any specific CPU features (I know that with minimal patching, the host computer can indeed run Ventura).

No luck, same loop-reboot. Any ideas?

[fth0]

You could provide another (zipped) VBox.log file to show that you didn't advertise non-existing CPU features any more, and you could explain the minimal patching you're talking about.

Also note that the virtual CPU(s) do not provide all CPU features of the host CPU to the guest OS.

[Cubytus32]

Here's log. AFAIK I haven't set any specific feature.

macOS 13-2023-03-20-18-38-03.log.zip

(35.91 KiB) Downloaded 23 times

As for the patching, OpenCore Legacy Patcher does provide what appears to be a decent documentaiton.

[fth0]

00:00:03.055178 [/CPUM/HostCPUID/1/] (level 3)
00:00:03.055179   eax <integer> = 0x00000000000106e5 (67 301)
00:00:03.055181   ebx <integer> = 0x0000000000100800 (1 050 624)
00:00:03.055182   ecx <integer> = 0x000000000098e3fd (10 019 837)
00:00:03.055183   edx <integer> = 0x00000000bfebfbff (3 219 913 727)
[...]
00:00:03.629664      Leaf/sub-leaf  eax      ebx      ecx      edx
00:00:03.629684 Gst: 00000001/0000  000106e5 00020800 80982201 178bfbff
00:00:03.629686 Hst:                000306a9 02100800 7fbae3ff bfebfbff

You're telling the guest OS that you have an older CPU (Intel Clarksfield, Family 6 Model 30, 2009-2010) than the host CPU (Intel Ivy Bridge, Family 6 Model 58, 2012-2013). If you want to remove the setting, use VBoxManage modifyvm "macOS 13" --cpuid-remove 1.

[Cubytus32]

macOS 13-2023-03-21-14-58-09.log.zip

(34.03 KiB) Downloaded 20 times

Thanks for the tip, I removed the older CPU flags (must have come from the 10.13 base setting I used), but result is still the same. See attached log.

[fth0]

I can see that you've successfully changed most of the settings mentioned so far (macOS template, CPUID, 2 vCPUs, no 3D acceleration). I see the following issues in your latest VBox.log file:

00:00:03.001358 Host RAM: 16384MB (16.0GB) total, 4294MB (4.1GB) available
00:00:03.325531   RamSize           <integer> = 0x000000017c400000 (6 379 536 384, 6 084 MB, 5.9 GB)

You've still provided memory to the VM that wasn't available. This can work to some extent because the host OS can free memory for the guest. But it might not be a healthy situation in the long run.

00:00:06.320486 EFI: VBoxDbg> loadimage64 'apfs.efi.m.efi' 0xd9d06000 LB 0x98a20
00:00:06.676133 EFI: VBoxDbg> loadimage64 '.efi' 0xd9a39000 LB 0xb6000
00:00:06.689659 EFI: VBoxDbg> loadimage64 'bo.efi' 0xd9c9d000 LB 0x5000
00:00:06.690301 EFI: VBoxDbg> unload 'bo.efi' # 0xd9c9d000 LB 0x5000
[...]
00:00:22.442520 ACPI: Reset initiated by ACPI
[...]
00:00:38.058296 /Public/Storage/AHCI0/Port0/BytesRead 78876672 bytes

There is a reset initiated quite early, perhaps by the guest OS, after reading ~75 MB from the virtual hard disk. Perhaps the images loaded can give a clue, or the contents in the screenshot you've posted ~5 days ago. But that's a question to the guest OS like "What does the guest OS dislike on this virtual machine?".