Contribute
Register

An iDiot's Guide To Lilu and its Plug-ins

@jaymonkey I echo all the praise in the posts above. I'm reasonably technology-savvy, but a real amateur on much of the detail involved in hackintoshes. Your guides are so detailed but very easy to follow and understand. I used your guides to clean up my Kexts with good results and you made me aware of Hackintool, which I used. It's an excellent tool. Together with an article on Catalina issues, your guides helped me to finally be able to upgrade to 10.15. I'm really grateful.
 
I echo all the praise in the posts above. I'm reasonably technology-savvy, but a real amateur on much of the detail involved in hackintoshes. Your guides are so detailed but very easy to follow and understand.


@WedgeTail,

Thank you for the positive feedback, it's always good to read a report from someone who found the guides useful and easy to follow.

One thing to keep in mind is that with 3rd Party kexts installed in /L/E after performing a MacOS update, sometimes some of the 3rd party kexts are missing from the kernel kext cache.

I haven't been able to fully find out why this is the case, but using Hackintool to re-mount the system drive as R/W (if running Catalina) and then using the Rebuild kext cache feature will solve the the issue.

These days I always rebuild the kext cache after installing a MacOS update just to be 100% sure.

I've been meaning to add this to the guide, and will try and get it done later this week.

Cheers
Jay
 
Last edited:
For some odd reason, I could not find DVMT Memory setting in BIOS .... As far as I remember IGSM was 64MB and I probably thought it is DVMT and increased it to 128MB.


@Archangeliques,

For what its worth My ASRock Z87 Motherboard (see my sig for details) also does not have the DVMT size BIOS setting.

A quick and easy way to find out what the default DVMT pre-allocated memory size is (if you cant set it in the BIOS) is to boot into Windows 10 and check the Intel Graphics Controller Memory Size as follows :-
  • As Windows does not support headless IGPU, connect a monitor to one of the motherboards display connectors
  • Boot into Windows 10
  • Right click on the Windows 10 desktop and select Display Properties
  • Select Advanced Display Settings at the bottom of the screen
  • Select the Display connected to the IGPU
  • Check the Intel Graphics Detected Video Memory on the Adapter Tab
IGPU-Memsize.PNG


From this we can derive the DVMT pre-allocated memory size as follows :-
  • If Detected Video Memory Size = 0MB, then DVMT pre-allocated = 32MB.
  • If Detected Video Memory Size = 32MB, then DVMT pre-allocated = 64MB.
  • If Detected Video Memory Size = 64MB, then DVMT pre-allocated = 96MB.
  • If Detected Video Memory Size = 128MB, then DVMT pre-allocated = 128MB
The above example is from my Kaby lake laptop, as you can see the HD 620 IGPU has a Detected Video Memory size of 128MB which means that the Default DVMT Pre-alloc size is also 128MB.

When I ran the above test on my Z87 System I found that the HD 4600 IGPU Detected Video Memory size was 32MB which means that the DVMT pre-allocated Memory is 64MB which is what MacOS is expecting as a Minimum.

MacOS does not use/need the "Integrated Graphics Share Memory" BIOS option so you should be able to set that back to 64MB and reclaim a little bit of reserved memory back.

Cheers
Jay
 
Last edited:
@WedgeTail,

Thank you for the positive feedback, it's always good to read a report from someone who found the guides useful and easy to follow.

One thing to keep in mind is that with 3rd Party kexts installed in /L/E after performing a MacOS update, sometimes some of the 3rd party kexts are missing from the kernel kext cache.

I haven't been able to fully find out why this is the case, but using Hackintool to re-mount the system drive as R/W (if running Catalina) and then using the Rebuild kext cache feature will solve the the issue.

These days I always rebuild the kext cache after installing a MacOS update just to be 100% sure.

I've been meaning to add this to the guide, and will try and get it done later this week.

Cheers
Jay
Stork has just replied to my post in macOS 10.15.2 Update:
"Beginning around the first of February, Apple is requiring all kexts to be certified by Apple and the Mac App Store. Thus, I recommend moving all the hackintosh kexts to /EFI/Clover/kexts/other/ folder. The new MultiBeast for Catalina will be using the Clover kext folder for all selected kexts/drivers because of Apple's new certification policy."

I don't use Multibeast but that I guess there isn't any way around that Apple policy.
 
"Beginning around the first of February, Apple is requiring all kexts to be certified by Apple and the Mac App Store.


@WedgeTail,

I would not read too much into that, the same panic/situation occurred when Apple insisted that all kexts must be signed (trusted) some years ago.

We circumvent that by using the CSRActiveConfig parameter in our config.plist.
The mask value of 1 allows "Untrusted Kexts" to be loaded.

