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

[racer]

Syncretic you are legend.

Clean install on cMP Big Sur 11.6. Flawless.
Donation coming your way, many many thanks to you and all the coders keeping our trusty cMPs humming 🙏

 

[splifingate]

OCLP Nightly (0.3.0) via USB to a Sammy 951 on my 5,1 and now I'm in BS 11.6

Everything works, incl. AW6 Unlock.

Only oddity noticed so-far:

System Firmware Version: 9999.999.999.999.999
SMC Version (system): 9.9999

Regards, splifingate

 

[tsialex]

Only oddity noticed so-far:

System Firmware Version: 9999.999.999.999.999
SMC Version (system): 9.9999

Regards, splifingate

It's completely normal, it's a trick to prevent unwanted/incorrect firmware updates when you spoof a newer still supported Mac.

Since the rule for updates is to update whenever a firmware of greater version is available, when you spoof a different board-id you need to spoof 9999.999.999.999.999 for the BootROM and 9.9999 for the SMC to never get a firmware update.

 

[cdf]

Since the rule for updates is to update whenever a firmware of greater version is available, when you spoof a different board-id you need to spoof 9999.999.999.999.999 for the BootROM and 9.9999 for the SMC to never get a firmware update.

To my knowledge this is only a precaution: it is not clear whether incompatible firmware updates (especially for the SMC) could actually be applied on the Mac Pro.

 

[tsialex]

To my knowledge this is only a precaution: it is not clear whether incompatible firmware updates (especially for the SMC) could actually be applied on the Mac Pro.

AFAIK it's never applied because efiflasher checks for the SPI flash memory model/size, but this can indirectly brick a Mac Pro that have a failed garbage collection and is fragmented (also can happen with one that the NVRAM region of SPI flash is over 100K cycles), since several writes happen successively to the NVRAM with very big variables.

Another unwanted behavior, the default boot is changed to the efiflasher and the firmware binary and auxiliary files are also saved to the ESP.

The BootROM is the Achilles heel of Mac Pro, less you mess with it, the better.

 

[austinhealey175]

Put the kids to sleep and come back to my '12 5,1 and it has not only finished downloading the update -- it's sitting there booted into 11.6. Watched the Steve Jobs video on Apple.com then sent a donation. THANK YOU!

 

[cdf]

AFAIK it's never applied because efiflasher checks for the SPI model, but this can indirectly brick a Mac Pro that have a failed garbage collection and is fragmented (also can happen with one that the SPI flash is over 100K cycles), since several writes happen successively to the NVRAM with very big variables.

The SPI model check is probably enough. I've seen the large variables after an update, even with the firmware version spoofing, but with WriteFlash set to disabled in OC, the SPI flash should be protected. (That's the purpose of WriteFlash "to account for firmware that may have issues with NVRAM variable storage garbage collection".)

Another unwanted behavior, the default boot is changed to the efiflasher and the the firmware binary is also saved to the ESP.

Indeed. However, the firmware version spoofing doesn't seem to prevent this.

(Sorry for the off-topic post, but this is too interesting to pass 🤓)

 

[tsialex]

The SPI model check is probably enough. I've seen the large variables after an update, even with the firmware version spoofing, but with WriteFlash set to disabled in OC, the SPI flash should be protected. (That's the purpose of WriteFlash "to account for firmware that may have issues with NVRAM variable storage garbage collection".)


Indeed. However, the firmware version spoofing doesn't seem to prevent this.

(Sorry for the off-topic post, but this is too interesting to pass 🤓)

We're trying to cover all angles of the issue with workarounds to make it as safe as it can be, but since the NVRAM area of the SPI flash can corrupt itself in certain circumstances with just the variables being set-up - some bricks will happen even with WriteFlash/spoofing being enabled, like bricks happened in SoftwareUpdates in the past.

This is not an OC issue in itself, but a MacPro5,1 BootROM design issue that was improved a lot with MacPro6,1 where Apple implemented NAND cell wear spread, for example.

 

[cdf]

some bricks will happen even with WriteFlash/spoofing being enabled, like bricks happened in SoftwareUpdates in the past.

That's very interesting. It also raises a doubt about the effectiveness of spoofing the firmware version.

This is not an OC issue in itself, but a MacPro5,1 BootROM design issue that was improved a lot with MacPro6,1 where Apple implemented NAND cell wear spread, for example.

Absolutely. In fact, OC has proven very useful in this regard (think Windows secure boot certificates). In practice, it's very reasonable to cover all the angles (early on, I adopted the firmware spoofing, and more recently I have installed a Matt card just to be extra safe). I certainly don't doubt the fragility of the BootROM; I'm just curious about whether spoofing the firmware version is actually useful.

 

[minomac]

Impatient much? Rewarding bad behaviour: You've added the patch on the wrong place in your plist. Just follow the instructions at the beginning of the thread.

eh sorry
I was used to the Tonymacx86 community and over there when someone use a "bump" without anyone got offended 🙃

Thanks for pointing me on the "Force" area of Kext: I read fastly and I placed the SurPlus code in the wrong place.

That said even the updated plist, after some reboot attempt, my cMP 5.1 (4.1) is not able to run Big Sure, so there's something wrong.

 

[tsialex]

That's very interesting. It also raises a doubt about the effectiveness of spoofing the firmware version.


Absolutely. In fact, OC has proven very useful in this regard (think Windows secure boot certificates). In practice, it's very reasonable to cover all the angles (early on, I adopted the firmware spoofing, and more recently I have installed a Matt card just to be extra safe). I certainly don't doubt the fragility of the BootROM; I'm just curious about whether spoofing the firmware version is actually useful.

I think that spoofing the EFI and SMC version may still be useful with some specific cases, like with macOS installer when it won't try to set-up the firmware update and also for preventing eficheck service to dump and warn about the wrong EFI.

