macOS Tahoe 26 on Unsupported Macs Discussion

[deeveedee]

The title of this thread is "macOS Tahoe 26 on Unsupported Macs Discussion"

I assumed the "Discussion" meant exactly that ("discussion" is absent from the other unsupported thread titles). If others don't want the discussion in this thread, I'm fine with that.

EDIT: I thought there would be a new "macOS Tahoe 26 on Unsupported Macs Thread" but I agree that would get confusing.

 

[olad]

The title of this thread is "macOS Tahoe 26 on Unsupported Macs Discussion"

I assumed the "Discussion" meant exactly that ("discussion" is absent from the other unsupported thread titles). If others don't want the discussion in this thread, I'm fine with that.

EDIT: I thought there would be a new "macOS Tahoe 26 on Unsupported Macs Thread" but I agree that would get confusing.

I would hate to run against you in a debate! You are right about 'Discussion' or 'Thread', but the knife you use for splitting hairs must be very finely honed. I agree with you that I thought we'd have "...Unsupported Macs Thread" but there it is. Your take is always entertaining and welcome, but on this, I am with @houser.

 

[olad]

Well you aree of course making sense and it would appear you are a bit of a pro on the subject, and I was maybe a tad more focused on people who come in and hit the binaries unknowingly and who will not read the fine print.
Mixing up reasonably clean and documented binaries such as real OCLP with clearly less serious ones just seems careless to me.

This thread could at least have been a bit of a safe-ish space in dangerous times (one binary to track), especially as OCLP as prior discussions tell, has some security issues on its own. But I hear you. And I peacefully disagree. For me this thread has lately become close to unreadable so I am not reading it much anymore because of the noise.
Ah well that would be my take on it. No more on the subject from me.
It has been a good few years.
Be safe be well.

Please don't stop your inputs on any topic. Banter is good.

 

[StefanAM]

It was a pain to install Beta2 on MacPro1,1. Sound and USB1,1 works. The only thing it doesn't is hardware acceleration - AMD FirePro W5100. I run it with "-amd_no_dgpu_accel". Thanx @laobamac_yyds (OCLP-Mod)!

 

[ImaxGuy]

EDIT: Leaving the post below for history, but Polaris is not dropped in Tahoe. See here.

@ImaxGuy If I'm not mistaken, your MBP 2019 includes Radeon Polaris dGPU (similar to iMac 19,x). Since Apple dropped support for AMD Polaris, it will be interesting to see how the OCLP Devs patch this. I'm hoping for a solution from the Open Core Developers with a change to WhateverGreen.kext, so that the fix does not require OCLP root patches. If WhateverGreen.kext can't fix this, it may be that the fix for this requires OCLP root patching.

EDIT: Note that I have a Hackintosh with AMD Polaris RX 560x. When I attempt to boot Tahoe with this dGPU, the desktop is briefly visible and then macOS Window Server panics, forcing a reboot. Someone in another forum claims that Tahoe's Window Server is attempting a Metal 4 operation. Since Intel's UHD 630 is Metal 3 and Tahoe works fine with it, there should be a patching solution for AMD Polaris (reverting some of the macOS kernel to something ported from Sequoia).

Thanks for the info. System report displays "Radeon Pro Vega 20". Is that in the Polaris family?

 

[deeveedee]

Thanks for the info. System report displays "Radeon Pro Vega 20". Is that in the Polaris family?

If Vega, it's not Polaris. I'm not too knowledgeable about the Radeon architectures, so someone else please chime in.

EDIT: @ImaxGuy Here's a good reference from Dortania.

 

[dhinakg]

But now that the lead man at OCLP is switching to Apple for money, Sequoia 15.6.x will
mean the end of macOS on older Intel Macs.

You may be interested in looking at this link.

 

[Neon Ball]

With permission from the graphics devs, I'll be sharing some progress on Tahoe graphics patches.

Now these are not to be taken as the patches being "close to ready" as there is still work to be done and the next beta might break things again. These are just to show (and reassure) that development is still ongoing and an acceleration milestone has been reached.

Additional note for Non-Metal is that Liquid Glass won't be functional due to the downgrades required, hence "old" blurs will be used as a substitute. There's also work to be done with this, as can be seen from the Non-Metal images.

