Coopydood / ultimate-macOS-KVM

Helping noobs and pros alike build the ultimate macOS virtual machine with easy automation, powered by KVM. Now with macOS Sequoia support!
https://coopydood.github.io/ultimate-macOS-KVM/
GNU General Public License v3.0
458 stars 26 forks source link

[KNOWN ISSUE] macOS Ventura fails to install both cleanly and as an upgrade #10

Closed Coopydood closed 1 year ago

Coopydood commented 1 year ago

Discussed in https://github.com/Coopydood/ultimate-macOS-KVM/discussions/9

Originally posted by **eversiege** July 22, 2023 I am not pushing this as an issue, as it's clearly not your fault, but I (and some of my friends) have tried to update Big Sur to Ventura, resulting the machine to hard brick/bootloop. The picture below shows the "Kernel panic" after updating. ![image](https://github.com/Coopydood/ultimate-macOS-KVM/assets/69052669/287b029e-0c80-4cac-84df-04b196bae05c)

An issue has been identified whereby installing macOS 13 Ventura - either by a clean install from the BaseSystem, or as an upgrade from a previous macOS version - fails with various different errors.

Ventura can boot with the project, however installing it seems to be very broken at the moment. I'm investigating this and will post an update if/when a fix is available. An OpenCore modification is likely required and will be looked into.

Sorry for the inconvenience. Please use macOS Monterey or earlier until this is resolved.

Coopydood commented 1 year ago

I've successfully installed macOS Ventura cleanly using ultimate-macOS-KVM.

Will continue to investigate, but it's looking like it's fixed!

Coopydood commented 1 year ago

This appears to be fixed with a simple QEMU CPU model change. This issue does NOT affect users who changed their CPU model from the default. For example, if you manually changed your CPU model to host, this does not affect you.

FOR NEW USERS: as of v0.9.6, this issue has been fixed, and new files generated with AutoPilot will use the new model by default, which can be used to install Ventura.

FOR EXISTING USERS: for users of v0.9.5 or earlier, you have a couple options:


  1. If you have an existing AutoPilot config that you have used for a while, with many customisations of your own, it may be best to just change the CPU model. Do this by finding the following line in your boot script:
    CPU_MODEL="Penryn"

    and change it to

    CPU_MODEL="Skylake-Client"

  1. Generate a new AutoPilot config file. While this does mean you have to go through AutoPilot again, there are a number of benefits. Generating a new AP config ensures you have the latest structure updates, and the best compatibility with the rest of the project:

    • You can keep your existing config file, either by choosing a different name, or by backing up your old one when prompted
    • You can keep and use your existing virtual hard disk file. When AP gets to the Creating virtual hard disk stage, you'll automatically be notified about the existing HDD file, and you'll have the option to use the file in the new config.
    • Your OpenCore boot image will be replaced, but your old OpenCore image will automatically get backed up to a timestamped folder, in the boot folder. If you've made customisations to the OpenCore image, you can move the old one back into place after AP finishes.
    • The virtual NVRAM will be reset, but this is safe. In v0.9.2 and later, you can even select your screen resolution as an AutoPilot stage - meaning you won't lose any resolution changes you may have made.