OCLP T2

Deutsch

English

Deutsch

English

Erscheinungsbild

← Alle Issues

[Bug]: Older RestrictEvents version causes when pressing ->, WindowServer to fail to draw the next screen on unsupported T2 Macs

· von @jakecaley

bug

Mac model / Mac-Modell

T2 — MacBook Pro 13-inch (2020, 2 thunderbolt 3 ports, Intel)

Target macOS version (if it is about malicious forks, typosquatting sites or security vulnerabilities, write - instead) / macOS-Zielversion (falls es um Typpfehler-Webseiten, Typpfehler-Repository oder Sicherheitslücken handelt, schreiben Sie stattdessen ein - )

mac os thaoe 26

OpenCore Legacy Patcher T2 version (Please state the version clearly, not state as version new or something. / Bitte die exakte Version nennen, nicht nur etwas oder neu.)

i always update when avalible

Issue type or recommendation / Typ Fehler oder Empfehlung

Installer error / Installationsfehler

Description / Beschreibung

after the new update the tahoe installer actually boots on the macbookpro16,3 (Thanks devs). theres still one isue. for some reason clicking on install mac os tahoe for some reason says this mac isnt compatible. i feel like its something with restrictevents.kext bc when i boot in verbose i notice before it even tries to load the mac os installer it says something about restrict events. i will post a log when i get one

Steps to upload the logs of the kernel panic if any (if not, you can skip this step or write -) / Schritte zum Hochladen der Protokolle des Kernel-Panics, falls vorhanden (falls keiner, dann Sie können das überspringen oder einen - schreiben)

No response

Panic log (if any) / additional notes (if any) / Panikprotokoll (falls einer) / zusätzliche Notizen (falls einer)

Kommentare
@friendlycatt · 
Yeah the issue is related to restrictevents i think medelcartelinc said in #327 this post that he is working on it , also how did you pass language section ? Mine is freezing everytime i press ->
@jakecaley · 
@friendlycatt new version should fix that issue they patched it to fix that on t2 Mac’s
@Medelcartelinc · 
@jakecaley @friendlycatt


You are completely spot on about the cause @jakecaley. The 13-inch 2020 MacBook Pro (MacBookPro16,3) carries board identifier J223AP, and Apple removed it alongside the 2018 and 2019 models from Tahoe's SupportedDeviceModels catalog. When you click Install macOS Tahoe, the background daemon osinstallersetupd queries the sysctl hw.targettype and rejects the machine with a compatibility error.


We diagnosed this exact failure path in Issue #327 and just submitted PR #331 to Albert's repository. The fix updates RestrictEvents so that sysctl queries from osinstallersetupd report a supported T2 board identifier (J680AP) and automatically injects -revbeta revpatch=sbvmm into the T2 boot-args. As soon as Albert merges PR #331 or provides an updated test build, your MacBookPro16,3 will bypass that check cleanly and allow the installation to proceed.


Regarding @friendlycatt's question about the language selection screen, that stall happened on earlier builds where the installer UI transitions hung waiting on graphics and input event queues, but updating to the latest EFI build with aligned APFS and boot-args allows the arrow click to advance into the recovery utility menu.
@jakecaley ·  · bearbeitet
@Medelcartelinc thanks im having issues getting it to boot into the installer and stay on. may be my issue bc for some reason it keeps on auto trurning on sip again i may just have to reset the nvram in the opcore menu for it to boot for all i know. it will boot for like 2 secs then lock up sounds like nvram issue im going to wait until what you said is going to happen with restrictevents is officaly released. i also cant turn on nvram flash because it makes my real sequioa install kernel panic
@Medelcartelinc · 
@jakecaley


That is extremely valuable feedback regarding WriteFlash. On T2 portables like the MacBookPro16,3, BridgeOS arbitrates NVRAM storage, and forcing direct SPI flash commits via WriteFlash=True conflicts with Apple's runtime NVRAM driver in Sequoia and triggers a kernel panic. We should avoid forcing WriteFlash globally on all T2 configs for that exact reason.


