[Guide] Dell Latitude E6410 (Nvidia) Hackintosh: Big Sur, Monterey, Ventura, Sonoma & Sequoia installations with Open Core Legacy Patching

[deeveedee]

@MacNB I hope you don't mind me pinging you.  I tried your VMM ON trick with this hack (SMBIOS MacBookPro6,2) and found that my rig would not boot  macOS Monterey 12.6.1 with Cpuid1Data configured in the attached config.plist.  The boot cycle freezes at the point here:

 

Frozen boot with VMM ON

Spoiler

 

My config.plist (with Kernel > Emulate > Cpuid1Data) is attached.  I have read posts from others who find that the "VMM trick" does not work with some SMBIOS models.  Maybe MBP6,2 is one such SMBIOS?  What's interesting about this is that I have intermittent boot failures with Monterey and the boot fails at close to the same place; however, The boot failure is rare and is only with Monterey, not Big Sur or Ventura and my hack does eventually boot Monterey.  With VMM ON configured, my rig always freezes at the same place and never boots.  The only way to recover is a forced shutdown by holding the power button.

 

If you have any ideas, I welcome your expertise.  Thanks!

 

EDIT: I tested with and without enabling Booter > Patch > Skip Board ID check (which is generated by Open Core Legacy Patcher).  The frozen boot behavior with VMM ON does not change, regardless of whether the Booter > Patch is enabled/disabled.

config-ALCmod-v-VMM-ON.plist.zip

Edited December 17, 2022 by deeveedee

[MacNB]

19 hours ago, deeveedee said:

@MacNB I hope you don't mind me pinging you.  I tried your VMM ON trick with this hack (SMBIOS MacBookPro6,2) and found that my rig would not boot  macOS Monterey 12.6.1 with Cpuid1Data configured in the attached config.plist.  The boot cycle freezes at the point here:

 

Frozen boot with VMM ON

  Reveal hidden contents

 

My config.plist (with Kernel > Emulate > Cpuid1Data) is attached.  I have read posts from others who find that the "VMM trick" does not work with some SMBIOS models.  Maybe MBP6,2 is one such SMBIOS?  What's interesting about this is that I have intermittent boot failures with Monterey and the boot fails at close to the same place; however, The boot failure is rare and is only with Monterey, not Big Sur or Ventura and my hack does eventually boot Monterey.  With VMM ON configured, my rig always freezes at the same place and never boots.  The only way to recover is a forced shutdown by holding the power button.

 

If you have any ideas, I welcome your expertise.  Thanks!

 

EDIT: I tested with and without enabling Booter > Patch > Skip Board ID check (which is generated by Open Core Legacy Patcher).  The frozen boot behavior with VMM ON does not change, regardless of whether the Booter > Patch is enabled/disabled.

config-ALCmod-v-VMM-ON.plist.zip 8.38 kB · 2 downloads

 

Short answer: No idea why VMM bit crashes your Monterey.

Longer answer: It may be related to the fact that you have some Kernel patches related to VMM (that I am not familiar with):

1. Reroute kern.hv_vmm_present patch (1)
2. Reroute kern.hv_vmm_present patch (2) Legacy
3. Reroute kern.hv_vmm_present patch (2) Ventura

What are those patches and why do you need them ?

May be they are causing your intermittent boot failures (esp 1 & 2) above.

 

[deeveedee]

@MacNB Very observant.  I'll bet you are correct.  Those Kernel patches are taken directly from the EFI generated by OCLP.  Without them, my hack does not see new macOS updates (e.g., I won't be prompted to upgrade to Ventura from Monterey).  I'll try disabling them before attempting your VMM fix and will report my findings.  Thank you!

[MacNB]

1 hour ago, deeveedee said:

@MacNB Very observant.  I'll bet you are correct.  Those Kernel patches are taken directly from the EFI generated by OCLP.  Without them, my hack does not see new macOS updates (e.g., I won't be prompted to upgrade to Ventura from Monterey).  I'll try disabling them before attempting your VMM fix and will report my findings.  Thank you!

 