A new issue post has also been released with information, already posted by Dhinak.

 

[ronton3]

With permission from the graphics devs, I'll be sharing some progress on Tahoe graphics patches.

Now these are not to be taken as the patches being "close to ready" as there is still work to be done and the next beta might break things again. These are just to show (and reassure) that development is still ongoing and an acceleration milestone has been reached.

Additional note for Non-Metal is that Liquid Glass won't be functional due to the downgrades required, hence "old" blurs will be used as a substitute. There's also work to be done with this, as can be seen from the Non-Metal images.

A new issue post has also been released with information, already posted by Dhinak.

Thank you for the good news.

 

[amaze1499]

With permission from the graphics devs, I'll be sharing some progress on Tahoe graphics patches.

Now these are not to be taken as the patches being "close to ready" as there is still work to be done and the next beta might break things again. These are just to show (and reassure) that development is still ongoing and an acceleration milestone has been reached.

Additional note for Non-Metal is that Liquid Glass won't be functional due to the downgrades required, hence "old" blurs will be used as a substitute. There's also work to be done with this, as can be seen from the Non-Metal images.

A new issue post has also been released with information, already posted by Dhinak.

Thank you. your response is much appreciated.

 

[Oxygen-X1]

You may be interested in looking at this link.

So one can only hope that it succeeds.

 

[ori69]

EDIT: Leaving the post below for history, but Polaris is not dropped in Tahoe. See here.

@ImaxGuy If I'm not mistaken, your MBP 2019 includes Radeon Polaris dGPU (similar to iMac 19,x). Since Apple dropped support for AMD Polaris, it will be interesting to see how the OCLP Devs patch this. I'm hoping for a solution from the Open Core Developers with a change to WhateverGreen.kext, so that the fix does not require OCLP root patches. If WhateverGreen.kext can't fix this, it may be that the fix for this requires OCLP root patching.

EDIT: Note that I have a Hackintosh with AMD Polaris RX 560x. When I attempt to boot Tahoe with this dGPU, the desktop is briefly visible and then macOS Window Server panics, forcing a reboot. Someone in another forum claims that Tahoe's Window Server is attempting a Metal 4 operation. Since Intel's UHD 630 is Metal 3 and Tahoe works fine with it, there should be a patching solution for AMD Polaris (reverting some of the macOS kernel to something ported from Sequoia).

The problems with Polaris were with Tahoe beta1. In beta2, Apple restored the Polaris drivers and removed AppleHDA.kext.

 

[hvds]

Experimented with OCLP 2.4.0 from source, main goal is understanding. If that shows anything, then how well OCLP is written so that a non-specialist user like me can understand something.

First tried to generate the correct USB-Map.kext/Plist.info via OCLP directly. Modifications to several places in source listed in text file. The substantial changes are in the data at payloads/Kexts/Plists/AppleUSBMaps/Info.plist - here made only changes relevant to my MBP11,1 and MBP5,2. Caution, the Info.plist is not taken from here but setting up with Build-Project.command puts it into payloads.dmg so delete this first after changes to info.plist.

This modified 2.4.0 then generated correct EFIs for the 5,2 and 11,1.

Next was trying root patching. No metallib found yet for Tahoe so don't patch graphics. Try to get wifi to work.
Execution has to fail because Universal-Binaries.dmg doesn't contain things for Darwin 25 yet. So tried to use earlier versions (by cp -R 13.7.2-xx 13.7.2-25) and then repeat root patching without leaving OCLP.
Using xx=24 (i.e. Sequoia) executes the patch but patched system won't boot, so restored it.

I may try other xx later, but understanding was the goal.

Edit: with Sonoma (23), same result, won't boot. Referenced from WiFiPeerToPeer, missing symbol __os_trace_zalloc.

 

[shafez]

Not a word from OCLP team, Have they bandand the development for good?

 

[StefanAM]

Not a word from OCLP team, Have they bandand the development for good?

Good morning!

 

[Kamiljarzi]

Hello everyone Unfortunately OCPL 3.0 DEV. it doesn't work on Macbook pro 11.1 even the installation doesn't work

 

