Nucintosh: a maintained OpenCore EFI for 8th generation Intel NUCs

One machine family, one EFI

Nucintosh is described as a quick and dirty repository for Intel NUC 8th generation Coffee Lake models, and the description is honest about the scope. The topic tags name the supported machines, the NUC8i3BEH, NUC8i3BEK, NUC8i5BEH, NUC8i5BEK, NUC8i7BEH and NUC8i7BEK.

The repository contents are small because the work is in the configuration rather than the code. The tree holds an EFI/ directory, a Stuff/ directory with the kexts and images used for different macOS versions, the README, and the GitHub configuration. The releases attach the EFI folder directly, and the README offers both the release download and cloning the full repository for the latest builds.

The stated coverage is broad for a hackintosh configuration, running from macOS Mojave through Catalina, Big Sur, Monterey, Ventura, Sonoma and Sequoia. The author says the EFI was assembled from various sources with a good deal of testing, and describes the aim as a stable and reliable build while noting that these things are never really finished.

Since the 13th of October 2025 the assumed installation target is macOS Sequoia. Older systems still work, but that path involves swapping kexts, and that is where the configuration stops being one size fits all.

The switch to iMac19,1 and the Tahoe problem behind it

The most consequential change in the recent releases is the SMBIOS model. The README states that the SMBIOS on the current and future releases will be iMac19,1, and explains why in unusually concrete terms.

The cause is the sbvmm patch, which came from the RestrictEvents kext that has since been removed. Without that patch, macOS decides a machine is not a real Mac and hides certain updates. The Tahoe update was therefore not being shown at all, and the App Store was refusing to install Tahoe versions of apps that might not work on Sequoia, with Xcode given as an example.

The downside of the old approach is what makes the change necessary. The patch also made incompatible updates visible, and with automatic updates left on, that could lead to a broken install. The author's own preference was to keep using a Mac mini, but since it is a T2 machine it would need the sbvmm patch to show updates, so the only clean solution available is to change the model.

The result is a configuration that presents itself as an iMac19,1, which is what most current hackintosh configurations for this generation of machine do anyway, with the side effect that the update filtering comes back without needing the removed kext.

Migrating an install that used the old model

Existing installations are not abandoned. The README gives a migration path, and the steps are ordered because the order matters for account association.

First you log out of your Apple ID in system preferences and in iMessage and FaceTime, the latter of which the author notes should happen automatically but does not always. Then you use GenSMBIOS to generate new serials and other identifiers, with iMac19,1 as the model. You update config.plist and also edit the plist inside USBMap.kext, which you reach by right clicking it and choosing show contents to find the file.

After that you reboot and clear NVRAM once before booting back into macOS, log in to the Apple ID again and carry on as before. The last step is checking whether the old machine has been removed from your account, in system preferences or online.

The reason for the logout first is the point of the whole exercise. The identifiers are tied to the device record in the Apple account, so the old record has to be released before the new identity is used, otherwise the two overlap and the account ends up in a state that is awkward to untangle.

BIOS settings, and the undervolting that stopped working

Before the installer is created, the NUC's own firmware has to be configured. The README lists the BIOS changes to make after loading the BIOS defaults:

Devices -> USB -> Port Device Charging Mode: off
Devices -> USB -> USB Legacy -> Disabled
Security -> Thunderbolt Security Level: Legacy Mode
Power -> Wake on LAN from S4/S5: Stay Off
Boot -> Boot Configuration -> Network Boot: Disable
Boot -> Secure Boot -> Disable

Two of those deserve a note from later in the README. Thunderbolt is set to Legacy Mode, and the README has a whole section on Thunderbolt behaviour. Secure Boot is disabled because that is what an OpenCore boot requires.

The undervolting story is the part worth reading before you update the BIOS. The README notes that Intel appears to have limited undervolting in a recent BIOS update to patch the Plundervolt exploit, and that the author tried reverting all the way back to one of the first versions without getting undervolting back on the test machine. The advice given is direct: do not update if you want to undervolting, and update later if undervolting was already disabled in your BIOS and the machine has no problems that only a BIOS update would solve.

The HDMI firmware update from Intel is a separate step, and it can only be installed in Windows. The README says it fixes many issues and bugs related to using the HDMI port, in particular with HDMI 2.0 monitors.

Broadcom Wi-Fi and the cost of leaving vanilla macOS

The README separates the Broadcom situation out because it changes what kind of installation you end up with.