That's the "problem" with OCLP...it is designed for REAL Mac's for people who do not know (or do not want to know) how to hack their unsupported Mac's to run latests macOS's.

For them, the OCLP have done a great job.

OCLP is not designed for hackintoch's and so they have not clearly documented each patch/config...it's all hidden behind the scene with their App.

You would have to look into their sources to decipher what they are doing if you can figure out the structure of the sources.

Unfortunately, if you reported this issue on their GitHub Issues, you will likely to get no support as your system is not a real Mac.

 

Yes, OCLP absolutely looks are the SMBIOS model number and within their code at various places, checks on that. Your MacBookPro6,2 may not be explicitly covered. 

Try: Enable Virutalisation In BIOS and then in your config.plist Root::UEFI::Quirks::EnableVmx=YES

[deeveedee]

@MacNB  The only change I needed to make was to enable Intel Virtualization in BIOS.  I had disabled it during some testing and forgot to turn it back on.  With Intel Virtualization enabled, your VMM ON patch coexists with the OCLP Vmm kernel patches without any problems.  Enabling Virtualization does not fix the intermittent Monterey boot problem (I am only able to fix that by disabling Intel Turbo Boost in BIOS).

 

The OCLP team has done a fantastic job on the various patches required for different SMBIOS Mac models.  Their Vmm patches do enable macOS updates on my HackBookPro6,2.   For those who want to learn about the OCLP patches, start reading here for more info.

 

Some have criticized CLOVER for the same "problem" where it provides too many canned fixes for people who do not know (or do not want to know).  I'm perfectly happy to take every bit of help I can get.  😃

 

Thanks again for your help!

Edited December 18, 2022 by deeveedee

[MacNB]

4 hours ago, deeveedee said:

@MacNB  The only change I needed to make was to enable Intel Virtualization in BIOS.  I had disabled it during some testing and forgot to turn it back on.  With Intel Virtualization enabled, your VMM ON patch coexists with the OCLP Vmm kernel patches without any problems.  Enabling Virtualization does not fix the intermittent Monterey boot problem (I am only able to fix that by disabling Intel Turbo Boost in BIOS).

 

The OCLP team has done a fantastic job on the various patches required for different SMBIOS Mac models.  Their Vmm patches do enable macOS updates on my HackBookPro6,2.   For those who want to learn about the OCLP patches, start reading here for more info.

 

Some have criticized CLOVER for the same "problem" where it provides too many canned fixes for people who do not know (or do not want to know).  I'm perfectly happy to take every bit of help I can get.  😃

 

Thanks again for your help!

 

Glad you got it working.

 

I have seen that OCLP Patching explanation page before. For me, there's still not enough detailed explanation.

[deeveedee]

I have reverted to OCLP 0.5.2 after testing post-install patching with OCLP 0.5.3.  I didn't see any improvements in Big Sur or Ventura with OCLP 0.5.3 patches and I saw new boot issues with Monterey here.  I understand that OCLP is for real Macs and accepted the risk when I first started exploring a MacOS 11+ solution for this hack.  Hopefully my OCLP 0.5.3 experience is not indicative of my future hack performance with OCLP.  

 

My findings should in no way be interpreted as a problem with OCLP.  I am using OCLP with a hackintosh -  a way not intended by OCLP developers.  Since this Dell Latitude E6410 has unsupported Nvidia graphics, I'll continue to rely on OCLP and retest with the release of version 0.5.4.

[deeveedee]

I noticed that OCLP 0.5.3 includes AppleALC 1.6.3 instead of 1.7.7 due to an apparent issue with legacy Macs.  I'm having no problems with 1.7.7 (aside from the HDAU naming problem), but tested 1.6.3 anyway.  I did not notice any difference between AppleALC 1.7.7 and 1.6.3 for this hack, so I am staying with version 1.7.7 (still using the version I modified to disable HDAU naming).

