macOS Tahoe 26 on Unsupported Macs Discussion

[houser]

@houser >> If OCLP novices don't learn the dangers and risks of "unofficial" versions from here, they may never know. Agree that we shouldn't promote or provide testing status of the "3d party knock-offs," >>

Just a short comment. I see your point on this, and I think the focus can probably be less on education and cavalier behaviour from users and more on keeping this little community useful. The thread format here is also not well suited to education IMHO and this is pretty well illustrated by your exchange with a newbie a few posts back
"LLM-tweaked" versions of code is already rampant in some places and to inject malicious code into a version of OCLP that way is not getting harder to do.
Ah well.
I also think coddling the 3d-party knock-offs (if that is what this is) and conflating them with the real thing here might be a pretty good way to lose the occasional valuable presence of the devs here.
/my 2 cents and end of rant.

 

[olad]

Just a short comment. I see your point on this, and I think the focus can probably be less on education and cavalier behaviour from users and more on keeping this little community useful. The thread format here is also not well suited to education IMHO and this is pretty well illustrated by your exchange with a newbie a few posts back
"LLM-tweaked" versions of code is already rampant in some places and to inject malicious code into a version of OCLP that way is not getting harder to do.
Ah well.
I also think coddling the 3d-party knock-offs and conflating them with the real thing here might be a pretty good way to lose the occasional valuable presence of the devs here.
/my 2 cents and end of rant.

A worthwhile rant 👌

 

[hackintosh_user]

The 3.0.0 release is definitely not happening this year but maybe, just maybe, macs from 2012-2017 could get root patches as nightly but most likely next year.

This is just my opinion but if people are expecting Tahoe to run well on most unsupported macs, they'll be very disappointed. In my experience, it feels considerably slower than Sequoia.

@educovas Just a question, 2012 Macs ( intel ivy and Haswell + Kepler) need metallibsupportpkg if I'm not wrong, and the last one was released in August for Sequoia 15.6.1 so would we see a pre-release for that in the case of Metal 3802 Gpus getting nightly root patches? ( also Great work massive respect to all of you I must say.)

 

[Sven G]

Has the GoldenGate OpenCanopy icon set included in OCLP been updated to include Tahoe devices (just curious to see how they will look)…? Probably not, yet (at least, not in any nightly, so far)…

 

[Anonymous Freak]

PurgePendingUpdate?

From what I've read, there seems to exist an OCLP tool called "PurgePendingUpdate" that supposedly helps to prevent the consequences of inadvertent, automatic upgrades to Tahoe caused by too-clever recent releases of Sequoia. The tool is said to exist somewhere in the Discord servers. Unfortunately, I've been unable to locate it. Can someone shed further light on this issue or share a verified download link?

Well, crap. I could have used that. Upgraded RAM in my 2013 Mac Pro that I use as a VM server, saw "OS update", went to apply, only to my horror realize it was upgrading to Tahoe, not installing the Sequoia update.

