Contribute
Register

[Guide] Intel NUC7/NUC8 using Clover UEFI (NUC7i7Bxx,NUC8i7Bxx,etc)

From your terminal output I can see Rehabman's script installed a bunch of kexts to Library/ Extensions (did the same for me first time out). Then if you are using my EFI Folder you are duplicating loading the same kexts and that is an issue. If you are going to ask me which kexts to remove please just start over following my post on page 90 post 901. If you have experience and know which kexts to remove and which to leave from L/E then go ahead

@Leesureone Thanks a huge for looking at this!

So my understanding is that kexts should be in just one location, so if there is a kext in EFI folder, it doesn't need to be in Library/Extensions. Please correct me if I'm wrong.

So my plan would be to just go through the listing of Rehabman's kexts which were in my original install thumbdrive, and remove all those from Library/Extensions, and leave the rest.

If not that, then should I just start the install all over again, with same process as the original guide, but with your EFI folder?
 
@Leesureone Thanks a huge for looking at this!

So my understanding is that kexts should be in just one location, so if there is a kext in EFI folder, it doesn't need to be in Library/Extensions. Please correct me if I'm wrong.

So my plan would be to just go through the listing of Rehabman's kexts which were in my original install thumbdrive, and remove all those from Library/Extensions, and leave the rest.

If not that, then should I just start the install all over again, with same process as the original guide, but with your EFI folder?
Yes, one location or the other. Good plan.
 
I don’t believe this is normal behaviour. Especially it works perfectly fine with my macbook pro.

edit: on second thought, on my macbook it us offcourse the internal speakers you control.. But I’m 100% sure it worked on win10 installed on my nuc..
in my experience, on lots of hackintoshes, if you are using HDMI to a monitor/tv, the Mac volume control is greyed out and OS X assumes the volume will be controlled on the monitor/tv. now, if you've connected a headphone-type cable to the audio out port on the nuc, such as using powered speakers, the audio control on the Mac will not be greyed out. if it is there is a problem.

windows may well work differently and let you control output volume from windows when you're connected via HDMI.
 
Yes, one location or the other. Good plan.
Removed a few kexts from /L/E, things got way more stable, but not completely. Removed a few more, and it got way more unstable than ever. (I'm talking just about video playback - that's the only problem I ever had.) Right now /L/E only has non-Rehabman kexts, and things are not working well.

Reading a few things Rehabman wrote here: https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/

"
It is a mistake to install everything to Clover/kexts. Contrary to popular hackintosh myth, it does not result in a cleaner install (the opposite is true). Many kexts will not work from Clover/kexts, so installing them to /L/E where they can be included in kernel cache is the best approach.

People often ask me why I install kexts to /L/E on.

I have many reasons:
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)
...
You might be wondering if this will result in duplicate kexts being loaded due to the kexts in EFI/Clover/kexts being injected when they are also installed to the system volume. The answer is no, not generally. With config.plist/SystemParameters/InjectKexts="Detect", kexts in EFI/Clover/kexts are not injected when FakeSMC.kext is in kernel cache. Because FakeSMC.kext is always a "kext you need", you will always install it to the system volume, which will put it in kernel cache. Kernel cache, of course, will not have FakeSMC.kext when booting the installer or recovery, so in these cases the kexts in EFI/Clover/kexts *will* be injected as you would expect.

"

So I guess it's a bit more complicated than that. I guess the only thing I can do now is reinstall the whole thing but with your EFI folder.
 
Removed a few kexts from /L/E, things got way more stable, but not completely. Removed a few more, and it got way more unstable than ever. (I'm talking just about video playback - that's the only problem I ever had.) Right now /L/E only has non-Rehabman kexts, and things are not working well.

Reading a few things Rehabman wrote here: https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/

"
It is a mistake to install everything to Clover/kexts. Contrary to popular hackintosh myth, it does not result in a cleaner install (the opposite is true). Many kexts will not work from Clover/kexts, so installing them to /L/E where they can be included in kernel cache is the best approach.

People often ask me why I install kexts to /L/E on.

I have many reasons:
- placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking.
- if you develop kexts, error checking is very important!
- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)
- the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality
- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)
- placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac)
...
You might be wondering if this will result in duplicate kexts being loaded due to the kexts in EFI/Clover/kexts being injected when they are also installed to the system volume. The answer is no, not generally. With config.plist/SystemParameters/InjectKexts="Detect", kexts in EFI/Clover/kexts are not injected when FakeSMC.kext is in kernel cache. Because FakeSMC.kext is always a "kext you need", you will always install it to the system volume, which will put it in kernel cache. Kernel cache, of course, will not have FakeSMC.kext when booting the installer or recovery, so in these cases the kexts in EFI/Clover/kexts *will* be injected as you would expect.

"

So I guess it's a bit more complicated than that. I guess the only thing I can do now is reinstall the whole thing but with your EFI folder.
There are strong arguments on both sides of kext placement, for me it's easier to leave them in the EFI folder now. Did you rebuild the kextcache after deleting them? Very important, its this command executed in terminal.

sudo kextcache -i /
 
NUC8i7BEH working great following the guides by @spottsy and @Leesureone. Thank you.

My thunderbolt 3 docking station (HP Elite 65W Thunderbolt 3 Dock) works flawlessly when plugged in during boot, won't show up after sleep, though. Has anybody tried to make that work? There is a fix available for the Hades NUC, I don't know whether that could be helpful: https://osy.gitbook.io/hac-mini-guide/details/thunderbolt-3-fix
 
