Zum Inhalt springen

← Alle Issues

Macmini8,1 Multiple boot behaviors observed, previously reached Tahoe installation with OCLP 3.0 beta

· von @Rodrxx-264 · bearbeitet 21. Juli 2026

Macmini8,1 (T2) - Multiple boot behaviors observed, previously reached Tahoe installation with OCLP 3.0 beta

Hello,

I would like to report my current testing results on a Mac mini 2018 (Macmini8,1) with the T2 chip.

Hardware

Mac mini 2018 (Macmini8,1)

Intel Core i7
External USB 3.0 SSD

Previous experience (late 2025)

Back in late 2025, while testing an early OCLP 3.0 beta (official OCLP project, not this T2 fork), I managed to get surprisingly far with Tahoe on this machine.

I documented part of that process here:

https://www.reddit.com/r/OpenCoreLegacyPatcher/comments/1phj6h8/logre_arrancar_el_instalador_de_macos_tahoe_en_mi/

At that time I was able to:

Boot the Tahoe installer

Format and select the target disk

Complete the initial installation phase

Successfully pass the first reboot

Continue the second installation stage

After the second reboot, the system would stop at the Apple logo with the progress bar barely started and never continue.

Because of this, I know that this machine was at least capable of completing most of the installation process.

Current testing with OpenCore-Legacy-Patcher-T2

First attempt

The installer successfully booted.

Instead of reaching the installer interface, I only got:

A gray screen

A visible and movable mouse cursor

No installer window or user interface appeared.

The machine remained in that state indefinitely.

Second attempt

Booting with verbose mode enabled, the system progressed much further.

The last visible messages were:

Apple T2 Controller
AppleUSBNCMData/en6
configureDatagramSizeOnBSDInterface()

At that point the system completely stopped progressing.

I waited more than 30 minutes and there was no additional output.

No kernel panic was displayed.

No reboot occurred.

Third attempt

A subsequent boot attempt stopped at a different location.

This time the system reached:

AppleIntelFramebuffer@0/AGPM

along with multiple messages related to:

AppleUserUSBHostHIDDevice
AppleUserHIDEventDriver
IOHIDProviderPropertyMerger

The machine again froze permanently.

The interesting part is that the freeze point was different from the previous attempt.

Observations

From my testing, the behavior does not appear completely deterministic.

I have now observed three different outcomes:

  1. Gray screen with a working mouse cursor.

  2. Freeze after Apple T2 Controller / AppleUSBNCMData initialization.

  3. Freeze earlier during Intel framebuffer / HID initialization.

Since I was previously able to complete most of the Tahoe installation process using an early OCLP 3.0 beta in 2025, I suspect that Macmini8,1 may be capable of booting significantly further than expected and that the remaining issues could be related to T2, BridgeOS, USBNCM, initialization timing, or service startup order rather than a hard hardware incompatibility.

I have attached photos from the verbose boot process and would be happy to perform additional testing if needed.

Thank you for your work on T2 support.

Image Image Image

Kommentare

@Rodrxx-264 ·

Additional finding:

After stopping the testing and booting back into my normal macOS installation, macOS presented a panic report that appears to originate from the T2 / BridgeOS environment.

panic(cpu 0 caller 0xfffffff01d2676cc): macOS panic detected
Debugger message: panic
Memory ID: 0xff
OS release type: User
OS version: 23P56028d
macOS version: Not set

Kernel version:
Darwin Kernel Version 25.6.0: Wed May 13 00:01:44 PDT 2026;
root:xnu-12377.160.49.0.1~22/RELEASE_ARM64_T8010

KernelCache UUID: [REDACTED]
Kernel UUID: [REDACTED]
Boot session UUID: [REDACTED]

iBoot version: iBoot-13822.120.5
iBoot Stage 2 version:
secure boot?: YES
roots installed: 0

x86 EFI Boot State: 0xd
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0x3
x86 Previous Power Transitions: 0x70707060400
PCIeUp link state: 0x89271614

macOS kernel slide: 0x200000
Paniclog version: 15
Kernel slide: 0x0000000016f20000
Kernel text base: 0xfffffff01df24000
mach_absolute_time: 0x12ce77aa8

Epoch Time:
  Boot    : [REDACTED]
  Sleep   : 0x00000000 0x00000000
  Wake    : 0x00000000 0x00000000
  Calendar: [REDACTED]