[deeveedee]

I am able to use the unmodified, release version 1.7.7 of AppleALC.kext after changing pci10de,be3 class-code to FF FF FF FF as described here.

[deeveedee]

I have upgraded this hack to OC0.8.8 while retaining the LegacyBoot from OC0.8.7 because of the issue here.

[deeveedee]

My latest Big Sur EFI (based on OpenCore 0.8.8) is now posted here.  For now, I am leaving my High Sierra EFI (here) untouched since it is a perfectly stable baseline.

 

EDIT: The Monterey boot problem has not improved and I still don't have a good fix for it.  Once Monterey boots, the OS works well (with the exception of the web camera and Bluetooth).  Monterey boot problem is less likely to occur after one successful boot and population of NVRAM emulation.  Disabling CPU Turbo Boost in BIOS is also a "fix."  My favorite macOS for this hack continues to be Big Sur.

Edited January 3, 2023 by deeveedee

[deeveedee]

The intermittent Monterey boot issue is solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  Leaving the post below for historical purposes.

 

==================================

 

EDIT: It appears that suspecting VirtualSMC is a wrong conclusion.  As indicated here, VirtualSMC is referenced in kernel panics.  Leaving this post below, since I still believe it offers a clue about the Monterey boot issue.

 

EDIT2: I attached a revised BigSur EFI here.  In the previous OC0.8.8 EFI, I had SetApfsTrimTimeout = 0 (should have been -1) because of an experiment I was doing.  Also, I found that I don't need the RTC fix which sets Length = 2 (this hack works fine with RTC Length = 8).  Also, I set Kernel > Quirk > ExtendBTFeatureFlags = False after seeing some FeatureFlags errors in verbose debugging.   Note that these changes do not fix the Monterey boot issue and simply represent the current baseline EFI that I am using for testing.

 

===================================

 