Regarding SIP reverting and the lockup after two seconds, T2 hardware resets NVRAM keys on reboot unless OpenCore continuously injects them on every startup. Resetting NVRAM from the OpenCore boot picker will clean out stale runtime entries and get you back into a clean state, and using -amfipassbeta in boot-args ensures AMFI remains bypassed without needing permanent NVRAM flashing. Waiting for the RestrictEvents target-type release will give you the complete and clean installer pass-through without triggering these NVRAM panics.
@jakecaley ·  · bearbeitet
ok thanks @Medelcartelinc.
@Medelcartelinc · 
@jakecaley


To clarify on Albert's specific procedure for T2 Macs: if you need to perform the initial security bypass, you should do it once from your Mac's native Recovery (holding CMD+R on boot without OpenCore). In native Recovery, make sure Secure Boot is set to No Security in Startup Security Utility, and in Terminal run  and .


Once that baseline is saved in native recovery, reboot through OpenCore. You do not need to touch or run csrutil inside the Tahoe installer itself, as OpenCore handles the active CSR state from that point forward.
@jakecaley · 
@Medelcartelinc was the command csrutil disable I can’t see the command you gave me
@Medelcartelinc ·  · bearbeitet
@jakecaley


Yes, the exact commands to run in Terminal while booted into native macOS Recovery (CMD+R) are:


First command: csrutil disable

Second command: csrutil authenticated-root disable


After running both commands and confirming that Secure Boot is set to No Security inside Utilities > Startup Security Utility, reboot your Mac and select OpenCore from the boot menu.
@jakecaley · 
@Medelcartelinc idk if it’s because I’m viewing it from a phone but it keeps on doing this

Image
@Medelcartelinc · 
@jakecaley


The terminal shell stripped the command strings out when posting earlier. The exact text is:


First command: csrutil disable


Second command: csrutil authenticated-root disable


Run both of those in native Recovery Terminal, make sure Secure Boot is set to No Security, and reboot into OpenCore.
@jakecaley · 
@Medelcartelinc now it shows up thanks
@albert-mueller ·  · bearbeitet
https://github.com/albert-mueller/OpenCore-Legacy-Patcher-T2/releases/tag/4.0.0.18009 - can you try this release? It should fix exactly this issue, thanks to @Medelcartelinc .

@friendlycatt @jakecaley
@jakecaley · 
@albert-mueller well i can boot into the installer but now i have the unsupported when trying to install it although i have verbose boot enabled and it says before it boots restrictevents.kext invalid parameter
@jakecaley ·  · bearbeitet
i could try making propertree look at the oc folder again @albert-mueller @Medelcartelinc
@jakecaley · 
opencore-2026-09-10-222518.txt @Medelcartelinc @albert-mueller  this is weird i looked in the config.plist theres nothing invalid in there
@Medelcartelinc · 
Hi @jakecaley, you hit the nail on the head! The RestrictEvents.kext in the latest release was missing a few essential symbols (_kmod_info), which caused the kernel to reject it during boot-time injection on T2 Macs. That is exactly why the installer was falling back to reporting the Mac as incompatible.


We've just manually re-compiled the kext with the correct linker flags to fix the missing symbols and pushed the working payload to a pending Pull Request. Once that PR is reviewed and merged into the main branch, a new build will be triggered and the Tahoe installer will properly bypass the hardware check again.


Thanks for testing and for pointing us exactly to where the issue was occurring!
@jakecaley · 
@Medelcartelinc yeah I had a feeling bc I tried getting it from online and replacing it and that caused it to do the language menu thing again so I knew that it had something to do with it
@Medelcartelinc ·  · bearbeitet
Hey @jakecaley,


I've put together a test build that includes the RestrictEvents kmod fix (to resolve the _kmod_info panics on Tahoe) along with the other recent fixes.


You can download it from my fork here so you can start testing immediately without having to wait for Albert to merge the PR. Since you mentioned you needed the PKG files rather than the standard ZIP build, I've compiled them for you:

https://github.com/Medelcartelinc/OpenCore-Legacy-Patcher-T2/releases/tag/tahoe-test-jake-v2


Download the OpenCore-Patcher-T2.pkg asset and you should be good to go. Let me know how it goes or if you run into any other weird panics with this build!
@jakecaley · 
@Medelcartelinc thank you so much i will test it rn
@jakecaley ·  · bearbeitet
Image it kernel panicked @Medelcartelinc also resetting nvram does the same thing
@jakecaley · 
Image here’s a less blurry photo @Medelcartelinc
@Medelcartelinc · 
Hey @jakecaley, thanks for the clearer photo! I can see it's panicking exactly at the __start symbol of RestrictEvents. This was caused by an issue with how the spoofed kext was manually built for this specific test, causing a page fault when it tried to load some C++ initializers. We've completely rebuilt the kext with a cleaner entry point now.


I have uploaded a v3 build that has this fixed. Could you please test it? This should definitely bypass the panic!

Download link: https://github.com/Medelcartelinc/OpenCore-Legacy-Patcher-T2/releases/download/tahoe-test-jake-v3/OpenCore-Patcher-T2.pkg
@jakecaley · 
@Medelcartelinc of course i got you i will try this
@jakecaley · 
@Medelcartelinc did he just release a new version
@jakecaley · 
@Medelcartelinc it says it fixes the issue with the kext do you still want me to try yours?
@Medelcartelinc · 
Let us know how the v3 test goes! We are heading to sleep now, so if there are any issues we'll take a look at it tomorrow.


Also, just a quick heads up: Albert just posted a new release (4.0.0.18009.1), but please note that his release is actually older than the v3 build we just sent you (it doesn't include this specific RestrictEvents fix for the Tahoe installer page fault). Make sure you test with the v3 PKG linked above!
@jakecaley · 
@Medelcartelinc if u see this it’s a different krnl panic


Image I will try the offices build now
@jakecaley · 
@Medelcartelinc


Image if you also see this this is the official build I’m pretty sure is the same krnl panic as before
@Medelcartelinc · 
@jakecaley Ah, thank you for testing the v3 build and providing the screenshot!


You're right, the 18009.1 official build and our v3 build failed for slightly different reasons, but they both stem from the same root issue. To fix the original __start panic you experienced, we removed the standard libkmod C++ library from the kext. However, doing so caused a new issue: the C++ global objects didn't get initialized, resulting in the wild deref memory panic you saw in v3!


I've spent some time writing a custom C++ initialization caller that safely bypasses the Tahoe page fault while properly setting up the kext. This should permanently resolve both panics.


I've just compiled a brand new v4 test build with this correct initialization logic!

Could you please test the OpenCore-Patcher-T2.pkg from the tahoe-test-jake-v4 release here?

https://github.com/Medelcartelinc/OpenCore-Legacy-Patcher-T2/releases/tag/tahoe-test-jake-v4


Fingers crossed this is the final fix!
@jakecaley · 
@Medelcartelinc sorry i was gone but im back ill test it out rn
@jakecaley · 
@Medelcartelinc kernel panic again but may be something on my end trying some stuff to fix it rn if it Dosnt work I’ll send a image
@jakecaley · 
Tried it again is this the same kernel panic?

Image
@jakecaley · 
@Medelcartelinc is there any certian options i sould set for building opencore
@jakecaley · 
@Medelcartelinc now wait I just rebuilt it and now the krnl panic is different

Image
@jakecaley · 
@Medelcartelinc lookig at the kernel panic before the newest one I see the boot args and there’s almost nothing so I must of accidentally left on the native models but the newest photo is a proper build of the v4 test
@jakecaley · 
@Medelcartelinc mabye not sure may be a lilu issue bc I noticed in the kernel panic it complains about restrictevents.kext and lilu.kext
Dieses Issue auf GitHub diskutieren37 Kommentare
Copyright © Dortania 2020–2025 · T2-Fork © 2026 Albert Müller und OCLP-T2-Mitwirkende