Zone info:
  Zone map: 0xffffffdc60504000 - 0xffffffe260504000
  . VM    : 0xffffffdc60504000 - 0xffffffdd46b68000
  . RO    : 0xffffffdd46b68000 - 0xffffffdd9383c000
  . GEN0  : 0xffffffdd9383c000 - 0xffffffde79ea0000
  . GEN1  : 0xffffffde79ea0000 - 0xffffffdf60504000
  . GEN2  : 0xffffffdf60504000 - 0xffffffe046b6c000
  . GEN3  : 0xffffffe046b6c000 - 0xffffffe12d1d4000
  . DATA  : 0xffffffe12d1d4000 - 0xffffffe260504000
  Metadata: 0xffffffe464844000 - 0xffffffe466044000
  Bitmaps : 0xffffffe466044000 - 0xffffffe466168000
  Extra   : 0 - 0

TPIDRx_ELy = {
  1: 0xffffffe12d03e360
  0: 0x0000000000000000
  0ro: 0x0000000000000000
}

CORE 0 is the one that panicked.
Check the full backtrace for details.

CORE 1:
PC=0xfffffff01e2b30a4
LR=0xfffffff01e2b30a0
FP=0xffffffe280e2be40

Compressor Info:
0% of compressed pages limit (OK)
0% of segments limit (OK)
0 swapfiles and OK swap space

Panicked task:
0xffffffe046bc36a0
0 pages
171 threads
pid 0: kernel_task

Panicked thread:
0xffffffe12d03e360
backtrace: 0xffffffe86d80b540
tid: 243

Backtrace:
  lr: 0xfffffff01e15e3b0  fp: 0xffffffe86d80b5b0
  lr: 0xfffffff01e2b0f4c  fp: 0xffffffe86d80b620
  lr: 0xfffffff01e2afc1c  fp: 0xffffffe86d80b710
  lr: 0xfffffff01e1196b8  fp: 0xffffffe86d80b720
  lr: 0xfffffff01e15e498  fp: 0xffffffe86d80bc00
  lr: 0xfffffff01e8bd7c4  fp: 0xffffffe86d80bc20
  lr: 0xfffffff01d2676cc  fp: 0xffffffe86d80bc50
  lr: 0xfffffff01d24f2cc  fp: 0xffffffe86d80bcb0
  lr: 0xfffffff01d2503fc  fp: 0xffffffe86d80bcf0
  lr: 0xfffffff01d256510  fp: 0xffffffe86d80bd40
  lr: 0xfffffff01d24fdec  fp: 0xffffffe86d80be00
  lr: 0xfffffff01d24eaac  fp: 0xffffffe86d80be30
  lr: 0xfffffff01e1bad68  fp: 0xffffffe86d80bf20
  lr: 0xfffffff01e1246ec  fp: 0x0000000000000000

@albert-mueller ·

Macmini8,1 (T2) - Multiple boot behaviors observed, previously reached Tahoe installation with OCLP 3.0 beta

Hello,

I would like to report my current testing results on a Mac mini 2018 (Macmini8,1) with the T2 chip.

Hardware

Mac mini 2018 (Macmini8,1)

Intel Core i7 External USB 3.0 SSD

Previous experience (late 2025)

Back in late 2025, while testing an early OCLP 3.0 beta (official OCLP project, not this T2 fork), I managed to get surprisingly far with Tahoe on this machine.

I documented part of that process here:

https://www.reddit.com/r/OpenCoreLegacyPatcher/comments/1phj6h8/logre_arrancar_el_instalador_de_macos_tahoe_en_mi/

At that time I was able to:

Boot the Tahoe installer

Format and select the target disk

Complete the initial installation phase

Successfully pass the first reboot

Continue the second installation stage

After the second reboot, the system would stop at the Apple logo with the progress bar barely started and never continue.

Because of this, I know that this machine was at least capable of completing most of the installation process.

Current testing with OpenCore-Legacy-Patcher-T2

First attempt

The installer successfully booted.

Instead of reaching the installer interface, I only got:

A gray screen

A visible and movable mouse cursor

No installer window or user interface appeared.

The machine remained in that state indefinitely.

Second attempt

Booting with verbose mode enabled, the system progressed much further.

The last visible messages were:

Apple T2 Controller AppleUSBNCMData/en6 configureDatagramSizeOnBSDInterface()

At that point the system completely stopped progressing.

I waited more than 30 minutes and there was no additional output.

No kernel panic was displayed.

No reboot occurred.

Third attempt

A subsequent boot attempt stopped at a different location.

This time the system reached:

AppleIntelFramebuffer@0/AGPM

along with multiple messages related to:

AppleUserUSBHostHIDDevice AppleUserHIDEventDriver IOHIDProviderPropertyMerger

The machine again froze permanently.

The interesting part is that the freeze point was different from the previous attempt.

