Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
This is from FireFox on 26Tahoe, I am going to let it set for awhile before I open OCLP to see if a patch is available, right now it is working just about like an unpatched Seq or Sonoma. After I logged back in from the Tahoe screensaver the Tahoe desktop was there briefly and then disappeared.

I reinstalled OCLP from the Sonoma Dortania folder and when I tried to root patch see the screenshot. Interestingly there is a modern audio patch that doesn't show up when patching Seq or Sonoma. This was done without Python.
 

Attachments

  • Screenshot 2025-07-26 at 3.00.35 PM.png
    Screenshot 2025-07-26 at 3.00.35 PM.png
    198.2 KB · Views: 42
Last edited:
In Beta 3, restoring AppleHDA.kext with "MyKextinstaller V.3" still worked.

In Beta 4, there's no way to restore AppleHDA.kext, so I have no sound on my late 2013 iMac.

Has anyone found a solution for the sound in Beta 4?
 
Strange things happen on the way to the forum: Things were going well with T26B on the test volume, then I thought I would install the latest 3.0.0n, afterwards the mouse and keyboards of both types stopped working and a message appeared that blue tooth was turned off. I tried reverting patches from another volume, no change.

edit: Erased 26test, started anew.
 

Attachments

  • IMG_1612.jpeg
    IMG_1612.jpeg
    214.6 KB · Views: 19
Last edited:
  • Like
Reactions: RogueB
Hello to all,

It would be remiss not to acknowledge risks inherent in experimenting with nightly OCLP software, and any warning to that effect should be fully appreciated. However, once risks are understood, and potential fallout is limited to the person’s own, non-mission-critical computer, said experiment becomes an exercise in discovery. The benefits of the latter often far outweigh the fall-out from “misadventure”, notably, when playing in one’s own “sandbox”; suo periculo doctrine applies.

iMac 13,2 metal capable :

Installed Tahoe 26 beta4 OTA over Tahoe beta3 on an external SSD. Used OCLP nightly 3.0.0 from July 1st. Slow process, but eventually reached the login screen and then desktop; keyboard and trackpad were fully active. There is a significant system overhead, as evidenced by the Activity Monitor, presumably due to “liquid glass” requirements. “Iconserviceagent” takes over CPU cycles, and becomes even more insidious, when a new window is opened and the system attempts to render application icons within. It took a long time before Dock was displayed, but eventually it appeared and was fully functional.

Operationally, while running beta4, when clicking on icon to start an application there is a significant delay, and sometimes process stalls. However, when tapping with two fingers on icon to activate drop-down menu, then choosing “open” command, the target launches relatively fast, and does not stall. This lag improves dramatically when post-install internal processes complete.

What works: Bluetooth and hence keyboard and track pad. Ethernet is fully functional and Internet can be accessed without issues, camera works, LAN is functional via Ethernet. All native applications, which do not require sound input-output or absolute Metal, launch and work as expected. Tahoe 26 beta4 is actually very “snappy” once background processes are completed, however, it does take a while (CPU dependent). Subjectively, some desktop responses appear to be faster than same actions on accelerated Sequoia.

What doesn’t work: there is no “Graphic Acceleration” , no WiFi, no sound input-output. Fusion Drive (an HDD) is not visible on desktop when booted into Tahoe, and Tahoe installer does not recognize (an internal) fusion HD. That “behavior” was also reported by other posters.



MacBooK Pro 5.2 (Non-Metal reference machine) - an external keyboard and mouse, routed through USB hub, were used throughout the process. Ethernet was used for internet and LAN connectivity.