Last edited:
NUC8i7BEH working great following the guides by @spottsy and @Leesureone. Thank you.

My thunderbolt 3 docking station (HP Elite 65W Thunderbolt 3 Dock) works flawlessly when plugged in during boot, won't show up after sleep, though. Has anybody tried to make that work? There is a fix available for the Hades NUC, I don't know whether that could be helpful: https://osy.gitbook.io/hac-mini-guide/details/thunderbolt-3-fix
I don’t have a dock like that to be able to test, nice link and it looks like the fixes for Thunderbolt are for OSX in general. I would make a guess they could work on our NUCs. Notice I’m not committing myself either way? :eek:
 
There are strong arguments on both sides of kext placement, for me it's easier to leave them in the EFI folder now. Did you rebuild the kextcache after deleting them? Very important, its this command executed in terminal.

sudo kextcache -i /

Thanks, didn't know I had to do that. Did that now. It complained that some kexts have wrong signature, cause they're also from Rehabman, so now the /L/E folder is totally clean. Here's what's in it now:

ACS6x.kext HighPointRR.kext
ATTOCelerityFC8.kext MOTUFireWireAudio.kext
ATTOExpressSASHBA2.kext MOTUMicroBookAudio.kext
ATTOExpressSASRAID2.kext MOTUPCIAudio.kext
ArcMSR.kext Motu MIDI Driver.kext
CalDigitHDProDrv.kext PromiseSTEX.kext
HighPointIOP.kext SoftRAID.kext


Those MOTU things are external sound card drivers.

So now things went back to "a lot more stable". The leftover symptom is that 2-3 times per hour of video I get a small flicker - just a white line over bottom 20% of the screen, but this time the sound also drops for a split second, which wasn't happening before. Not a big deal when I play sound through HDMI, but my external sound card REALLY doesn't like it. After a drop like that it just goes into static noise at full volume on my 8" monitors! Not pretty. Anyway, there's still something going wrong. What else can I look into?
 
NUC8i7BEH working great following the guides by @spottsy and @Leesureone. Thank you.

My thunderbolt 3 docking station (HP Elite 65W Thunderbolt 3 Dock) works flawlessly when plugged in during boot, won't show up after sleep, though. Has anybody tried to make that work? There is a fix available for the Hades NUC, I don't know whether that could be helpful: https://osy.gitbook.io/hac-mini-guide/details/thunderbolt-3-fix

Glad it all works for you. I use a USB-C external drive to run a backup version of my Catalina MAC OS. It uses the USB-3.1 Gen 1 and not Thunderbolt though. It does sleep. It didn't sleep at first either. From memory I just had to reboot after all updates and it worked. Not sure if that is all I did. One thing to check is your bios settings match Rehabman's.

Also make sure you are running BIOS version 74 as mine works with that. Also I have run MAC OS with USB 3.1 using the front ports too and sleep and wake works.

Here are the BIOS settings to save you looking them up: Double check yours. Might be one of those. It might be the Network on Lan waking it up who knows. Also bluetooth mouse can keep it awake so you can disable that waking up the system. USB keyboards can be the problem unplug all usb and see if sleep wake works.

BIOS settings


On my NUC7i7BNH, BIOS version 040 was installed (now updated to 045 yet).

The boot menu and BIOS setup can be accessed by mashing the F2 key during BIOS startup. After the main screen comes up choose "Advanced". That gets you to the main BIOS setup screens.

To start, choose "Load Defaults" (choose from the menu or press F9 in the BIOS setup).

Then change:
- Boot->Boot Configuration, disable "Network Boot"
- Power->Secondary Power Settings, "Wake on LAN from S4/S5", set to "Stay Off"

These settings are important but are already set as needed by "Load Defaults"
- Devices->Video, "IGD Minimum Memory" set to 64mb or 128mb
- Devices->Video, "IGD Aperture Size" set to 256mb
- Boot->Secure Boot, "Secure Boot" is disabled
- Security->Security Features, "Execute Disable Bit" is enabled.

Suggested:
- Boot->Boot Priority->Legacy Boot Priority, disable "Legacy Boot" (it will reduce confusion).
Exception: NUC8 (read above NUC8 notes)
 
in my experience, on lots of hackintoshes, if you are using HDMI to a monitor/tv, the Mac volume control is greyed out and OS X assumes the volume will be controlled on the monitor/tv. now, if you've connected a headphone-type cable to the audio out port on the nuc, such as using powered speakers, the audio control on the Mac will not be greyed out. if it is there is a problem.

windows may well work differently and let you control output volume from windows when you're connected via HDMI.

I can confirm that volume is greyed out. A week or so ago several pages earlier on this thread this issue was discussed with pictures posted. I have attached pictures of both. At the moment I use HDMI out and use REMOTE CONTROL to change volume. When using headphones using the 3.5mm audio out I can control volume using the slider. I copied pics for you as well.
 

Attachments

  • Internal Realtek Front Audio Out Volume Blue.png
    Internal Realtek Front Audio Out Volume Blue.png
    2.1 MB · Views: 124
  • Samsung TV HDMI greyed out use remote control.png
    Samsung TV HDMI greyed out use remote control.png
    2.1 MB · Views: 128
Last edited:
Back
Top