macOS Tahoe 26 on Unsupported Macs Discussion

[Oxygen-X1]

If you tell me which graphics card you’re using and whether you’re working with Hackintosh tools (Clover/OpenCore, WhateverGreen, Platform IDs), I can help you determine if and how QE/CI can be enabled.

Thanks for the effort but I don't do Hackintosh. The AMD Radeon, will do a fine job when the Devs have everything in place, I will wait for that, in the meantime for everyday use T26 is fine for my needs, I even find it to be very quick in Firefox, I do not use this computer for work. I did find out that launchpad has been replace with "apps", it opens but then quickly disappears, that does not bother me because I never use it, the finder menu bar is fine.

Thanks for your offer to help me figure out if QE/Ci works on my nVidia (Kepler chipset).
I already know that it doesn't!! work, just like your AMD Radeon not work.

And your AMD Radeon will work fine once the developers have everything set up,
or they'll never get it done! I'm still waiting for that... Me too.

And I don't use a Hackintosh! You should check out my signature.

 

[HippoInWindow20]

Note: feel free to correct me on anything here, this is just from my own testing and investigation.

I've done some testing with Tahoe on a 2018 MBP (MacBookPro15,1). OCLP is not an option, since the 2018 was never unsupported before and OCLP hasn't been updated yet. So I went with OpenCore and some very basic spoofing. My goal is spoof to 16,1 and see what happens.

RECOVERY
My first attempt was recovery. Booting into recovery directly through OpenCore is not possible. Instead, you have to manually attempt to boot it without OC, which will initiate an iBridge update. After iBridge updates, Tahoe Recovery can be booted through OpenCore with no issues on 15,1. WiFi, external display, SSD, etc. all work fine.

INSTALLATION
Then there is a huge blockade: macOS Installer. Since I did not hide my T2, the installer checks for this multiple times during installation:

1. When you click Continue on the first page
2. After extracting SharedSupport.dmg
3. After extracting the payload .aea file
4. After extracting the actual BaseSystem
5. During first reboot phase

These errors occur due to a personalization step in the installer. When it sees the T2, it checks the plists to see if any extra work needs to be done during installation to accommodate for it (eg. update iBridge). By manually extracting SharedSupport and changing all references to the MBP16,2 chip (J152FAP) to the 15,1 one (J680AP), the first two checks are circumvented.

The third check is a bit different, though. The aea file is signed, so you cannot modify it beforehand. This can be circumvented, but requires precise timing. You have to manually patch the plists after the installer extracts them to temporary directories, but before the installer reads them. From testing, you have about 10-15 seconds to do this.

I have not been able to get past the last two checks. They seem to be in plist files deep into the installer and I have not found a way to fix this.

BOOTING FULL OS
After fumbling with the installer for way too long, I decided to just use another Mac to preinstall the OS on an external drive. macOS supports booting from external media, so this is fine. Unfortunately, this was unsuccessful. The system attempts to boot but fails while searching for the root device. More specifically, the APFS driver cannot verify the system image. I have no idea why this happens.

On Macs without T2, the same external SSD works fine for booting Tahoe (even on 9,1!). But it seems that T2 Macs file system verification works a bit differently. I think the OS expects a root hash from UEFI, but OpenCore does not provide one. The APFS driver receives null data, and subsequently panics with the following message:

panic(cpu 0 caller 0xffffff801f441676): "The global payload bytes pointer is NULL\n" @apfs_vfsops.c:2736

MY EXPECTATION
In Recovery, ioreg properly shows all hardware. It also seems to have attached all drivers. Considering that, I fully expect Tahoe to be possible on this Mac. The APFS issues seem like they are solvable, as long as it is possible to provide the data the OS expects on boot for filesystem verification.

Okay that explains why I didn't got it to work on a 2019 13-inch (MacbookPro15,4). Looks like the APFS Driver panic is T2-related.

panic(cpu 0 caller 0xffffff80096489ce): "The global payload bytes pointer is NULL\n" @apfs_vfsops.c:2738