Contribute
Register

Why use .../CLOVER/kexts/Other/ folder for Direct Update to Mojave?

Status
Not open for further replies.
If you have all your kext your system needs in EFI>Clover>kexts>Other during install, all the kexts are included and added to the kernel-cache, SIP can stay enabled and you will never have any issues with them staying in that location. With everything being installed in L/E, you end up having to redo permissions, rebuilt kernel-cache and disabling SIP in order to get the kext to get loaded.

Not true ....

Kext's installed into EFI>Clover>kexts>Other are 'injected' rather than 'loaded'

Injected kext's live outside of the kernels kext's memory pool and are excluded for the kernel cache ...

Jay
 
We need to find a definitive answer to that question that it is critical.
Having kexts to clover/other have several advantages. First of all you have all your kexts in one place , so if you want to try another or update one you simply delete and add without having to repair permissions. The second and biggest one is that if you inject a kext that makes your system not to boot , you can always boot from a usb or get in windows and mount refi flower and repair. If you install a "problematic" kext into l/e and you cannot boot then the only option you have is to reinstall macOS.

So , inject through clover/kexts has advantages.

Can anyone say for sure that installing into l/e has advantages , too ?
 
We need to find a definitive answer to that question that it is critical.
Having kexts to clover/other have several advantages. First of all you have all your kexts in one place , so if you want to try another or update one you simply delete and add without having to repair permissions. The second and biggest one is that if you inject a kext that makes your system not to boot , you can always boot from a usb or get in windows and mount refi flower and repair. If you install a "problematic" kext into l/e and you cannot boot then the only option you have is to reinstall macOS.

So , inject through clover/kexts has advantages.

Can anyone say for sure that installing into l/e has advantages , too ?
read post 2:
https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/
 
I quote from the link :

- 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!

comment : Suppose it is true , but the majority of users aren't developers. If there is one , I agree , put them in l/e.


- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)

comment :Today , almost every kext can be injected through clover/other , even codeccommander.


- 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

comment : As I said earlier , today this method is minimalistic and fully functional as well.


- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)

comment : with newer systems like CoffeeLake we often have to try/inject newer kexts.


- 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)

comment : In theory maybe. Practically what's the difference?
 
The second and biggest one is that if you inject a kext that makes your system not to boot , you can always boot from a usb or get in windows and mount refi flower and repair. If you install a "problematic" kext into l/e and you cannot boot then the only option you have is to reinstall macOS.
Actually all you have to do now is reboot, get back to Clover boot menu, hit spacebar on the drive you were trying to boot and Select Block kext inject and select the kext you just installed that stopped your system from booting. Its al builtin the GUI boot menu of Clover now.
 
Not true ....
Kext's installed into EFI>Clover>kexts>Other are 'injected' rather than 'loaded'
Injected kext's live outside of the kernels kext's memory pool and are excluded for the kernel cache ...
Jay
Yes injecting kext live outside the kernel's memory pool but if you have them injected during the install phase they are 100% included in the kernel-cache, has been this way since 10.12 because the kernel-cache gets built off what kexts are loaded during the system install phase. I do agree with you on the "injected" vs "loaded" theory though, but is only related to newer kext that is being injected after install phase is done.
 
Actually all you have to do now is reboot, get back to Clover boot menu, hit spacebar on the drive you were trying to boot and Select Block kext inject and select the kext you just installed that stopped your system from booting. Its al builtin the GUI boot menu of Clover now.

Thought that option was for kexts at clover , only. Does it work with l/e too ?
 
Thought that option was for kexts at clover , only. Does it work with l/e too ?
Yeah it only effects kexts that have been put in EFI>Clover>kexts>"Any of the folders"
 
I quote from the link :

- 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!

comment : Suppose it is true , but the majority of users aren't developers. If there is one , I agree , put them in l/e.

But the error checking is still important.
If I had a dollar for every time a user had incompatible/mismatced kexts in EFI/Clover...
And if those same kexts were installed to /L/E, the user would have had obvious errors from kextcache to investigate.

- some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*)

comment :Today , almost every kext can be injected through clover/other , even codeccommander.

FYI: I wrote the special code in CodecCommander.kext that allows it to be used in Clover/kexts. Note that the special code I added to CodecCommander is not present in a kext like IOath3kfrmwr.kext. Note also the case of BrcmFirmwareRepo.kext, which does not work from Clover/kexts, and requires the use of heavy weight alternative in BrcmFirmwareData.kext.

But still not all.
I run into issues that are a direct result of kexts not starting from kernel cache. It is possible these problems are not as prevalent with desktops that have a much simpler hack kexts setup (eg. less kexts, kext startup not as critical).

If you understand the ramifications (including the above regarding mismatched kexts), then by all means put your kexts into Clover/kexts only, but I would not attempt to diagnose a problem with someone doing that, as it is too much work to verify all the kexts in Clover/kexts are compatible with each other (eg. easier to let kextcache check for me).

- 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

comment : As I said earlier , today this method is minimalistic and fully functional as well.

I still like certain kexts, not necessary for recovery or the installer to be out-of-play when booting the recovery or installer.

- so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems)

comment : with newer systems like CoffeeLake we often have to try/inject newer kexts.

Well, of course... updating the kexts on Clover/kexts is a different matter.
(I have scripts that do it automatically...)

- 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)

comment : In theory maybe. Practically what's the difference?

The difference is in the results everyday, especially on laptops.
You should hang out in the laptop forum for a while and try to help people... maybe you'd understand better.
 
I respect your opinion. That's for sure.
 
Status
Not open for further replies.
Back
Top