After many boot cycles with Monterey, I finally have a clue that may lead to a solution.  For the first time, I saw a kernel panic without an immediate reboot.  If this kernel panic is indicative of the Monterey boot problem (and I think there's a good chance this is indicative), the Monterey boot problem with my hack is with VirtualSMC.  Maybe there is a Quirk that I have incorrectly configured?  Or maybe I need to use FakeSMC?

 

Monterey Boot Kernel Panic

Spoiler

 

Edited March 24, 2023 by deeveedee

[deeveedee]

My latest OC 0.8.8 EFI (here) disables Bluetooth kexts for Monterey and Ventura.  With Bluetooth kexts disabled, Monterey booting is more reliable.  Still not perfect, but much better.  Since Bluetooth is not working for me in Monterey and Ventura, this change is perfectly acceptable to me.

[deeveedee]

With the releases of Big Sur 11.7.3, Monterey 12.6.3, Ventura 13.2 and OCLP 0.6.1, my hacking strategy for this Dell Latitude is as follows:

 

• Apply EFI updates derived from OCLP 0.6.1 (I am using a single OC 0.8.8 EFI to boot Big Sur, Monterey and Ventura)
• Upgrade to Big Sur 11.7.3 (BS is my baseline on this hack)
• Upgrade to Monterey 12.6.3
• Apply Post Install patches to Monterey and Ventura using OCLP 0.6.1 (stay with OCLP 0.5.2 post-install patches on Big Sur until further testing)

 

I am going to remain on Ventura 13.1 until I confirm that OCLP is properly patching Ventura with working Nvidia graphics acceleration.

Edited January 24, 2023 by deeveedee

[deeveedee]

I have completed the Upgrades to Big Sur 11.7.3, Monterey 12.6.3 and Ventura 13.2.  With the release of OCLP 0.6.1, Ventura works better than Monterey (no boot issues with Ventura while there are still occasional boot issues with Monterey).  If my testing continues to go well with Ventura, there will be no need to maintain Monterey on this hack.

[deeveedee]

Continuing to test Ventura 13.2 on this hack after applying OCLP 0.6.1 patches.  I'm pleasantly surprised by how well the following apps work: Xcode 14.2, Visual Studio 2022 with Xamarin, Microsoft Office 2019 (be sure to apply most recent updates).  I have not found any app limitations and am very pleased with the way this hack is performing.  This is definitely a testament to how well Apple has written macOS Ventura. It is a very efficient OS.

[deeveedee]

I have posted my latest OC 0.8.8 EFI for Big Sur and Ventura here.  This new EFI incorporates some components of the EFI generated by OCLP 0.6.1.  Following successful testing of Ventura 13.2 and OCLP 0.6.1 on this hack, I am abandoning Monterey and will no longer attempt to fix the intermittent Monterey boot issue.  For my purposes, Big Sur and Ventura work well enough that Monterey is unnecessary.  I am continuing to leave my High Sierra EFI unchanged, as this is my stable baseline that works perfectly.

[deeveedee]

After running the GeekBench 5 benchmarks on my HackMini8,1, the benchmarks for this hack make me laugh    The performance/responsiveness of this hack when running Ventura 13.2 is much better than the GB5 benchmarks imply.

 

GB5 Detected Info

Spoiler

 

GB5 CPU Scores

Spoiler

 

[deeveedee]

Without much expectation for success, I tested VoodooSDHC.kext (for Ricoh SD Card Reader) and determined that the wake "freeze" problem that occurred when I tested with Catalina here still occurs with this new OpenCore implementation and Big Sur.  I tested out of curiosity and don't have a need for the SD Card Reader; however, if anyone does have a newer solution for the Ricoh SD Card reader, please let me know.  Thank you.

[deeveedee]

I am amazed at how well this hack works with Ventura 13.2.  Today I've been using RealVNC Viewer and Microsoft Remote Desktop.  Both work flawlessly and performance is outstanding.  This is simply amazing.  OCLP's ability to resurrect this hack and restore its life to a modern-day Mac has far, far, far exceeded my expectations.  This was a lot of work, but well worth the effort.

[deeveedee]

The -v boot issue and the intermittent Monterey boot issue are solved by replacing VirtualSMC.kext with FakeSMC.kext or add boot-arg vsmcgen=1 for VirtualSMC.  Leaving the post below for historical purposes.

 

===================================

 

I tried removing the -v (verbose) boot-arg from my OC0.8.8 EFI for Big Sur and found that Ventura 13.2 never boots without the -v boot-arg (details here).  This does not affect operation of Ventura, so it's a lower priority for me, but if anyone has any guesses about why Ventura would boot 100% of the time with the -v boot-arg and never boot without the -v boot-arg, please offer suggestions.  Thank you.

Edited March 24, 2023 by deeveedee

[deeveedee]

I have upgraded my High Sierra EFI to OC0.8.8 with the following changes:

• Replaced VoodooHDA with AppleALC (again) now that I'm disabling Device pci10de,be3 to avoid the slow boot when AppleHDA detects the device.  Note that My SSDT-HDAU ACPI patch names pci10de,be3 as HDAU.  I found that the device can be named HDAU as long as class-code is <FF FF FF FF>.  Note also that I am unable to set class-code to <FF FF FF FF> via OC DeviceProperties, because OC is unable to overwrite an existing DeviceProperty for an unnamed device (as per Vit9696 and confirmed in testing).
• Removed cosmetic ACPI > Add SSDT-SMS0.  This was purely cosmetic and I determined that it was actually incorrect.  On a real MBP6,2, SMS0 is a child of Device \_SB.PCI0.SMC and not a child of \_SB.PCI0 as I had originally and incorrectly specified.  Making this change did not change the behavior of this hack.
• Disabled ACPI > Add SSDT-FRWR.  See my note here about Firewire and SD Card support.
• Removed CPU PM SSDT, since I found that laptop performance was not as good with as without.  It was a good learning exercise.

 

Note that High Sierra boots perfectly without boot-arg -v (unlike Ventura with my Big Sur EFI).  I still don't know why I can't boot Ventura without the -v boot-arg.

Edited January 28, 2023 by deeveedee

[deeveedee]

I updated my Big Sur EFI (still OC 0.8.8) with a few changes to bring my Big Sur EFI closer to my High Sierra EFI.  These changes include changing SSDT-HDMI to SSDT-HDAU.  Note that booting Ventura requires boot-arg -v.  Webcam and Bluetooth do not work in Ventura, but do work well in Big Sur.

 

Note that by setting HDAU.class-code = <FF FF FF FF>, I no longer need boot-arg AlcDelay.  All versions of macOS that I am testing (High Sierra, Big Sur and Ventura) boot quickly with the HDAUoff fix and without boot-arg AlcDelay.

Edited January 28, 2023 by deeveedee

[deeveedee]

I just discovered that I do not need LoadEarly = True for UEFI > Drivers > OpenRuntime.efi.  As advised by @Stefanalmare, I had disabled OpenVariableRuntimeDxe.efi since it is not needed when using OpenDuet, but I did not understand that I also did not need to set LoadEarly for OpenRuntime.efi.  I will continue to test, but it appears that this legacy hack boots fine without any UEFI > Drivers set to LoadEarly.

 

EDIT: I do not know why I don't need UEFI > Drivers > OpenRuntime.efi > LoadEarly = True.  I thought I needed OpenRuntime.efi > LoadEarly = True when UEFI > Drivers > OpenVariableRuntimeDxe.efi was enabled (and OpenVariableRuntimeDxe.efi > LoadEarly = True), but then I disabled OpenVariableRuntimeDxe.efi because I'm using using LegacyBoot/OpenDuet).  The configuration of OpenRuntime.efi, OpenVariableRuntimeDxe.efi, LegacyBoot and LoadEarly are still confusing to me.  Maybe I don't need OpenRuntime.efi > LoadEarly = True because I have set UEFI > Quirks > RequestBootVarRouting = False?  Maybe I never needed OpenRuntime.efi > LoadEarly = True after disabling UEFI > Drivers > OpenVariableRuntimeDxe.efi?

