Are kexts like FakeSMC.kext already in System/Library/Extensions by default?

[ModBot]

I never realized how many kexts were already in System/Library/Extensions by default. Is FakeSMC.Kext, or are any of the following: IntelGraphicsFixup.kext, Lilu.Kext, RealtekRTL8111.kext, SATA-100-Series-Unsupported.Kext, USBInjectAll.kext, VoodooPS2Controller.kext already in System/Library/Extensions by default, and using KextWizard just overwrote the copy already there, or are each of these Hackintosh kexts (including FakeSMC.kext) that weren't there naturally and that I actually put there for the first time (on my own system, that is) by using KextWizard?

What version of macOS did you start with?

 

[Kyler]

Started with High Sierra; not sure if you meant to quote the first post or not but we've moved on since that point haha

 

[carpentryplus25]

I never saw your answer originally (I don't know how I read over it and I apologize for that). That answers the original question of this thread. Thank you.

It happenes probably cause I did quote you is why you didn’t notice it.

Rehabman, say I need to uninstall VoodooPS2Controller from S/L/E because I accidentally installed it there and it's the wrong kext for my computer (which it is, I need to use the other keyboard/touchpad kext), how can I uninstall the kext completely and safely from S/L/E?

And for the kexts that are in EFI/Clover/Kexts/Other, is it safe to just delete and replace the essential kexts (like for this keyboard driver)

Now to answer this question you can delete them in finder and then rebuild kext caches and repair disk permissions. Now additional info because some folks get this part twisted. There is really nothing wrong with installing kexts to s/l/e or l/e. In fact most developers do install them there because it allows debug logging. With that said on a hackintosh with unsigned kexts SIP must be disabled all the time with unsigned kexts in either of those directories. Or they will fail to load. Being able to disable SIP is actually a developer feature. Now Some kexts won’t work in the EFI/EFI/Clover/kexts directories an example of this is a patched AppleHDA.kext it must live in s/l/e. Anyhow hope this clears up some confusion

 

[Kyler]

you can delete them in finder and then rebuild kext caches and repair disk permissions.

Can anyone else confirm this (would just like to double check) and how can I do this?

Now Some kexts won’t work in the EFI/EFI/Clover/kexts directories an example of this is a patched AppleHDA.kext it must live in s/l/e.

Can it live in /L/E? Or must it live in /S/L/E? If it must live there how can I protect it from updates?

 

[carpentryplus25]

Can anyone else confirm this (would just like to double check) and how can I do this?


Can it live in /L/E? Or must it live in /S/L/E? If it must live there how can I protect it from updates?

To start with delete what ever kext you aim to uninstall by in finder. Then open terminal and type.

sudo touch /System/Library/Extensions/

Hit enter then type

sudo touch /Library/Extensions/

Hit enter then type

sudo kextcache -Boot -U/

Hit enter and let it finish then repair disk permissions and google search about that should do I can’t remember the terminal commands at the moment as I’m on a mobile device

To protect AppleHDA from updates we typically leave it alone now and bin patch it on the fly with clover and use a dummy style kext to inject our config data to it from our dummy kext. That way it doesn’t break after an update

 

[VioletDragon]

No, I mean the kexts that came on the computer (so not the ones I mentioned originally; I mean the other kexts, those that there are way more of, that are filling S/L/E). I am pretty sure none of those kexts were kexts I installed there, they were ones that came when you install macOS; that are found on any Mac. (Correct or no?)

Now, when did that change happen, where kexts are now installed to /L/E? Sounds like a good change but what was the reasoning given? RehabMan's installer guide for laptops seems to still encourage installing to /S/L/E though I think L/E is better since as far as I know those kexts won't get uninstalled in an update then?

You can delete VoodooPS2 from S/L/E right click and delete. Install to L/E. You can use Terminal or KextBeast 2.0.1 to install to L/E. You also need VoodooPS2 in EFI/Clover/kexts/other.

Install to L/E using Terminal,

sudo cp -R KextToInstall.kext /Library/Extensions

Rebuild Cache.

sudo kextcache i /

 

[Kyler]

What way do you guys suggest I repair disk permissions? I see apps for it when I googled it but I'd rather do it by terminal if still possible, and if not if there's a particular app you guys trust I'd rather use that. Cheers.
Can I use Kext Wizard's built in feature for that is that outdated now? "System/Library/Extensions > Repair Permissions "It will also repair permissions on the whole disk. It can take some time."

 

[Kyler]

Would this command

diskutier resetUserPermissions / `id - u`

do it/have done it? I attached a screenshot of the result.
I also used KextWizard's "repair disk permissions" thing before that and it said successful, and I followed the commands from carpentryplus28's response too. The thing is, macOS El Capitan removed the ability to repair disk permissions through Disk Utility, and Sierra supposedly removed the ability to do it through Terminal, but that was with a different command (

Spoiler

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /

).
Check the screenshot. (source for this command: https://support.apple.com/en-us/HT203538 which was linked to in a comment here.