OCLP-Mod Release/Issue/Discussion

[miliuco]

@johnnyl

Yes, tried on Tahoe 26.2. 
What I did was to enable the Fenvi with the mod (no root  patch before). I reverted the patch because it was only a test. I think that is a good idea revert the patch if you have one applied, remove current OCLP, install the 3.1.1 mod and apply the patch again. 
 

Edited December 27, 2025 by miliuco

[fabiosun]

1 hour ago, schrup21 said:

keep in mind that DisableIoMapper has to be set to true

Not for some motherboard for AMD users, true/false is the same for us

Edited December 27, 2025 by fabiosun

[deeveedee]

For those who don't understand the difference between boot-args -lilubetaall and -amfipassbeta, hopefully this should clear up the confusion:

 

Many of the Acidanthera / Dortania kexts that we rely upon for hacking our PCs depend on Lilu.kext.  These Lilu-dependent kexts include AMFIPass.kext, WhateverGreen.kext, VirtualSMC.kext, AppleALC.kext and others.  Lilu.kext must be loaded by CLOVER or OpenCore in order for these Lilu-dependent kexts to function.

 

For Lilu-dependant kexts, like AMFIPass.kext, there are two ways to enable beta operation of the kext: 

• Use -lilubetaall boot-arg which universally applies to Lilu.kext and all Lilu-dependent kexts (thus the name -lilubetaall)
• Use the kext-specific beta boot-arg

 

Some of the common kext-specific beta boot-args are

• Lilu.kext: -lilubeta
• WhateverGreen.kext: -wegbeta
• VirtualSMC.kext: -vsmcbeta
• AppleALC.kext: -alcbeta
• AMFIPass.kext: -amfipassbeta

 

Since beta operation of a kext may require execution of untested or minimally-tested code, it is typically advisable to use the kext-specific beta boot-arg (not -lilubetaall), so that beta operation is selectively enabled only for the kext or kexts that require it.  However, since there will be no more releases of macOS for Intel, it is likely that AMFIPass.kext will be the last Lilu-dependent kext to be updated for Tahoe, which means that -lilubetaall and -amfipassbeta boot-args can be used interchangeably.

 

 

Long story short, we can use -lilubetaall and -amfipassbeta boot-args interchangeably.

Edited December 27, 2025 by deeveedee

[kgp]

18 hours ago, deeveedee said:

For those who don't understand the difference between boot-args -lilubetaall and -amfipassbeta, hopefully this should clear up the confusion:

 

Many of the Acidanthera / Dortania kexts that we rely upon for hacking our PCs depend on Lilu.kext.  These Lilu-dependent kexts include AMFIPass.kext, WhateverGreen.kext, VirtualSMC.kext, AppleALC.kext and others.  Lilu.kext must be loaded by CLOVER or OpenCore in order for these Lilu-dependent kexts to function.

 

For Lilu-dependant kexts, like AMFIPass.kext, there are two ways to enable beta operation of the kext: 

• Use -lilubetaall boot-arg which universally applies to Lilu.kext and all Lilu-dependent kexts
• Use the kext-specific boot-arg

 

Some of the common kext-specific beta boot-args are

• Lilu.kext: -lilubeta
• WhateverGreen.kext: -wegbeta
• VirtualSMC.kext: -vsmcbeta
• AppleALC.kext: -alcbeta
• AMFIPass.kext: -amfipassbeta

 

Since beta operation of a kext may require execution of untested or minimally-tested code, it is typically advisable to use the kext-specific beta boot-arg (not -lilubetaall), so that beta operation is selectively enabled only for the kext or kexts that require it.  However, since there will be no more releases of macOS for Intel, it is likely that AMFIPass.kext will be the last Lilu-dependent kext to be updated for Tahoe, which means that -lilubetaall and -amfipassbeta boot-args can be used interchangeably.

 

 

Long story short, we can use -lilubetaall and -amfipassbeta boot-args interchangeably.

 

