Jump to content

[pre-release] macOS Ventura


3,556 posts in this topic

Recommended Posts

5 hours ago, Middleman said:

Okay Henties.

I haven't yet tackled Z490 yet (that will be my next task) but I think it could work.
 

@Middleman Thank you for your response however I think you may have misread my original post.

 

There is no need for me to try and get Monterey to boot.

Presently Monterey is booting flawlessly with either OC 0.8.1 or OC 0.8.2

I nevertheless followed your suggestions, unfortunately without success.

 

Keen to hear from you as soon as you have tackled your Z490 

 

Greetings Henties

 

  • Like 1
Link to comment
Share on other sites

8 hours ago, eSaF said:

I need a board to utilise my Ninth Gen CPU or am I on the wrong track?

I’m afraid you need a newer CPU. Z490 mobos need 10th gen. Z590 can have 10th or 11th. 690 chipset with 12th gen are very very powerful but more difficult to install macOS. 

Link to comment
Share on other sites

@STLVNUB - Hiya, tried your EFI Folder with a clean install and it fell at the same hurdle as before. It goes all the way through the first stage then on the second stage it starts to continue with the install and then 12 minutes remaining of this stage, it throws up the message 'A Required Firmware Update could not be Installed'.

 

There is something quirky happening between Ventura and the Gigabyte Z390 motherboard that it doesn't like and I can't put my findings on it whereas other boards had a relatively easy time via a few tweaks. All in all, thanks for the help, appreciate the kind gesture.

  • Like 2
  • Sad 2
Link to comment
Share on other sites

Just now, miliuco said:

I’m afraid you need a newer CPU. Z490 mobos need 10th gen. Z590 can have 10th or 11th. 690 chipset with 12th gen are very very powerful but more difficult to install macOS. 

Yes I realised that after some research (the offer of my projected B'day present from wifey just disappeared in the distance :hysterical: )

  • Haha 6
Link to comment
Share on other sites

After successfully booting my Z690 mobo with Ventura ß1 (described here), I tried to get Ventura to install and boot on an MSI Creator TRX40 mobo.  On another forum, fabiosun has done a lot of work and had it working on his TRX40 mobo. After trial and error, I got it partially working, but it would stop short of login. Since this stoppage was similar to what I've read others have observed on other mobos, I thought that the solution might help other, non-TRX40 mobo users.

 

While I'd not needed the following kext with the TRX40 for Big Sur or Monterey, the AppleMCEReporterDisabler kext file is now needed for Ventura ß1 (this kext is not required for the Z690 mobo).

 

Once, this kext was loaded, Ventura would finish the install and boot. However, once booted, the machine would crash and boot-loop in less than a minute. It turns out there was one more problem: the Aquantia ethernet port.

 

After disconnecting the cable  to the Aquantia port, Ventura became stable. The built-in Aquantia is an AQC107 (not the newer Aquantia AQC113 that is working in Ventura ß1 on the Z690 mobo). BTW, enabling v082 OC's Kernel/Quirks/ForceAquantiaEthernet had no effect on the stability of Ventura; the cable could not be left connected to the port.

 

So besides the latest OC and OC kexts and disabling Booter/Quirks/AvoidRuntimeDefrag, with the TRX40 mobo, Ventura required the AppleMCEReporterDisabler kext and disconnecting the built-in Aquantia AQC107 port.

AppleMCEReporterDisabler.kext.zip

Edited by iGPU
  • Like 4
Link to comment
Share on other sites

4 hours ago, aben said:


Can confirm: this kext fixes the YouTube-playback issue on Safari :) Also, LVDS display no more wakes up to black screen from sleep. Thank you very much!

Thanks for your confirmation! And does this mean that everything goes as flawless as Monterey?

 

Thanks @dhinakg

  • Like 1
Link to comment
Share on other sites

8 minutes ago, iGPU said:

After successfully booting my Z690 mobo with Ventura ß1 (described here), I tried to get Ventura to install and boot on an MSI Creator TRX40 mobo.  On another forum, fabiosun has done a lot of work and had it working on his TRX40 mobo. After trial and error, I got it partially working, but it would stop short of login. Since this stoppage was similar to what I've read others have observed on other mobos, I thought that the solution might help other, non-TRX40 mobo users.

 