Broadcom users need to use OCLP, the OpenCore Legacy Patcher, starting with Sonoma and newer, and will no longer run vanilla macOS, because security features have to be disabled and the root filesystem is patched and no longer sealed. The README links to an issue in the repository for getting Broadcom working again and states the author's goal plainly, which is to run vanilla macOS and not modify it in any way.

The advice for anyone with Broadcom hardware is therefore about which version to stay on. Ventura will keep receiving security updates for at least a few more years, so if you want security features left enabled, stay on Ventura for now. Stock NUCs are not affected, which is the README's way of saying that the models that shipped with Intel wireless hardware avoid this whole branch of the guide.

There is a second, smaller consequence in the same area. Incremental updates will not work, and a full installer is downloaded instead, unless BlueToolFixup.kext is disabled. That is a small thing on its own, but it changes how a machine behaves on update day, and it is the kind of detail that decides whether the experience feels stable.

Wi-Fi and Bluetooth kexts are version specific

If you are not installing Sequoia, the configuration needs adjusting, and the README is specific about it.

On Sonoma and older you swap out itlwm.kext with AirportItlwm.kext, choosing the version that matches your macOS install, from the Stuff folder in the repository. The warning is blunt: not doing this may cause a boot loop. Once the kexts are swapped, the README recommends using the snapshot function in ProperTree to update the config, which is how a plist editing tool applies the same change across every copy of the file.

Bluetooth has a similar version fork for older systems. If you hit Bluetooth issues on versions prior to Monterey, you may also have to replace BlueToolFixup.kext with IntelBluetoothInjector.kext, and those kexts are in the same Stuff folder.

The rest of the install flow follows the familiar path. You download macOS from the App Store and create a USB installer with createinstallmedia on macOS, whether a real Mac, a hackintosh or a virtual machine, or you use gibMacOS. The README notes that installers made with gibMacOS on Windows and Linux need a working internet connection, because the recovery image is used and the full installer is then downloaded from Apple, whereas createinstallmedia produces an offline installer.

The EFI folder goes on the EFI partition of the USB installer, you clear NVRAM from the OpenCore picker, and you install. A practical warning from the README is that OpenCore does not always select the correct partition in the menu during installation: you only boot into the installer once, do the formatting and let it copy what it needs to the internal disk, and from then on select the internal disk, which is easy to spot because it will not have an external label.

Where this repository is the wrong answer

The scope is narrow in a way that decides the question for most people.

If your hardware is not an 8th generation Coffee Lake Intel NUC, none of this applies. The EFI is device specific, the BIOS settings assume that board, and the kext choices assume its wireless hardware. A generic hackintosh guide plus a config built for your own board is the route for other machines.

If you need Broadcom Wi-Fi, or you need incremental updates, or you cannot accept a patched and unsealed system volume, then the recommendation in the README is to stay on Ventura and accept that you are on an older branch, which has its own end of life ahead of it.

There is also the question of what this repository is. It is an EFI, a set of kexts and a README maintained by one person, and the README says so plainly with the quick and dirty description and the admission that these things are never really finished. There is no licence recorded for the repository, which matters if you plan to redistribute the configuration or build on it, and the release history is short and irregular, with v6.1 dated 2026-04-29, v6.2 dated 2026-09-29 and v6.3 dated 2026-10-08.

What you get in exchange for accepting that is a tested configuration with the sharp edges already discovered. The README indexes sections for post install, updating, Thunderbolt, Apple and third party Wi-Fi and Bluetooth, Intel Wi-Fi and Bluetooth, natively supported Bluetooth dongles, what does not work, undervolting, performance, power and noise with notes on passive cooling, and a todo list. For the specific machine, that is a lot more than you would get from starting from scratch.

Editorial conclusion

Adopt Nucintosh if you own one of the 8th generation Coffee Lake Intel NUC models and you want a working, tested EFI rather than a generic guide, and read it as a device specific configuration rather than a tutorial for the general case. Do not adopt it for other hardware, for a machine where Broadcom Wi-Fi is mandatory, or if you need incremental macOS updates on Sequoia. Verify three things first: whether your Broadcom card forces the OpenCore Legacy Patcher route, since the README states that path disables security features and unseals the root filesystem; that your macOS version matches the kexts, because AirportItlwm and itlwm are not interchangeable and the Wi-Fi kext choice can cause a boot loop if wrong; and whether you rely on undervolting, because the README reports Intel disabled it in a later BIOS update and that reverting did not restore it on the author's test machine. No licence is recorded for the repository, the last push was on 2026-10-11, and the newest release is v6.3 dated 2026-10-08.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. zearp/Nucintosh on GitHub