Kernel panic when booting any volume from OCLP picker on iMacPro1,1

August 3, 2026 · by @LucasDrouot

needs-version-info

When attempting to boot into any volume from the OCLP boot picker, my iMac Pro goes directly to a black screen (power state: off). I suspect this is a kernel panic.

The only time it somewhat worked was during the very first boot into the installer, where it got stuck on the loading bar indefinitely. I haven't been able to reproduce that since. I wasn't running in verbose mode at the time, so I don't have logs for that attempt.
On one occasion, it triggered a Panic Medic Boot.

Note: csrutil and csrutil authenticated-root are automatically re-enabled after every kernel panic.

What I've tried

Recreated the bootable installer drive
Reset NVRAM (notably, only the EFI on the external drive is visible; the internal EFI does not show up even after installing OCLP to it)
(Attempted to boot the main macOS partition via OCLP)
None of these worked.

Comments

@albert-mueller · August 3, 2026

Just released the next release - SIP was set to 0x803 instead of 0xFFF, that may have caused panics. Can you try?
@LucasDrouot

@LucasDrouot · August 4, 2026

After updating to the latest release, the behavior is unchanged.

I tried enabling both OpenCore Debugging and Kext Debugging to collect logs. However, no log files are ever generated.

The boot sequence is as follows:

OpenCore loads normally and the boot picker appears.
I select any boot volume
The screen goes black for about 2 seconds while the display signal is still active
The iMac then immediately shuts off

Because the crash happens this early, I never reach verbose output, and no opencore.log, kext logs, or panic logs are written to the EFI partition. I suspect the failure occurs before OpenCore has a chance to write any debug output.

I'm attaching a ZIP archive of my EFI folder (Boot and OC) in case it helps identify a configuration or implementation issue.
EFI.zip

@albert-mueller · August 4, 2026

After updating to the latest release, the behavior is unchanged.

I tried enabling both OpenCore Debugging and Kext Debugging to collect logs. However, no log files are ever generated.

The boot sequence is as follows:

OpenCore loads normally and the boot picker appears.

I select any boot volume

The screen goes black for about 2 seconds while the display signal is still active

The iMac then immediately shuts off

Because the crash happens this early, I never reach verbose output, and no opencore.log, kext logs, or panic logs are written to the EFI partition. I suspect the failure occurs before OpenCore has a chance to write any debug output.

I'm attaching a ZIP archive of my EFI folder (Boot and OC) in case it helps identify a configuration or implementation issue. EFI.zip

My Mac mini 2018 (although yours is an iMac Pro), behaved the same way when Secure Boot was set to Medium Security instead of No Security and also when Allow booting from external media was set to Don’t allow booting from external media. On my Mac mini 2018, also, when Secure Boot was set to Medium Security, it either froze at Apple logo or it didn’t boot at all. Have you tried disabling Secure Boot by setting to None?

@LucasDrouot · August 4, 2026

Secure Boot is fully disabled on my iMac Pro. I tried re-enabling it and disabling it again, but the issue persists.

The iMac did generate a kernel panic log this time, which I have attached.
panic_report.txt

@albert-mueller · August 4, 2026

Okay, you’ve set Démarrage sécurité (Secure Boot) to Aucune sécurité (No security) and Autoriser le démarrage à partir de supports externes ou amovibles (Allow booting from external media). That’s good. The kernel panic shows some issue with communicating to the T2/bridgeOS properly, will take a look later on. Bonne nuit.

@albert-mueller · August 23, 2026

When attempting to boot into any volume from the OCLP boot picker, my iMac Pro goes directly to a black screen (power state: off). I suspect this is a kernel panic.

The only time it somewhat worked was during the very first boot into the installer, where it got stuck on the loading bar indefinitely. I haven't been able to reproduce that since. I wasn't running in verbose mode at the time, so I don't have logs for that attempt. On one occasion, it triggered a Panic Medic Boot.

Note: csrutil and csrutil authenticated-root are automatically re-enabled after every kernel panic.

What I've tried

Recreated the bootable installer drive

Reset NVRAM (notably, only the EFI on the external drive is visible; the internal EFI does not show up even after installing OCLP to it)

(Attempted to boot the main macOS partition via OCLP)
None of these worked.

OK, with alpha 17, many issues are fixed. Can you try again? @LucasDrouot

@LucasDrouot · August 23, 2026

Same situation; the T2 panics.
panic_report.txt

@albert-mueller · August 23, 2026

Can you send the EFI with the logs? Or eventually a slow-motion video showing the panic if it reaches a kernel panic?
The log that you sent only says that bridgeOS panics, but doesn’t say much why.

@LucasDrouot · August 23, 2026 · edited

Tried to boot the installer via OCLP twice:
opencore-2026-08-23-102049.txt
opencore-2026-08-23-102318.txt
OC.zip

Recorded the whole process (OCLP boot the second time, and Macintosh HD boot)
Tried to get the best video quality; any AI should be able to read the output
https://www.swisstransfer.com/d/73899bb6-95a8-4a2c-bc2b-be513e508f8c

@albert-mueller · September 1, 2026

@Medelcartelinc Not sure how to fix this panic and whether it is OpenCorePkg related or not. If it is, I'd be happy to add you as a contributor to my OpenCorePkg fork if you want.

@LucasDrouot · October 4, 2026

@albert-mueller Have you made any progress on this issue?

@github-actions · October 4, 2026

Hi @LucasDrouot, thanks for the report! To look into this we need to know exactly which versions you're running. Please edit your issue or reply below with:

macOS version, ideally with the build number (e.g. 26.6.1 (25G76)). You can find it under → About This Mac, or by running sw_vers in Terminal.
OpenCore Legacy Patcher version (e.g. 4.0.0.19004.5), shown in the app's main window. If you built from source, the commit hash works too.

"Latest" or "new" isn't enough, since new builds come out often. This comment will go away once the versions are added.

@albert-mueller · October 4, 2026

@albert-mueller Have you made any progress on this issue?

Yes! Now even MacBookAir8,1 makes its way to Recovery, and other MacBooks are no longer kernel panicking when trying to reach Recovery.
But second stage is another issue.
For the iMac Pro, this remains to be tested.

@albert-mueller · October 4, 2026

@zkennedy137

@albert-mueller · October 7, 2026

@albert-mueller Have you made any progress on this issue?
Can you try it on your iMacPro1,1, @LucasDrouot ?
On most Macs, now it manages to go to macOS 26 Tahoe Recovery with no issues.

@zkennedy137 · October 7, 2026

I know that in my testing when I elected a boot option in OpenCore and was presented with a black screen I had to boot into my stock Sonoma install then shut down and then try to boot into it and for some reason this fixed the black screen. However this was usually because I was trying to boot into Sonoma (the only installed os on my Mac at the moment) with OpenCore but the stock boot from hard drive worked fine.

@LucasDrouot · October 9, 2026

15. > @albert-mueller Have you made any progress on this issue?

I've tried everything, but it still crashes

Discuss this issue on GitHub17 comments