While I'd not needed the following kext with the TRX40 for Big Sur or Monterey, the AppleMCEReporterDisabler kext file is now needed for Ventura ß1. 

 

Once, this kext was loaded, Ventura would finish the install and boot. However, once booted, the machine would crash and boot-loop in less than a minute. It turns out there was one more problem: the Aquantia ethernet port.

 

After disconnecting the cable  to the Aquantia port, Ventura became stable. The built-in Aquantia is an AQN107 (not the newer Aquantia AQC113 that is working on the Z690 mobo). Enabling v082 OC's Kernel/Quirks/ForceAquantiaEthernet had no effect on the stability of Ventura; the cable could not be left connected to the port.

 

So besides the latest OC and OC kexts and disabling Booter/Quirks/AvoidRuntimeDefrag, with the TRX40 mobo, Ventura required the AppleMCEReporterDisabler kext and avoiding any Aquantia AQN107 connection.

AppleMCEReporterDisabler.kext.zip 2.5 kB · 2 downloads

ForceAquantiaEthernet patch itself should be still there; I confirmed that some days ago.

 

This means that most likely we will need some other patches.

  • Like 2
Link to comment
Share on other sites

18 minutes ago, PMheart said:

Thanks for your confirmation! And does this mean that everything goes as flawless as Monterey?

 

Thanks @dhinakg


Yup, so far so good with regards to iGPU aspects; extremely content with the performance. Really don't see any difference TBH compared to Monterey; just as fluid and snappy. Thank you once again and best regards to @dhinakg as well!

  • Like 1
Link to comment
Share on other sites

Just to confirm, currently the Z370 platform stops with "Required Firmware Update", right?

 

I have HD630, so tried Macmini8,1 and iMac19,1, -disablegfxfirmware, no_compat_check, ... Of course, latests OC 0.8.2 and Kexts.

Link to comment
Share on other sites

Does anyone have a working Ventura system with Clover?

I would switch to OpenCore for my laptop but i need a custom DSDT and it needs to be wife friendly so uefi boot option isnt a fix.

DSDT.aml

Edited by SavageAUS
  • Haha 1
Link to comment
Share on other sites

Just now, ITzTravelInTime said:

Any news for the people that needs avoidruntimedefrag in order to successfully boot into monterey? (and so can't boot into ventura)

I can confirm it works on Monterey without AvoidRuntimeDefrag on Coffee Lake. My config file is in post above.
@miliuco I thought you should know this too.

  • Like 2
Link to comment
Share on other sites

24 minutes ago, ludufre said:

Just to confirm, currently the Z370 platform stops with "Required Firmware Update", right?

 

I have HD630, so tried Macmini8,1 and iMac19,1, -disablegfxfirmware, no_compat_check, ... Of course, latests OC 0.8.2 and Kexts.

Were you successful with installing Ventura with those settings?

Link to comment
Share on other sites

11 minutes ago, Middleman said:

I can confirm it works on Monterey without AvoidRuntimeDefrag on Coffee Lake. My config file is in post above.
@miliuco I thought you should know this too.

My question is different, i am asking if there are any developments for the people that NEED avoidruntimedefrag to boot big sur or more recent, and so can't really boot into venura (with an attempt at booting without that quirk enabled resulting into a system stuck during boot, for example shortly after `[pci configuration end]` or similar, like my x99 system does).

Edited by ITzTravelInTime
  • Like 2
Link to comment
Share on other sites

4 minutes ago, ITzTravelInTime said:

My question is different, i am asking if there are any developments for the people that NEED avoidruntimedefrag to boot big sur or more recent, and so can't really boot into venura (with an attempt at booting without that quirk resulting into a system stuck during boot, for example shortly after `[pci configuration end]` or similar, like my x99 system does).

Do you have any settings under DeviceProperties?

Link to comment
Share on other sites

7 minutes ago, ITzTravelInTime said:

My question is different, i am asking if there are any developments for the people that NEED avoidruntimedefrag to boot big sur or more recent, and so can't really boot into venura (with an attempt at booting without that quirk resulting into a system stuck during boot, for example shortly after `[pci configuration end]` or similar, like my x99 system does).

Right. And to answer your question, 'Yes there are developments for you folks'. My previous Acer config on Monterey using OC 0.7.8 was unable to boot without AvoidRuntimeDefrag enabled. Since I managed to get Ventura going on OC 0.8.1, I can confirm Montery can now also boot from the same config file on Coffee Lake. So yes.

  • Like 2
Link to comment
Share on other sites

Just now, Cyberdevs said:

Do you have any settings under DeviceProperties?

 

I am just using some patches for device names and audi layout id, stuff that i can remove, the same config can boot fine into monterey (once i enable avoidruntimedefrag).

1 minute ago, Middleman said:

Right. And to answer your question, 'Yes there are developments for you folks'. My previous Acer config on Monterey using OC 0.7.8 was unable to boot without AvoidRuntimeDefrag enabled. Since I managed to get Ventura going on OC 0.8.1, I can confirm Montery can now also boot from the same config file on Coffee Lake. So yes.

 

I still have the same problem after updating to OC 0.8.1.

Link to comment
Share on other sites

Just now, ITzTravelInTime said:

I am just using some patches for device names and audi layout id, stuff that i can remove, the same config can boot fine into monterey (once i enable avoidruntimedefrag).

Try without them and see if that changes anything.

When I add any DeviceProperties my SkyLake or KabyLake just doesn't boot to the installer. I guess it's worth to give a try.

Link to comment
Share on other sites

8 minutes ago, Cyberdevs said:

Try without them and see if that changes anything.

When I add any DeviceProperties my SkyLake or KabyLake just doesn't boot to the installer. I guess it's worth to give a try.

Tried but nothing, still stuck at [pci configuration end] and it does the same with catalina and monterey too, just by enabling avoidruntimedefrag i can boot into those oses (but i get stuck at the boot.efi log on ventura).

Link to comment
Share on other sites

Guest 5T33Z0

@ITzTravelInTime EDIT: AvoidRuntimeDefrag quirk has been fixed

 

On most Intel CPU Generations, AvoidRuntimeDefrag is a necessity to boot the System.

 

What I know/observed so far:

  • 10th Gen and newer: don't require it to boot, therefore macOS 13 can be installed
  • 3rd Gen (Ivy Bridge): requires it, so no chance to install macOS 13 on it.
  • 4th (Haswell): ?
  • 5th Gen (Broadwell): ?
  • 6th Gen (Skylake): required.  Also requires Skylake Inector kext for the iGPU
  • 7th Gen (Kaby Lake): ?
  • 8th & 9th  Gen (Coffee Lake): I am seeing mixed results

 

Latest Lilu build works without -lilubetaall, btw: https://dortania.github.io/builds/?product=Lilu&viewall=true

 

In fact, you should update OpenCore and ALL your kexts to the latest avaialble builds (esp. Lilu, VirtualSMC and Whatevergreen) before attempting to install macOS Ventura. They all can be obtained from Dortania's build repo (select from them from the dropdown menu).

 

I had strange pink stripes on my display during boot. After updating Lilu and whatevergreen they were gone. And some apps stopped crashing as well.

Edited by 5T33Z0
Link to comment
Share on other sites

3 hours ago, aben said:


Yup, so far so good with regards to iGPU aspects; extremely content with the performance. Really don't see any difference TBH compared to Monterey; just as fluid and snappy. Thank you once again and best regards to @dhinakg as well!

All credits must go to @dhinakg :)

 

Would you mind helping me do another test:

- Delete the previous SkylakeInjector from @dhinakg

- Use the new SKLAsKBLGraphicsInfo.kext as attached

- Delete device-id spoofing as KBL (VERY IMPORTANT)

- Keep KBL ig-platform-id

 

This new SKLAsKBLGraphicsInfo.kext replaces `IOPCIPrimaryMatch` with SKL IDs, thus no extra spoofing will be required.

 

Thanks!

 

EDIT - @Hervé thanks for your confirmation as well. If you want, could you please do the test above as well?

 

 

UPDATE - This will not work, as device-id will be checked by KBL kext when probing. Also, this method caused kernel panic as reported by @Hervé. Removed.

 

Edited by PMheart
  • Like 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...