Now it's too late, and my "primary†" OS on it is Tahoe. USB is borked, I have to plug in a Thunderbolt 3 dock and use its USB3 ports for keyboard and mouse, Bluetooth is broke because its on internal USB, and networking doesn't work. Onboard Ethernet is detected but doesn't think it's plugged in (I use both ports, neither thinks it's plugged in.) The TB3 dock's Gigabit Ethernet controller doesn't even show up under "PCI" like it does on a supported OS.

And of course graphics are painfully slow. (Not that it matters - since I use this machine headless 99% of the time.)


† I also have a "last supported OS" Monterey install dual-boot for troubleshooting.

 

[PeterHolbrook]

^It seems you need to reinstall Sequoia. If you haven't done so yet, I can suggest a possible pathway towards an in-place reinstall that does not require the full erasure of the disk, provided you have a valid backup of a recent Sequoia /System/Library/CoreServices/SystemVersion.plist. I discovered this on my own a few weeks ago. This is what I did using the Terminal on a secondary Sonoma boot volume.

1. Make sure SIP is off
2. Mount your main SSD (failed Tahoe install) as a writeable volume.
3. cd to /System/Library/CoreServices
4. Erase SystemVersion.plist. I also erased SystemVersion.bundle, but I'm not sure that was actually required
5. cp your valid SystemVersion.plist to /System/Library/CoreServices. I also copied (with -R) SystemVersion.bundle, but that might have not been necessary.
6. Now you can reinstall (from Sonoma in my case) the same or a later release of Sequoia on top of the spoofed version of your failed Tahoe install. In my case it took nearly one hour, but everything worked just fine. I didn't need to restore apps or my data, as everything was in place as it was supposed to be.

Good luck!

EDIT: rm and cp ought to be preceded by sudo, naturally, if run from the Terminal of a full operating system, such as Sonoma (as opposed to the Recovery environment of macOS).

 

[houser]

>>. If you haven't done so yet, I can suggest a possible pathway towards an in-place reinstall that does not require the full erasure of the disk, >>

Thanks for this interesting tip, might well come in handy.
So I assume this is mainly intended for when you don't have a complete backup and need to downgrade MacOS?
Can we also assume it might work with OCLP as well as without?

 

[PeterHolbrook]

Thanks for this interesting tip, might well come in handy.
So I assume this is mainly intended for when you don't have a complete backup and need to downgrade MacOS?
Can we also assume it might work with OCLP as well as without?

Absolutely, both things are true.

 

[deeveedee]

... have a valid backup of a recent Sequoia /System/Library/CoreServices/SystemVersion.plist.

I just saved my SystemVersion.plist just in case . Thanks!

I inspected SystemVersion.plist and don't see anything in it that is system-specific. For those who don't have this saved, can SystemVersion.plist from another Sequoia instance be used? I think that's what you implied, but just wanted to confirm. Thanks again.

 

[PeterHolbrook]

I just saved my SystemVersion.plist just in case . Thanks!

I inspected SystemVersion.plist and don't see anything in it that is system-specific. For those who don't have this saved, can SystemVersion.plist from another Sequoia instance be used? I think that's what you implied, but just wanted to confirm. Thanks again.

I actually used a Sequoia SystemVersion.plist copied from my son’s iMac. Editing the plist itself, or creating it from scratch, is equally possible, provided you know what you’re doing.

 

[Anonymous Freak]

^It seems you need to reinstall Sequoia. If you haven't done so yet, I can suggest a possible pathway towards an in-place reinstall that does not require the full erasure of the disk, provided you have a valid backup of a recent Sequoia /System/Library/CoreServices/SystemVersion.plist. I discovered this on my own a few weeks ago. This is what I did using the Terminal on a secondary Sonoma boot volume.

1. Make sure SIP is off
2. Mount your main SSD (failed Tahoe install) as a writeable volume.
3. cd to /System/Library/CoreServices
4. Erase SystemVersion.plist. I also erased SystemVersion.bundle, but I'm not sure that was actually required
5. cp your valid SystemVersion.plist to /System/Library/CoreServices. I also copied (with -R) SystemVersion.bundle, but that might have not been necessary.
6. Now you can reinstall (from Sonoma in my case) the same or a later release of Sequoia on top of the spoofed version of your failed Tahoe install. In my case it took nearly one hour, but everything worked just fine. I didn't need to restore apps or my data, as everything was in place as it was supposed to be.

Good luck!

EDIT: rm and cp ought to be preceded by sudo, naturally, if run from the Terminal of a full operating system, such as Sonoma (as opposed to the Recovery environment of macOS).

Note to self: start backing up SystemVersion.plist.

(This wasn't an important enough system to back up. It was my "goof around with" system, I had *JUST* started to use it as a server, and hadn't put anything truly important on it yet.)

 

[sinbad21]

I actually used a Sequoia SystemVersion.plist copied from my son’s iMac. Editing the plist itself, or creating it from scratch, is equally possible, provided you know what you’re doing.

What about BuildID key? No importance?

 

[PeterHolbrook]

What about BuildID key? No importance?

Never did I intimate that the values of the keys within SystemVersion.plist could be random or invented. In my limited experience, the only critical keys that probably disallow system downgrades are ProductUserVisibleVersion and ProductVersion. If you make the system volume writeable and use a valid editor, changing the relevant strings to something like "15.7.2" will bypass the installer limitation that disallows downgrading the installed version of macOS. I don't know what the result would be if one were to randomly change the string values of other keys, such as BuildID, ProductBuildVersion or iOSSupportVersion. My hunch is that would not matter if reinstall were to follow immediately, as SystemVersion.plist would be entirely overwritten by the installer itself.

 

[deeveedee]

Never thought I'd be so excited to see new activity and a visit by dhinakg in the OCLP repo.