Contribute
Register

Where do you place your hackintosh kexts?

Where are your hackintosh kexts loaded and have you had problems?

  • /EFI/CLOVER/kexts/Other/ with no problems

    Votes: 70 56.5%
  • /Library/Extensions/ with no problems

    Votes: 32 25.8%
  • Both with no problems

    Votes: 16 12.9%
  • /EFI/CLOVER/kexts/Other/ with some problems

    Votes: 2 1.6%
  • /Library/Extensions/ with some problems

    Votes: 1 0.8%
  • Both with some problems

    Votes: 3 2.4%

  • Total voters
    124
Status
Not open for further replies.
Interesting. I just checked About This Mac > System Report > Extensions. The good news is that all the hackintosh (recognizable) kexts are loaded. But several of the kexts in /L/E/ folder are not.

So, I looked on my 2017 MBP, and the same non hackintosh are shown are not loaded. Wonder why? (I am not knowledgeable enough about the inner workings of macOS to discover the reasons.) Thus, I'm assuming if they aren't loaded, as listed in both my MBP and MyHeroII hackintosh, then these kexts are not necessary for MyHeroII's SysDef of iMac18,3 nor my MBP14,3.
assume clover loads 3rd party kexts from /L/E if FakeSMC is in /L/E and config.plist -> InjectKexts->Detect

which is what Rehabman mentions in his Laptop Guide post 2:

coming from a laptop user, using BrcmFirmware (which only works in /L/E), my kexts including FakeSMC are installed to /L/E and it all works fine and dandy

There will always be a debate on where to install kexts and the best place to install them is what works for you (the user)
 
Is there a link that gives the process from boot to log in screen? Or at least the clover part?
 
Is there a link that gives the process from boot to log in screen? Or at least the clover part?

Enter the following in Terminal:
Code:
bdmesg
 
I will try bdmseg but was thinking of the logical description of the clover processes - eg. it looks here first and loads x, then if y is set in x it loads z
 
So there really is no consensus on this either way it sounds like?

I've been an "everything in EFI/CLOVER/kexts/Other/" person for a while now and everything seems totally flawless to me...with the added benefit of a fully clean & normal MacOS install which is super nice for updates/upgrades.

Are there even any plausible theories about the why/how of putting kexts in L/E?
Performance? Caching? Something like that I'd guess? Maybe?
 
So there really is no consensus on this either way it sounds like?

I've been an "everything in EFI/CLOVER/kexts/Other/" person for a while now and everything seems totally flawless to me...with the added benefit of a fully clean & normal MacOS install which is super nice for updates/upgrades.

Are there even any plausible theories about the why/how of putting kexts in L/E?
Performance? Caching? Something like that I'd guess? Maybe?
read post 2:
 
Are there even any plausible theories about the why/how of putting kexts in L/E?
Here's the TL;DR version from Rehabman:
IMO, placing kexts in Clover/kexts for injection when not needed is like "flying blind." I don't know about you, but I would not board a plane with a blind pilot (no offense to the blind).
Make sure you've fully tested your hackintosh auto pilot system before taking off with all your kexts in your "other" folder.

Full version:
People often ask me why I install kexts to /L/E

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)
 
Last edited:
What's the best way to do the kext installation?

kextbeast?
kextupdater?
Clover Config?
Terminal?
Other?

Seems like there are like 8 different ways to do it - what's the latest best recommendation for Mojave?
 
Here's the TL;DR version from Rehabman:

Make sure you've fully tested your hackintosh auto pilot system before taking off with all your kexts in your "other" folder.

Full version:

The key takeaway here is:
Screen Shot 2019-04-16 at 5.42.52 AM.png



Screen Shot 2019-04-16 at 5.55.42 AM.png

I don't have the skills for kext development, so I guess I'm boarding the plane without knowing if the pilot can see anyway.



Screen Shot 2019-04-16 at 5.58.28 AM.png

There are also some kexts which were designed with the intent of having them injected, including BrcmFirmwareDate + BrcmPatchRAM2 from RehabMan and Lilu + its plugins/extensions.
Screen Shot 2019-02-12 at 8.35.11 PM.png
That's why there was a need to create LiluFriend.
Screen Shot 2019-02-12 at 8.46.35 PM.png



2.png

To avoid the gioSrcreenLockState 3, we often need WhateverGreen. I would consider this "essential for booting". Since WhateverGreen (along with any and all Lilu plugin/extension) needs to be in the same location as Lilu, I inject Lilu/AppleALC/WhateverGreen.

If a user uses VirtualSMC (which is a Lilu plugin/extension) and VirtualSMC is considered "essential" and VirtualSMC needs to be in the same location as Lilu, I don't see how putting AppleALC and WhateverGreen in /EFI/CLOVER/kexts/Other/ can be construed as "wrong".



I know some people had trouble getting the VGTab created kext working. This was why jaymonkey wrote the guide on how to have the Vega power tables injected by Clover via config.plist. As far as I can tell, the only difference here is the delivery method, but whether you inject via config.plist or VGTab kext in /EFI/CLOVER/kexts/Other, you are still injecting.

This poll, after having been running over a year and with over 50% of the respondents reporting that injecting kexts works "with no problems", shows that it obviously works.

I don't think there's any debate about which method is easier to use and maintain.
 
Last edited:
Status
Not open for further replies.
Back
Top