Thinking about it, this one is a very minor one, when you run SilientKnight (everyone should run it from time to time to check the macOS security status and to keep XProtect/GateKeeper/MRT/TCC/KEXT updated) the spoofed EFI version also fools the EFI version check. So, it's useful for some situations.

 

[cdf]

I think that spoofing the EFI and SMC version may still be useful with some specific cases, like with macOS installer when it won't try to set-up the firmware update and also for preventing eficheck service to dump and warn about the wrong EFI.

This makes sense. Perhaps on the next macOS update with a firmware update for the spoofed model, I'll compare what happens with and without spoofing the firmware version. For science.

 

[oeyvind]

Anyone have any idea... I'm getting kernel panic after installing 11.6

 

[avro707]

Anyone have any idea... I'm getting kernel panic after installing 11.6

Are those some latebloom arguments there, not sure you are supposed to have those anymore now that there is SurPlus. I'm not the expert on these, but I remember removing them from my OC setup when applying the SurPlus fixes. Do you have any other way to get in and modify that?

I always kept two installs, one that works and the other on a different drive that is the "test" version just in case.

 

[splifingate]

It's completely normal, it's a trick to prevent unwanted/incorrect firmware updates when you spoof a newer still supported Mac.

Since the rule for updates is to update whenever a firmware of greater version is available, when you spoof a different board-id you need to spoof 9999.999.999.999.999 for the BootROM and 9.9999 for the SMC to never get a firmware update.

Thank you for the explanation, t

I'm not holding my breath for such updates; but I wasn't holding it for nvme support, either, so...

Regards, splifingate

 

[tsialex]

Thank you for the explanation, t

I'm not holding my breath for such updates; but I wasn't holding it for nvme support, either, so...

Regards, splifingate

It's not for MacPro5,1 firmware updates, but iMacPro1,1 and MacPro7,1 firmware updates being applied incorrectly.

 

[macnrolla]

Anyone have any idea... I'm getting kernel panic after installing 11.6

Can you please try to reset the NVRAM and re-bless the volume, I also had problems at first.

 

[Syncretic]

Anyone have any idea... I'm getting kernel panic after installing 11.6

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

eh sorry
I was used to the Tonymacx86 community and over there when someone use a "bump" without anyone got offended 🙃

Thanks for pointing me on the "Force" area of Kext: I read fastly and I placed the SurPlus code in the wrong place.

That said even the updated plist, after some reboot attempt, my cMP 5.1 (4.1) is not able to run Big Sure, so there's something wrong.

The plist you posted earlier has SurPlus in the Kernel/Add section, it needs to be in Kernel/Patch. If you're still having problems, please post your updated config.plist file as an attachment.

 

[expede]

FileVault is working again!!! Thank you Syncretic!

This is the way!

/Doc

 

[splifingate]

[Addendum to Post #252, above]

Purchased a New Inland Premium 2TB from B&M Microcenter today . . . basically the same as teh Sabrent Blue/Phison E12, but single-sided. My 1TB Sabrents are 2-sided.

Imaged my install on the Sammy p951 to the IP2TB, removed both, moved the IP2TB to the 2nd pci-e16 slot, rebooted twice (first re--boot automatically forced a reboot), and I'm in.

No hiccoughs noted, yet.

Regards, splifingate

 

[HuRR]

Booted into my Monterey SSD and Software Update showed Beta 9. I did not have VMM on at the time. I downloaded the update and it restarted. I saw a volume "Macintosh HD" and "Monterey" (which is my Monterey volume name). OC ran the update install but then just rebooted the next time into Monterey without installing the update. One time it just hung at the boot.

I ended up booting back into my Monterey volume and enabled VMM. Restarted and ran the software update again with VMM enabled. Worked perfectly fine with SurPlus! I'm using the @h9826790 0.7.4 package.

 

[offdwall]

Just another positive data point. I upgraded my 2010 MacPro 5,1 from Catalina to Big Sur 11.6 tonight. I'm using Martin's 0.7.3V2 package, unmodified. I have an updated WIFI/BT card that is recognized natively in Big Sur. The update went very smoothly. I've also got a full PCIe complement of cards with an M.2 NVMe startup drive, a Pro Tools HDX card and a UAD Octo card. Music software is running great, no issues at all!

 

[avro707]

I just had a random restart when attempting to turn on the computer:

I have the PLIST I downloaded before in this topic, no changes made since.

1. turned on computer
2. chimed
3. OC boot menu
4. chose the 11.6 Big Sur on the NVME Samsung 980 Pro (connected via Sonnet card)
5. black screen/restart then it worked

Note: the OC 0.7.3.1 is not on the NVME drive, it's on a normal 2.5" SSD drive connected via SATA.

If there is somewhere I can look, I'll post a log if you advise me where to find it.

I had no issues before this - everything seemed to run perfectly. So if I can find anything that will be of use, I'll provide it.

 

[PeterHolbrook]

I ended up booting back into my Monterey volume and enabled VMM. Restarted and ran the software update again with VMM enabled. Worked perfectly fine with SurPlus!

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.

 

[cdf]

I ended up booting back into my Monterey volume and enabled VMM. Restarted and ran the software update again with VMM enabled. Worked perfectly fine with SurPlus! I'm using the @h9826790 0.7.4 package.

Depending on the versions of macOS that you want to run, you might want to try with SecureBootModel set to Default.

Full Security install in macOS Monterey · Issue #1809 · acidanthera/bugtracker

While #1769 was fixed by acidanthera/RestrictEvents@2430ed0 which allowed macOS Monterey updates with x86legacy, the installer only works with the equivalent of "Medium Security". In other words, i...

github.com

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.

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.