Observations

From my testing, the behavior does not appear completely deterministic.

I have now observed three different outcomes:

  1. Gray screen with a working mouse cursor.
  2. Freeze after Apple T2 Controller / AppleUSBNCMData initialization.
  3. Freeze earlier during Intel framebuffer / HID initialization.

Since I was previously able to complete most of the Tahoe installation process using an early OCLP 3.0 beta in 2025, I suspect that Macmini8,1 may be capable of booting significantly further than expected and that the remaining issues could be related to T2, BridgeOS, USBNCM, initialization timing, or service startup order rather than a hard hardware incompatibility.

I have attached photos from the verbose boot process and would be happy to perform additional testing if needed.

Thank you for your work on T2 support.

Image Image Image

Hi! This issue is known: #125 . As noted, it requires separate Lilu plugin I think to be fixed? Thanks for your feedback!

@Rodrxx-264 ·

Thank you for the response.

That makes sense. Based on the different behaviors I observed, it may indeed require a separate Lilu plugin or additional runtime patches.

If you create an experimental build or need testing specifically on Macmini8,1, I am willing to test it and provide verbose boot photos, panic logs, and any other diagnostic information you need.

For reference, I observed:

  1. Gray screen with a movable mouse cursor.
  2. Freeze after Apple T2 Controller / AppleUSBNCMData initialization.
  3. Freeze around AppleIntelFramebuffer / HID initialization.
  4. A T2 / BridgeOS ARM64_T8010 panic reported after returning to my normal macOS installation.

Thanks again for working on T2 support.

@albert-mueller ·

Thank you for the response.

That makes sense. Based on the different behaviors I observed, it may indeed require a separate Lilu plugin or additional runtime patches.

If you create an experimental build or need testing specifically on Macmini8,1, I am willing to test it and provide verbose boot photos, panic logs, and any other diagnostic information you need.

For reference, I observed:

  1. Gray screen with a movable mouse cursor.
  2. Freeze after Apple T2 Controller / AppleUSBNCMData initialization.
  3. Freeze around AppleIntelFramebuffer / HID initialization.
  4. A T2 / BridgeOS ARM64_T8010 panic reported after returning to my normal macOS installation.

Thanks again for working on T2 support.

Thank you! I also have a Mac mini 2018.

@albert-mueller ·

Image Image Image

These are the results with the new update that I released a couple of hours ago

@Rodrxx-264 ·

In my case, doesn't show noting, only the cursor

Image

@albert-mueller ·

In my case, doesn't show noting, only the cursor

Image

It only works with Mininmal SMBIOS spoofing. Try this.

@Rodrxx-264 · · bearbeitet

In my case, doesn't show noting, only the cursor
Image

It only works with Mininmal SMBIOS spoofing. Try this.

Update:

Changing the SMBIOS from Macmini8,1 to MacBookPro16,1 fixed the gray screen + mouse cursor issue.

I can now:

  • Boot Recovery
  • Open Disk Utility
  • Start the Tahoe installation
  • Complete the first installation stage
  • Reboot into the second-stage installer
Image

However, during the second stage, I get the following error:

"An error occurred preparing the software update."

The error appears in a window titled "macOS Update Assistant".

So the installer now progresses much further, but fails during the software update preparation phase.

@albert-mueller ·

In my case, doesn't show noting, only the cursor
Image

It only works with Mininmal SMBIOS spoofing. Try this.

Update:

Changing the SMBIOS from Macmini8,1 to MacBookPro16,1 fixed the gray screen + mouse cursor issue.

I can now:

  • Boot Recovery
  • Open Disk Utility
  • Start the Tahoe installation
  • Complete the first installation stage
  • Reboot into the second-stage installer
Image However, during the second stage, I get the following error:

"An error occurred preparing the software update."

The error appears in a window titled "macOS Update Assistant".

So the installer now progresses much further, but fails during the software update preparation phase.

Before reaching "An error occurred preparing the software update.", likely it was showing errors before it reached this screen, do you know if any appeared, like for example let's say AppleKeyStore strike 1 (just an example to understand what I mean)?

@Rodrxx-264 ·

In my case, doesn't show noting, only the cursor
Image

It only works with Mininmal SMBIOS spoofing. Try this.

Update:
Changing the SMBIOS from Macmini8,1 to MacBookPro16,1 fixed the gray screen + mouse cursor issue.
I can now:

  • Boot Recovery
  • Open Disk Utility
  • Start the Tahoe installation
  • Complete the first installation stage
  • Reboot into the second-stage installer