In any case, for OCLP-Mod 3.1.1 the -amfipassbeta boot-arg is more than sufficient.
Using -lilubetaall instead seems like overkill, especially since my system does not boot at all with this boot-arg enabled.

Edited December 28, 2025 by KGP-iMacPro
fixing one typo

[deeveedee]

It might be interesting for you to figure out why your hack doesn't boot with boot-arg -lilubetaall.  I'd speculate that something is wrong with your EFI.  

 

EDIT: If your hack doesn't boot with -lilubetaall, then one or more of your Lilu-dependent kexts (most likely NOT an Acidanthera kext) has bad beta code in it.  Or you spelled -lilubetaall incorrectly (it's easy to forget the second "a").

Edited December 27, 2025 by deeveedee

[kgp]

17 hours ago, deeveedee said:

It might be interesting for you to figure out why your hack doesn't boot with boot-arg -lilubetaall.  I'd speculate that something is wrong with your EFI.

 

What should be wrong with my EFI? I use Lilu 1.7.1, WEG 1.7.1d7, AppleALC 1.9.5, VirtualSMC 1.3.7 and AMFIPass 1.4.1.... in any case I don't see any reason for using -lilubetaall, when just -amfipassbeta is required.

 

EDIT: All other kexts that may also depend on Lilu are strictly required and work perfectly fine on my system without the -lilubetaall boot-arg. There are no functional alternatives for these kexts, and at least for my system, I do not expect to need -lilubetaall going forward. 🙂 

 

EDIT: The "culprit" was SMCRadeonSensors.kext v.2.3.0 by ChefKiss, which was installed locally on my system and is not part of my EFI-Folder distribution. After disabling this kext, my system now also boots with boot-arg "lilubetaall". Nevertheless, I still recommend using "-amfipassbeta" instead, as "-lilubetaall", in the specific case of OLCP-Mod 3.1.1, is an overkill and affects all Lilu-dependent kexts!      

Edited December 28, 2025 by KGP-iMacPro
Second EDIT with solution and clarification

[deeveedee]

@KGP-iMacPro Happy New Year.  Let's be happy.  I'm sorry if my post is not to your liking.  I hope that others have learned something new from my post.

[kgp]

Happy new year, @deeveedee ! 🤗💫
Please don’t misunderstand me - I consider your contribution and your overview of the different Lilu-family boot-args to be very important for the community, especially for those who were missing this respective information.

Many thanks and all the best,

KGP 👍

[johnnyl]

5 hours ago, miliuco said:

@johnnyl

Yes, tried on Tahoe 26.2. 
What I did was to enable the Fenvi with the mod (no root  patch before). I reverted the patch because it was only a test. I think that is a good idea revert the patch if you have one applied, remove current OCLP, install the 3.1.1 mod and apply the patch again. 
 

Thanks bud that's cleared it up for me. I'm going to have a go at that. All the best for the new year for you and everyone else here.

[XanthraX]

Happy New Year to all here. Your hard work made it again. All of you. Even it is the last macOS for hacks, you don't give up. Happy New Year all and all your dreams to get true.

[johnnyl]

On 12/25/2025 at 2:48 PM, laobamac_yyds said:

Merry Christmas, my friends!

 

OCLP-Mod 3.1.0 is a gift for all Hackintosh players~

Thanks again to all Dortania team members and OCLP-Mod testers!

Thanks laobamac_yyds all the best in the new year.

[johnnyl]

13 hours ago, johnnyl said:

Thanks bud that's cleared it up for me. I'm going to have a go at that. All the best for the new year for you and everyone else here.

Just an update. I got the wifi working with my Fenvi 219 in Tahoe 26.3 beta. Thanks to all involved 

I did have trouble with the wifi patch being greyed out in OcMod 3.1.1 after first reverting the old usb and audio patch. I soon found that was because I still had the original opencore patcher installed,so I also reverted that one too. 

Also I found that the mod wanted to automatically install the KDK package before I could click on the patch button and after the patch button would be greyed out again. So I had to be careful to cancel the KDK update so that that patching button was available. The KDK package downloaded and installed after rebooting. I did use boot arg -amfipassbeta and DisableIoMapper set to true so I didn't need to disable vtd in my Bios.