If and when Apple implement further kext certification, it will just be a case of using another CSRActiveConfig bit mask value to circumvent it. This feature is baked into MacOS so that developers can test kexts and Apps without having to submit every alpha and beta version of a kext/App to Apple before they can start testing it.

We use the same mechanism so that we can load 3rd Party kexts required to run MacOS on non-Apple hardware.

There is already a new bit mask value to allow "Unapproved Kexts" (mask value = 512) which we currently don't use, so that may be the one to use if and when Apple make this latest change. It should also be noted in the very latest release of MacOs there has been another SIP mask value added to allow un-notarized apps.

For more info on how to use the CSRActiveConfig parameter see my post here :-


So you can rest easy as there is nothing to worry about.

Cheers
Jay
 
Last edited:
@WedgeTail,

I would not read too much into that, the same panic/situation occurred when Apple insisted that all kexts must be signed (trusted) some years ago.

We circumvent that by using the CSRActiveConfig parameter in our config.plist.
The mask value of 1 allows "Untrusted Kexts" to be loaded.

If and when Apple implement further kext certification, it will just be a case of using another CSRActiveConfig bit mask value to circumvent it. This feature is baked into MacOS so that developers can test kexts and Apps without having to submit every alpha and beta version of a kext/App to Apple before they can start testing it.

We use the same mechanism so that we can load 3rd Party kexts required to run MacOS on non-Apple hardware.

There is already a bit mask value to allow "Unapproved Kexts" (mask value = 512) which we currently don't use, so that may be the one to use if and when Apple make this latest change. It should also be noted in the very latest release of MacOs there has been another SIP mask value added to allow un-notarized apps.

For more info on how to use the CSRActiveConfig parameter see my post here :-


So you can rest easy as there is nothing to worry about.

Cheers
Jay


hello now that you are talking about this. I always have a unanswered question. in this guide the full recommendation is that the kexts should be in /L/E so that the kernel could load them at the beginning of the boot process, as my understand. but all the other guides, for example the one that helps with usb, with native power management, troubleshooting, even in un post when talking about sip, suggest to put the kexts int /EFI/Clover/kexts/other and set detect to inject to yes in the config.plist.

So the question is why ? I can understand that maybe the problems to re-build cache, and others.

but is any gain in performance to put the kexts in /L/E than the other way?
 
So the question is why ? I can understand that maybe the problems to re-build cache, and others.


@Ennio1985,

Pros and cons of installing kexts in /L/E over Injection via Clover is covered in the kext guide : -


Which method you choose to use is down to personal preference, there are those who feel that the Injection method is simpler and requires less maintenance resulting in a more native install, and there are those who feel installing kexts in /L/E results in a more stable system as MacOs can actively monitor the kexts and they can be easily be debugged if necessary (lilu + plugins have internal debugging and logging, but there are still many 3rd party kexts which rely on MacOS to debug them).

Cheers
Jay
 
Last edited:
hello now that you are talking about this. I always have a unanswered question. in this guide the full recommendation is that the kexts should be in /L/E so that the kernel could load them at the beginning of the boot process, as my understand. but all the other guides, for example the one that helps with usb, with native power management, troubleshooting, even in un post when talking about sip, suggest to put the kexts int /EFI/Clover/kexts/other and set detect to inject to yes in the config.plist.

So the question is why ? I can understand that maybe the problems to re-build cache, and others.

but is any gain in performance to put the kexts in /L/E than the other way?
Kexts in /EFI/Clover/kexts/other makes it run like a real Mac, those kexts are injected during boot, so MacOS won't know if there is any alien kexts trying to run in the system. In this way you can have full SIP enabled, so you will be protected like a real Mac. You can have GateKeeper ON, again you will be protected like a real Mac. Also, when you update or upgrade you will less likely to have issues.
 
@Ennio1985,

Pros and cons of installing kexts in /L/E over Injection via Clover is covered in the kext guide : -


Which method you choose to use is down to personal preference, there are those who feel that the Injection method is simpler and requires less maintenance resulting in a more native install, and there are those who feel installing kexts in /L/E results in a more stable system as MacOs can actively monitor the kexts and they can be easily be debugged if necessary (lilu + plugins have internal debugging and logging, but there are still many 3rd party kexts which rely on MacOS to debug them).

Cheers
Jay
did you note any difference in performance of using one or another method?
 
Kexts in /EFI/Clover/kexts/other makes it run like a real Mac, those kexts are injected during boot, so MacOS won't know if there is any alien kexts trying to run in the system. In this way you can have full SIP enabled, so you will be protected like a real Mac. You can have GateKeeper ON, again you will be protected like a real Mac. Also, when you update or upgrade you will less likely to have issues.
so if I use inject instead of detect. I could set 0x0 instead of 0x67 in the CsrActiveConfig value. enable full sip can cause any problems? in the guide to use iMessages the say that sip should be disabled
 
Back
Top