Macmini8,1 Multiple boot behaviors observed, previously reached Tahoe installation with OCLP 3.0 beta
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:
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:
-
Gray screen with a working mouse cursor.
-
Freeze after Apple T2 Controller / AppleUSBNCMData initialization.
-
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.


Comments
@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.
@albert-mueller ·
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:
Thanks again for working on T2 support.
@albert-mueller ·
Thank you! I also have a Mac mini 2018.
@albert-mueller ·
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
@albert-mueller ·
It only works with Mininmal SMBIOS spoofing. Try this.
@Rodrxx-264 · · edited
Update:
Changing the SMBIOS from Macmini8,1 to MacBookPro16,1 fixed the gray screen + mouse cursor issue.
I can now:
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 ·
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 ·
The sequence is:
“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 · · edited
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.
@Rodrxx-264 ·
same problem
ia.log
@albert-mueller · · edited
@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 ·
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:Automatic: False, untouched OEM SMBIOS/DataHub/NVRAM) so SEP keybag decryption succeeds natively.Skip Board ID checkbooter patch to bypass compatibility checks without spoofing.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!