I'm no expert so make of this what you want lol. Cheers

Edited December 28, 2025 by johnnyl

[Wppley]

On 12/25/2025 at 11:48 AM, laobamac_yyds said:

Merry Christmas, my friends!

 

OCLP-Mod 3.1.0 is a gift for all Hackintosh players~

Thanks again to all Dortania team members and OCLP-Mod testers!

Merry Christmas to all! Thank you so much, @laobamac_yyds, for the solution! Thank you so much, @Henties, for sharing your success! Now everything works perfectly.

[chris1111]

OCLP-Mod 3.1.2 updated properly 

 

 

Reboot Done Thanks @laobamac_yyds

 

[laobamac_yyds]

The original version of OCLP crashes on some C612 platforms due to the inability to detect PCI devices. I am unable to reproduce the issue and can only guess and fix it ... already included in OCLP-Mod 3.1.2. Perhaps it is effective?

 

in device_probe.py

[XanthraX]

Updated to version 3.1.2. Works flawlessly here. Thank you all who contributed to this project. 

[axonleo]

Could this mod patch Kepler gtx 680 gpu in Tahoe 26.2 ?

[chris1111]

1 hour ago, axonleo said:

Could this mod patch Kepler gtx 680 gpu in Tahoe 26.2 ?

No

[schrup21]

Hi @laobamac_yyds There's a little problem about the Modern WiFi Patch and Intel modules: even when using Itlwm + Heliport.app, and not having IOSkywalkFamily or IO80211FamilyLegacy enabled in OpenCore (nor the block entry for IOSkywalkFamily), OCLP-Mod still wants to apply the Modern WiFi patch. There doesn't seem to be an option to prevent this.

Some users might prefer Itlwm over AirportItlwm (e.g becaus of the use of a hidden Wifi, what AirportItlwm doen't support) and only want to Patch AppleHDA.

There should be a toggle for Modern Wifi oder the Patcher should recognize, if Itlwm is already loaded or if IO80211FamilyLegacy is present; something like that.

 

Edit: Applying the Modern Wifi Patch has no negative impact.

 

Spoiler

 

Edited January 3 by schrup21

[LockDown]

OCLP does not mind those kext for detection. You might have an IONAME in config

Edited January 3 by LockDown

[schrup21]

42 minutes ago, LockDown said:

OCLP does not mind those kext for detection. You might have an IONAME in config

 

you are right, the BCM Adapter was detected because of IONAME - without OCLP-Mod applies a patch for an "Intel wireless network adapter" (effectively the same Modern Wifi Patch). 

However, I've found that Itlwm also works with the Modern Wifi Patch, so it doesn't matter whether the patch is applied or not – it's purely cosmetic.

 

[arsradu]

3.1.3 - all good on my hardware (had to add -amfipassbeta to boot args in order to boot, otherwise I would get a reboot). But other than that, no issues. I only needed audio and wifi patches. And there are no graphics patches available either way, as far as I know. So, for me, this works perfectly fine. Thank you so much to everyone who made this all possible.

[Thebes Knossos]

Any progresses / experiences about legacy Metal 3802 restoring for Tahoe (Haswell use case for me) ?

[deeveedee]

@Thebes Knossos Maybe this isn't fully understood ... the folks publishing these "unofficial" OCLP patchers aren't actually developing the patches.  They are forking GitHub repos from the actual OCLP Devs and making tweaks in order to publish the patchers before the actual OCLP Devs have finished their development and testing and before the OCLP Devs want the patches to be published.

 

if you want to follow progress of OCLP patcher development, you must watch the actual OCLP Dev GitHub repos - not the unofficial copies. For example, to follow Metal Library development progress, you can look in places like this.  Navigating the OCLP repos will require some basic knowledge of GitHub.

Edited January 16 by deeveedee

[Thebes Knossos]

Thanks deeveedee