[Test Report] MacBookAir8,1 (T2) – Why "Dirty" Cover Install is the Only Way to Bypass Early PMU Deadlock
Device: MacBookAir8,1 (2018, T2 Security Chip)
Tool: OpenCore Legacy Patcher T2 (v4.0.0.190009.7)
Target OS: macOS 26 Tahoe
Summary:
I conducted two days of testing on MacBookAir8,1 to compare a "dirty" cover install versus a clean install. The critical finding is that a "clean" install fails immediately at the PMU clock sync stage. Only a "dirty" cover install (overwriting an existing system volume with complex Preboot residues) can bypass T2's early boot validation and reach the graphical Login Window.
Day 1: The "Mistake" That Proved the Only Way Forward
• Setup (Dirty Environment): The target volume was created locally (no USB) and had a complex history: downgraded to Ventura, then upgraded to Sonoma. This left heavily mixed Preboot environments and security certificates. macOS 26 was then installed directly over this volume.
• Result: The installer completed Stage 1. The system successfully loaded the graphical Login Window. However, upon entering the password, the kernel panicked due to AppleKeyStore timeout (launchd infinite loop).
• Feasibility Analysis: If I had performed a clean install on Day 1 instead of this cover install, the system would never have reached the Login Window. It would have crashed early at the PMU stage (as proven on Day 2). Thus, the "dirty" cover install is currently the only viable method to bypass the early T2 boot validation.
Day 2: The Reality of Clean Install (Pure Environment)
• Setup: Created independent partitions (Installer HFS+ and Tahoe-Test APFS) and executed Reset NVRAM.
• Result: The system failed much earlier. It stalled at using hsynchronous pmu monotonic clock read and entered a launchd deadlock. The graphical installer was never reached.
• Implication: Without legacy Preboot residues to trick T2, the hardware strictly blocks PMU clock synchronization.
Additional Observations:
• Bypassing OpenCore: Booting natively triggers Apple's installer whitelist ("macOS Tahoe is not compatible with this Mac").
• SMBIOS Spoofing: Not feasible in the current OCLP-T2 UI.
Conclusion & Suggestion:
The T2 security chip remains a hard physical lock. The "dirty" cover install proves that the UI and core OS are fully compatible once early validation is bypassed. Future development should focus on dynamically generating or replaying a legitimate Preboot environment (mimicking the dirty state) to bypass the early PMU deadlock, while simultaneously addressing the final AppleKeyStore key exchange during user authentication.
Comments
@albert-mueller ·
@zkennedy137 @gandolf243 @matteoiacca
@Skjen-911 ·
Are there currently any reports of someone successfully upgrading a 2018 MacBook Air with a T2 chip to macOS 26 Tahoe?
@albert-mueller ·
Currently there are reports that it doesn't work yet on T2 Macs (at Stage 2 it gets stuck).
@Skjen-911 ·
Thanks @albert-mueller! Hope it gets working soon. As a MacBook Air 2018 user, I'll keep following the progress, test the installs, and provide feedback!
@albert-mueller ·
@Skjen-911 ·
Thanks for the new photo showing the Privacy/Terms page.
Just to clarify: does this mean your current test progress has only reached this specific page so far?
I want to share a crucial detail from my Day 1 test (using the older .7 version with a dirty cover install): I actually bypassed the installation phase completely and successfully downloaded all the system files. My machine even reached the final macOS 26 graphical Login Window (the password entry screen).
However, the moment I entered my password, the system instantly panicked, threw a screen full of verbose code, and triggered a kernel panic, locking up completely.
I am sharing this to let you know that the software deployment and UI rendering can work, but the final authentication step is where the T2 completely blocks us. I will test 19.9.9 with a clean install as soon as I am back to see if your new T2Fixup changes this behavior!
@matteoiacca ·
@albert-mueller @zkennedy137 @gandolf243 @Skjen-911
Seeing @Skjen-911 reach the graphical login window on the MacBookAir8,1 is awesome news. It proves GPU acceleration, WindowServer, and the core OS are running fine on T2 once early boot checks are out of the way.
Here is what is happening and how to get past both stops:
using synchronous pmu monotonic clock read:On a clean drive with reset NVRAM, the T2 chip does not have the legacy Preboot/LocalPolicy data it expects, so it ignores the clock sync requests and the boot hangs. On a dirty install, those older Preboot files are still there from Ventura/Sonoma, so the T2 is happy and lets it boot right through. To fix this for clean installs, we just need OCLP to copy or preserve that legacy Preboot folder onto the target volume.
When you type your password, macOS asks the T2 SEP to unlock the account. But the older T2 BridgeOS cannot handle Tahoe's new protocol, so it sits there waiting until it hits a 5-strike timeout and panics the kernel (
AppleKeyStore timeout).How to fix it:
T2TahoeFixup(v1.0.2) so login processes (loginwindow,opendirectoryd, etc.) use software password derivation instead of calling the hardware SEP, exactly like macOS does inside a VM. I also hookedAppleKeyStoreso it skips the SEP endpoint and never triggers the timeout panic.aks-endpoint=0to your OpenCoreboot-args. AppleKeyStore natively checks for this boot-arg and skips waiting on the SEP.This should let the password login pass right through into the desktop.
T2TahoeFixup-1.0.2-Release.zip
@Skjen-911 ·
Incredible explanation! Everything makes perfect sense now.
I just found all the original photos from my Day 1 and Day 2 tests. I am attaching them to this reply as additional evidence so you can see the exact crash states.
I'm currently away from my Mac, so I will take some time to digest your notes first. As soon as I'm back, I will apply the new v1.0.2 patch and the aks-endpoint=0 boot-arg, and run the test.
I'll report back with the new logs and results. Thanks again for the lightning-fast fix!
@Skjen-911 ·
I just remembered another crucial observation that might be very helpful for the project!
Today, I used
EFI Boot(OpenCore environment) to boot my existing Sonoma partition. I wanted to simulate what the hardware status might be like if we successfully reach the macOS 26 desktop.The result was incredibly promising: Both Wi-Fi and Bluetooth modules were working perfectly normally! The only thing that failed was the GPU acceleration (the system lost the glassmorphism/liquid glass rendering effects and had abnormal resolution).
This proves that the network and Bluetooth kexts injected by OCLP-T2 are fully functional under the T2 spoofing environment. It means once we bypass the login window into macOS 26, we probably only need to worry about the Root Patch for the GPU!
@albert-mueller ·
Thanks! Since my SSD runs 26.5.2, I’ll need to update to 26.7.1 and try again. It will take some time before I can booting from the external SSD.
@zkennedy137 ·
You almost assuredly were booting into the volume for file-vault. Even if not enabled you can boot this partition and it will give the illusion of a login screen. It is just to enter your password for file-vault. It would freeze immediately after you enter the password and leave the screen stuck with the “login screen” and then possible shutdown from a panick. @Skjen-911
@matteoiacca ·
@zkennedy137 @albert-mueller
Thanks for the feedback! To clarify on the FileVault theory:
It definitely wasn't the EFI pre-boot FileVault screen. Here is why:
boot.efipasses control directly to/System/Library/Kernels/kernel.launchd(PID 1) was active, root was mounted read-only with the signed system snapshot,WindowServerhad launched with full resolution handling, and the Cocoaloginwindowprocess was actively rendering the UI.panic: "sks request timeout (5 strikes)"originating fromcom.apple.driver.AppleKeyStore.In an EFI pre-boot FileVault unlock, the macOS kernel isn't even in memory yet, so an IOKit kernel panic like this is physically impossible.
Why AppleKeyStore was called even without FileVault:
Even with FileVault off, macOS always protects the user keychain/dataprotection via a local User Keybag (
/var/db/keybags/). At the graphical login window,loginwindowandopendirectorydsubmit the password toAppleKeyStoreto unwrap this keybag. On T2 Macs,AppleKeyStoredefaults to delegating this to the T2 Secure Enclave (SEP) via mailbox IPC. Because BridgeOS doesn't reply with the expected Tahoe response,AppleKeyStoretimes out 5 consecutive times and halts the kernel.That's why hooking
AppleKeyStore::expect_sep_firmware_to_be_loaded() -> falseinT2TahoeFixupv1.0.2 (or settingaks-endpoint=0) solves this: it forces software keybag derivation (just like macOS does in a VM) and bypasses the SEP strike panic entirely.@albert-mueller Take your time updating to 26.7.1! Looking forward to your results with the external SSD once you're ready.
@Skjen-911 ·
@zkennedy137 @matteoiacca Just to add one more visual detail from my Day 1 test, to fully confirm @matteoiacca's theory.
I remember exactly what that login screen looked like, even though I didn't take a photo. It was definitely the macOS graphical Login Window, but severely unaccelerated.
Here is what I saw:
@Skjen-911 ·
I just want to mention that I'm located in Asia, so there is a significant time zone difference (around 12 hours) between us. Also, English is not my native language, so please excuse any awkward phrasing in advance.
I am currently quite busy and apologize if I can't reply or test immediately. But I will definitely try the v1.0.2 patch and the
aks-endpoint=0boot-arg as soon as I have time, and I will get back to you with the results.