I was previously able to install Tahoe beta 2 onto an internal SSD drive, with very encouraging results (see post #305)
However, Tahoe beta 3 was not installable on either internal or external SSD, no matter the release date of OCLP 3.0.0 used or Sequoia version underlying the process.

Finally, release of Tahoe developer beta 4 made it possible to install Tahoe on both, an internal and external SSDs. Used OCLP 3.0.0 from July 1, 2025, Each drive had Sequoia 15.6 beta4 pre-installed before Tahoe update.

Tahoe Beta4 installer was downloaded from Mr.Macintosh site (or via OCLP function), and extracted onto an internal and external drives, each operating under Sequoia 15.6 beta4. Thereafter, OCLP 3.0.0 nightly (July 1, 2025 version) was installed on both SSD drives, and, in addition, on a USB thumb drive housing an additional Tahoe beta4 installer.

External SSD installation:
Tahoe beta4 installer was launched from a Sequoia 15.6 beta4 volume, on an external SSD, targeting “itself” for update.
Installation took an extended period of time, but did complete, and presented a login window with an active external keyboard and mouse. Past password entry, it took a very long time for fully functional desktop to stabilize and allow applications to be launched.

Internal SSD installation:
Booted from a USB thumb drive and launched installer in usual manner. Again, as with external drive, it took long time to reach login widow, but when reached, both, keyboard and mouse were active, and it was possible to enter password.
It took a very, very long time to reach fully functional desktop, but eventually it was possible to launch applications and access internet, etc.

What works:
Applications launch and are active if, sometimes, at glacial speeds (Note: applications relying on metal support or sound are not fully functional). Ethernet (WAN) and LAN are fully active.

What doesn’t work:
There is no Graphics Acceleration, no Bluetooth or WiFi, and there is no sound input or output (as expected due to lack of patches).

Oddly, OCLP 3.0.0 release from 7.14.25 (macOS-next branch with USB mapping) did not work on my machine; it resulted in failed install due to apparent problems with USB port “enumeration”. See a screen shot of the installation log (attached below).

Not sure of what changed in Tahoe Beta 4 release to allow installation, but it was more forgiving of OCLP intervention than Beta3.

It was encouraging to see positive positive results achieved by @hvds, @deeveedee, @renton and others, which served as background to the Tahoe installation on legacy non-metal machines. Building OCLP from source does seem to produce versions of OCLP better matched to non-metal machines.

Overall, an encouraging sign of progress thanks to developer teams and this forum’s members.

Hope this entry may be of help.

MacBook Pro 5,2   Tahoe B4 internal.png
MacBook Pro 5,2. Tahoe desktop on the internal drive.

MacBook Pro 5,2 Tahoe B4 external.png

MacBook Pro 5,2 Tahoe desktop on external drive

Screenshot 2025-07-28 at 10.43.44.png

Error codes OCLP 3.0.0 nightly, July 14 build from macOS-next developer branch.
 
Last edited:
In Beta 3, restoring AppleHDA.kext with "MyKextinstaller V.3" still worked.

In Beta 4, there's no way to restore AppleHDA.kext, so I have no sound on my late 2013 iMac.

Has anyone found a solution for the sound in Beta 4?
Install KDK_26.0_25A5279m
mkdir ~/livemount
diskutil list
sudo mount -o nobrowse -t apfs /dev/disk(tahoe partition) ~/livemount
sudo ditto /Library/Developer/KDKs/KDK_26.0_25A5279m.kdk/System ~/livemount/System
sudo touch ~/livemount/System/Library/Extensions
sudo kmutil create --allow-missing-kdk --volume-root ~/livemount --update-all --variant-suffix release --no-authentication --no-authorization
sudo bless --folder ~/livemount/System/Library/CoreServices --bootefi --create-snapshot
 
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:
Code:
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.
 
  • Like
Reactions: Oxygen-X1
Install KDK_26.0_25A5279m
mkdir ~/livemount
diskutil list
sudo mount -o nobrowse -t apfs /dev/disk(tahoe partition) ~/livemount
sudo ditto /Library/Developer/KDKs/KDK_26.0_25A5279m.kdk/System ~/livemount/System
sudo touch ~/livemount/System/Library/Extensions
sudo kmutil create --allow-missing-kdk --volume-root ~/livemount --update-all --variant-suffix release --no-authentication --no-authorization
sudo bless --folder ~/livemount/System/Library/CoreServices --bootefi --create-snapshot
I was able to solve the sound problem on the late 2013 iMac.
With labobamac's SimplyLoader 1.0.1, now also available in English.
Will there ever be full graphics support for NVidia Kepler graphics cards?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.