MP 1,1-5,1 SurPlus - The Big Sur/Monterey fix you've been waiting for.

[h0miesexual__]

I've posted my findings about the MacOS 11.3+ "race condition" bug, along with a patch I'm calling SurPlus, in a github repository. All the details are there, and I'm not sure there's any benefit in reposting them all here. (Yes, I had to write my own debugger; the boot hangs generally happened before the boot was far enough along for MacOS' remote debugging facility to work, so drastic measures were required.)

This thread will serve for questions (hopefully with answers), comments, and discussion regarding SurPlus.

In a nutshell: our Classic Macs will live to fight another day. As of now, latebloom is deprecated. Install the three-byte SurPlus patch in your OpenCore config.plist and boot Big Sur or Monterey just as you would Catalina or Mojave.

PLEASE: If you're going to post in this thread because you're having trouble getting the patch to work, please include your OpenCore config.plist file as an attachment. Without that, it's very difficult to offer assistance.

So I am working on getting it to work but whenever in verbose trouble shooting it gets stuck saying something about the IHuntKeysInNVRAM (or something similar not being found) I'm still learning opencore so help would be greatly appreciated. config attached below

 

[oeyvind]

You have latebloom installed, and it's unclear if you have SurPlus installed. Please post your config.plist file as an attachment.

Managed to fix my problem by using the h9927790's 0.7.4 beta config

Thanks Syncretic!

 

[Cococollector]

Just.
Works.
Great work, @Syncretic ! That's wizardry!

Up to now, I found no information (or rather positive confirmation) whether OC for AHCI. I've now installed Big Sur via OCLP 0.3 on a SATA disk, booting from AHCI on PCIe is to follow.

Spoiler: System

4,1 flashed to 5,1; 6x 3,33; 24GB RAM; Samsung 951 AHCI (Mojave boot disk); Samsung 960 SSD SATA (Big Sur test disk); RX580 8GB; TitanRidge; Inateck USB 3.0; WiFi BCM94360CD;

 

[splifingate]

Just.
Works.
Great work, @Syncretic ! That's wizardry!

Up to now, I found no information (or rather positive confirmation) whether OC for AHCI. I've now installed Big Sur via OCLP 0.3 on a SATA disk, booting from AHCI on PCIe is to follow.

Spoiler: System

4,1 flashed to 5,1; 6x 3,33; 24GB RAM; Samsung 951 AHCI (Mojave boot disk); Samsung 960 SSD SATA (Big Sur test disk); RX580 8GB; TitanRidge; Inateck USB 3.0; WiFi BCM94360CD;

I installed BS-S+ fresh to a 512GB Samsung 951 AHCI (Lenovo OEM, iirc) the other day to perfect success.

No problems whatsoever; just too small for regular use.

Regards, splifingate

 

[khronokernel]

Although I haven't really looked into it, there is now a VMM-related patch:

Support Spoofless Approach via VMM by khronokernel · Pull Request #548 · dortania/OpenCore-Legacy-Patcher

Ref: #543

github.com

Perhaps @khronokernel could chime in with some details.

Something specific you'd like me to elaborate on? To avoid repeating ourselves, you can see our connected issue:

• Github Issues: Supporting Spoofless Usage

 

[LFO8]

I must say.. the installation of Monterey beta 8 went flawlessly thanks to this patch. And my cMP 5,1 is so well behaved under Monterey!

Thank you!

 

[macrumorsnumpty]

OCLP 3.0 updated on my Mac Pro 5,1 - 11.3 to 11.6 installation went smoothly. Thank you so much.

Saw the donation link and acted on it. TY.

 

[thatsmeonlyme]

updated my cMP 5.1 (2010) to Monterey B9. Everything is working fine.

 

[GSXB]

success with beta 9 installed from desktop with the full installer from mr Macintosh
opencore 0,7,4 with SecureBootDevice disabled and the vmm flag enabled

 

[mangombia]

View attachment 1860772
success with beta 9 installed from desktop with the full installer from mr Macintosh
opencore 0,7,4 with SecureBootDevice disabled and the vmm flag enabled

Question: Is VMM Flag enabled only needed for install/updates (as for Catalina), or is it necessary to remain in place even after install for Monterey?

 

[MoerBoer]

Thank you SO much!

I went directly from Mojave to Big Sur 11.6 ( with FileVault on the NVME ) and it's running smooth as butter!

 

[cybercylon]

Here is another data point for a Mac Pro 5 1. Even with latebloom, booting with >11.2.3 was better but still dodgy. With SirPlus, I did an upgrade from Catalina to 11.6, and all went well. I know my 5,1 can survive many warm reboots now as for some reason, my Ubuntu install no longer works (and neither does the reinstall). I don't consider that issue to be an OpenCore or Surplus related though. Likely something I messed up...

Glad for all of the hard work that sorted this out though. Otherwise, many would be lamenting the loss of security updates to Catalina at this time next year.

Donation definitely in order.

 

[h9826790]

Question: Is VMM Flag enabled only needed for install/updates (as for Catalina), or is it necessary to remain in place even after install for Monterey?

If you have backup boot drive (e.g. Big Sur), please try disable VMM and see if you can still boot beta 9.

Initially, we assume the VMM flag is only required for installation. But may be that's also required to run Monterey now.

 

[cdf]

I wonder if this finally confirms that the VMM flag must be set for Monterey installs and updates to be possible on Mac Pros booted via OpenCore. It would be great if some other workaround were possible.

Question: Is VMM Flag enabled only needed for install/updates (as for Catalina), or is it necessary to remain in place even after install for Monterey?

Initially, we assume the VMM flag is only required for installation. But may be that's also required to run Monterey now.

I can confirm that Monterey beta 9 (21A5543b) is installable and bootable without the VMM flag. The installation merely requires adding a FirmwareFeatures bit to the corresponding PlatformNVRAM variables.

Something specific you'd like me to elaborate on?

Sure. If the VMM flag ends up being required for OTA updates (as is the case in Catalina with minimal spoofing), then could the new patch be used instead (even though the patch is really aimed at a spoofless configuration)?

 

[khronokernel]

If the VMM flag ends up being required for OTA updates (as is the case in Catalina with minimal spoofing), then could the new patch be used instead (even though the patch is really aimed at a spoofless configuration)?

It could, and would alleviate the concerns for FirmwareFeatures issues. As Dhiank and I found, Beta 7+'s patchd will run through a few checks before finishing sealing:

• Check presence of kern.hv_vmm_present
  • If present, assume firmware supports everything require
• Else, check if firmware supports APFS and Large BaseSystem
  • iMac17,1 have explicit exemption from BaseSystem support check
  • Check is done based off ROM and NVRAM

Once these checks pass, patchd will finish with APFS sealing. Currently that's the only area that checks for Large BaseSystem support.

Then I bugged Vitaly and we got that added to OC, as seen with this commit:

• https://github.com/acidanthera/OpenCorePkg/commit/1cb8490fd60f6b5f983d42e5bbf08e3d2d43d8f6

With OTA updates, the main issue Dhiank found was Pallas dropped support for T2 Board IDs and instead required the SecureBootModel identifier to be passed. So one can either:

• Enable SecureBootModel as per this commit:
  • https://github.com/acidanthera/OpenCorePkg/commit/7583455f11ef15d50df4aca49f1d90eff39d5c2f
• Switch to a non-T2 Board ID (ie. iMac19,1)
• Force VMM flag to set VMM-x86_64
  • Can be done either with VMM flipped in CPUID, or use our VMM patch
  • Additionally RestrictEvents supports reporting kern.hv_vmm_present status based off process used with -revsbvmm

 

[PeterHolbrook]

RestrictEvents supports reporting kern.hv_vmm_present status based off process used with -revsbvmm

As far as preserving the computing power of the cMP 5,1 goes, what is more effective? Setting the VMM flag via the CPUID or using the (new?) RestrictEvents kext?

 

[cdf]

As far as preserving the computing power of the cMP 5,1 goes, what is more effective? Setting the VMM flag via the CPUID or using the (new?) RestrictEvents kext?

Well, the VMM flag via the CPUID has always been intended as a temporary solution for installations and updates. You flip it back after, so performance and power management are nonissues. Now, if you intend on always leaving it, then any of the other solutions, including RestrictEvents would certainly be preferred. My preference would be the FirmwareFeatures and SecureBootModel solution, provided that it keeps working.

 

[PeterHolbrook]

Well, the VMM flag via the CPUID has always been intended as a temporary solution for installations and updates. You flip it back after, so performance and power management are nonissues. Now, if you intend on always leaving it, then any of the other solutions, including RestrictEvents would certainly be preferred. My preference would be the FirmwareFeatures and SecureBootModel solution, provided that it keeps working.

Thanks, @cfd. I hope you can provide an exemplary setup of OC using one or both of those solutions, perhaps when 0.7.5 is released (?) or shortly before Monterey is officially released.

 

[cdf]

I hope you can provide an exemplary setup of OC using one or both of those solutions, perhaps when 0.7.5 is released (?) or shortly before Monterey is officially released.

Absolutely!

 

[GSXB]

Question: Is VMM Flag enabled only needed for install/updates (as for Catalina), or is it necessary to remain in place even after install for Monterey?

the VMM flag is only required for installation purposes, once installed it can be turned off

 

[GSXB]

I can confirm that Monterey beta 9 (21A5543b) is installable and bootable without the VMM flag. The installation merely requires adding a FirmwareFeatures bit to the corresponding PlatformNVRAM variables.



Sure. If the VMM flag ends up being required for OTA updates (as is the case in Catalina with minimal spoofing), then could the new patch be used instead (even though the patch is really aimed at a spoofless configuration)?

there's no need to add to the config it will boot Monterey beta9 without the VMM flag

 

[cdf]

there's no need to add to the config it will boot Monterey beta9 without the VMM flag

Please carefully re-read my post. That's precisely what I said. I even underlined "without."

Edit: To further clarify, something was indeed added to your config (whether you did it yourself or not) for installing Monterey. See post #290, which very comprehensively lays out the options.

 

[jameslmoser]

Here is another data point for a Mac Pro 5 1. Even with latebloom, booting with >11.2.3 was better but still dodgy. With SirPlus, I did an upgrade from Catalina to 11.6, and all went well. I know my 5,1 can survive many warm reboots now as for some reason, my Ubuntu install no longer works (and neither does the reinstall). I don't consider that issue to be an OpenCore or Surplus related though. Likely something I messed up...

Glad for all of the hard work that sorted this out though. Otherwise, many would be lamenting the loss of security updates to Catalina at this time next year.

Donation definitely in order.

My fedora drive no longer boots either unfortunately. I went from OC 0.5.9 to 0.7.3. It still works with 0.5.9.

 

[GSXB]

Please carefully re-read my post. That's precisely what I said. I even underlined "without."

Edit: To further clarify, something was indeed added to your config (whether you did it yourself or not) for installing Monterey. See post #290, which very comprehensively lays out the options

I was referring to adding firmware features that is not in my config, and to clarify I did read you post correctly and the variables you are adding are being removed In The next release. As for SecureBootDevice setting that to default disables the ability to boot Mojave so for me Disabled is the best option there

 

[cdf]

I was referring to adding firmware features that is not in my config,

That's fine. Monterey will still boot without the extra FirmwareFeatures bit. As my post states, the extra bit is for the installation, not booting.

and to clarify I did read you post correctly and the variables you are adding are being removed In The next release

Next release of what? Besides, as post #290 explains, the extra FirmwareFeatures bit is not the only option, but something indeed needs to be added.

As for SecureBootDevice setting that to default disables the ability to boot Mojave so for me Disabled is the best option there

My post clearly states that the FirmwareFeatures and SecureBootModel solution is my preference. You are of course free to choose whichever solution is best for you.

As far as I'm concerned this issue is settled, and, as an off-topic parenthesis, it shouldn't be dragged any further. Remember, this thread is about SurPlus, undoubtedly one of the top achievements in prolonging the life of the classic MacPro!