Edited January 28, 2023 by deeveedee

[Stefanalmare]

12 hours ago, deeveedee said:

I just discovered that I do not need LoadEarly = True for UEFI > Drivers > OpenRuntime.efi.  As advised by @Stefanalmare, I had disabled OpenVariableRuntimeDxe.efi since it is not needed when using OpenDuet, but I did not understand that I also did not need to set LoadEarly for OpenRuntime.efi.  I will continue to test, but it appears that this legacy hack boots fine without any UEFI > Drivers set to LoadEarly.

 

EDIT: I do not know why I don't need UEFI > Drivers > OpenRuntime.efi > LoadEarly = True.  I thought I needed OpenRuntime.efi > LoadEarly = True when UEFI > Drivers > OpenVariableRuntimeDxe.efi was enabled (and OpenVariableRuntimeDxe.efi > LoadEarly = True), but then I disabled OpenVariableRuntimeDxe.efi because I'm using using LegacyBoot/OpenDuet).  The configuration of OpenRuntime.efi, OpenVariableRuntimeDxe.efi, LegacyBoot and LoadEarly are still confusing to me.  Maybe I don't need OpenRuntime.efi > LoadEarly = True because I have set UEFI > Quirks > RequestBootVarRouting = False?  Maybe I never needed OpenRuntime.efi > LoadEarly = True after disabling UEFI > Drivers > OpenVariableRuntimeDxe.efi?

I don't use LoadEarly = True in legacy hacks from a while. It is not need for it.