Image However, during the second stage, I get the following error: "An error occurred preparing the software update." The error appears in a window titled "macOS Update Assistant". So the installer now progresses much further, but fails during the software update preparation phase.

Before reaching "An error occurred preparing the software update.", likely it was showing errors before it reached this screen, do you know if any appeared, like for example let's say AppleKeyStore strike 1 (just an example to understand what I mean)?

The sequence is:

  1. Select “Macos installer” in OpenCore.
  2. Verbose output appears and scrolls quickly.
  3. The screen goes black.
  4. The Apple logo, progress bar, and estimated time appear.
  5. After some time, macOS Update Assistant shows:
    “An error occurred preparing the software update.”

I found the installer log at:

macOS Install Data/ia.log

on the external SSD.

The most recent failed attempts show the following underlying error:

Operation: Install Mobile Software Update failed

Error Domain=com.apple.osinstall Code=-81
“An error occurred preparing the software update.”

Underlying error:

Error Domain=MobileSoftwareUpdateErrorDomain Code=29
“Failed to find personalization variant.”

target_update=25B78

This exact “Failed to find personalization variant” error appears repeatedly in multiple attempts.

I also found an earlier failed attempt with a different underlying error:

Error Domain=NSPOSIXErrorDomain Code=2
“No such file or directory”

Localized description:

“Failed to get paths for system root hash/mtree manifest”

The log also repeatedly shows mobileassetd failing to connect to:

com.apple.softwareupdated

with:

“The connection to service named com.apple.softwareupdated was invalidated: Connection init failed at lookup with error 3 - No such process.”

I am not sure whether the softwareupdated messages are the cause or only a consequence of the installation failure.

I can attach the complete ia.log and OpenCore debug log if they are useful.

ia.log

@albert-mueller · · bearbeitet

Can you try with macOS 26.5.2 and see if this issue appears? Your macOS 26.1 install is very outdated and will fail since certs have expired by now for this release and can no longer be validated by Apple's servers. That's 1 thing I have observed in your logs.

@albert-mueller ·

In your logs it says that you were using macOS 26.1, which is very outdated.

@Rodrxx-264 ·

That makes sense.

The previous failed attempts were using an early Tahoe 26.1 installer. I am currently testing again with the latest available Tahoe release on a clean installation.

I'll report back with the results.

@albert-mueller · · bearbeitet

@Rodrxx-264 now you should be able to get further, but still kernel panics upon post install, however, macOS 26 Recovery works with 0 issues. Just tested on my own Mac mini 2018. #130 . Post install kernel panics are due to be fixed, however, it requires significant amount of work. I'll really appreciate if you can join and try to help fixing the kernel panic. Currently I'm working with @DrDonk to fix this, but if you can join I'll appreciate this as well.

@Rodrxx-264 ·

@Rodrxx-264 now you should be able to get further, but still kernel panics upon post install, however, macOS 26 Recovery works with 0 issues. Just tested on my own Mac mini 2018. #130 . Post install kernel panics are due to be fixed, however, it requires significant amount of work. I'll really appreciate if you can join and try to help fixing the kernel panic. Currently I'm working with @DrDonk to fix this, but if you can join I'll appreciate this as well.

Hi! I hope you’re doing well.

I wanted to follow up on your update from July 31st and see how the project has been progressing. Do you have a quick update on the current status of the kernel panic that occurs after installation and the work being done to fix it?

I’d also be very interested in joining and contributing to the project. I’m available for testing, so I’d be happy to help test different builds or patches, reproduce issues, collect logs, and report any findings that might be useful.

I also have Mac mini 2010, 2012, and 2014 models available in case testing on older hardware is needed at some point.

@Medelcartelinc ·

Hi @Rodrxx-264! Great timing.
We actually just made huge progress on that exact post-install kernel panic today!
The root cause behind the failure was the Secure Enclave (SEP) rejecting APFS keybag operations (EPERM) because OpenCore was spoofing SMBIOS and altering DataHub/NVRAM tables.
Albert recently verified a working EFI pass-through on his MBP 2020, and I just submitted PR #275 (#275) to the repo. It aligns the EFI builder for all T2 Macs (including Macmini8,1) to:

  1. Pass through native hardware identities (Automatic: False, untouched OEM SMBIOS/DataHub/NVRAM) so SEP keybag decryption succeeds natively.
  2. Inject the Skip Board ID check booter patch to bypass compatibility checks without spoofing.
  3. Apply T2-safe booter quirks.
    Having you test this on your Mac mini 2018 (Macmini8,1) would be super valuable! Once Albert merges PR #275 (or if you test the PR branch directly), we'd love to see your results!