[gilby101]

Not a word from OCLP team, Have they bandand the development for good?

Did you miss this post from @dhinakg https://forums.macrumors.com/thread...pported-macs-discussion.2458481/post-33986181 and link from it?

My summary, is that the team have identified (and listed) major challenges and that this will be a guide for development effort.

 

[deeveedee]

Hello everyone Unfortunately OCPL 3.0 DEV. it doesn't work on Macbook pro 11.1 even the installation doesn't work

While most builds will probably "work", the builds between official releases aren't intended to be tested, working solutions. Definitely feel free to test the DEV build at your own risk, but when they don't work, don't be surprised and wait for the next build.

EDIT: Especially this early in the creation of a new build for a new macOS.

 

[Kamiljarzi]

While most builds will probably "work", the builds between official releases aren't intended to be tested, working solutions. Definitely feel free to test the DEV build at your own risk, but when they don't work, don't be surprised and wait for the next build.

EDIT: Especially this early in the creation of a new build for a new macOS.

Yes I know I know I wrote purely informative

 

[jshayya0184]

Anyone know if the new OCLP branch fixes the "panic stackshot succeeded" error when booting on devices such as the MBA7,2?

 

[deeveedee]

He is talking about Macs that contain a T2 chip. These are the ones that may be most problematic, chances are these machines won’t be able to run Tahoe with OCLP. From the various half-working successes on other older Macs without those pesky T2 chips, it seems not too unrealistic to get them to a usable state in the end. Just let’s wait and see what the devs come up with down the road.

I stand corrected, as it appears you are correct about the T2 challenges faced by the OCLP Devs. I had assumed that since a hackintosh emulating Macs with T2 (e.g., macMini8,1) overcome T2 issues with Open Core (by setting 'Misc > Security > SecureBootModel = Disabled' and revpatch=sbvmm/RestrictEvents.kext) that real Macs would use the same technique. For reasons that I don't understand, that doesn't appear to be the case.

 

[Neon Ball]

I stand corrected, as it appears you are correct about the T2 challenges faced by the OCLP Devs. I had assumed that since a hackintosh emulating Macs with T2 (e.g., macMini8,1) overcome T2 issues with Open Core (by setting 'Misc > Security > SecureBootModel = Disabled' and revpatch=sbvmm/RestrictEvents.kext) that real Macs would use the same technique. For reasons that I don't understand, that doesn't appear to be the case.

In real Macs, many basic things are handled by the T2. It works as an SSD controller, audio device (hence why AppleHDA was yanked, as the remaining models route audio through T2), media encode/decode, Security Enclave Processor (SEP), hardware Root of Trust for Secure Boot and bunch more I may be forgetting. It really is a taste of Apple Silicon on an Intel platform with a lot of tasks offloaded to it.

If the T2 challenge is not remedied, they won't be usable starting from the fact that the SSD won't be accessible at all. It may be possible to circumvent it with an external disk but that's not a good solution.

 

[OKonnel]

Guys, there is excellent news!
@dhinakg, the co-founder of OCLP together with Mykola Grymalyuk (aka @khronokernel) has opened a new Issue in GitHub, yesterday 30 June, concerning the development of OCLP for Tahoe.
Here is the link: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/1167
So far, it has always been Khronokernel that has played this role; but we can well see that Dhinak G is following the same lines.
Therefore, the path of OCLP will continue happily, and let us remember that we all have to be very grateful to all the Developers (@ASentientBot, @educovas, @Jazzzny, @flagers, @Ausdauersportler, @IronApple, @UHDBit, @thatstella7922, @crystall1nedev, @socamx, @Paradox94, @ASentientHedgehog, @Mr.Macintosh and more…) whose credits are listed in the Open Core Legacy Patcher pages and in the Khronokernel’s personal Blog
Khronokernel first valued and esteemed each and every one of them 😍🤩🙏

 

[deeveedee]

If the T2 challenge is not remedied, they won't be usable starting from the fact that the SSD won't be accessible at all. It may be possible to circumvent it with an external disk but that's not a good.

Thank you for the quick reply and helpful explanation!

 

[jshayya0184]

People over on Reddit really have no respect for the devs