Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
How did you upgraded, any special steps you performed?
I followed barrykn's big sur micropatcher and followed his directions on this web page to install BS 11.3 on my MacPro


Downloaded his latest v0.5.1 micropatcher. His method requires you know your way around the terminal app and know how to type manual commands.

I also found this thread helpful


Lots of good information posted by people who are alot more knowledgeable and smarter than I. :)
 
  • Sad
Reactions: PeterHolbrook
@cdf I just read part 1 of your guide (basic installation) and you changed a lot the install process. From your current guide, I have no idea what I have to do to initially install Catalina or Big Sur (which you reference now in part 4). Also, in part 1, you should mention clearly the OS users have is Mojave, when they reboot after disk blessing.

I guess I'm used to the old guide structure which was very clear. Basically, you made the guide to focus on OpenCore basic>advanced installation, then at the very end to install a newer OS into a separate disk, am I seeing this right? If I understand correctly, in part 4, while logged in Mojave, I download the Catalina/Big Sur installer and run it, then select Disk A.
 
@cdf I just read part 1 of your guide (basic installation) and you changed a lot the install process. From your current guide, I have no idea what I have to do to initially install Catalina or Big Sur (which you reference now in part 4).
The simple answer is that it just works. Once booted through OC, installing macOS is just like on a supported Mac, whether installing or updating from an existing installation or a USB installer. As pointed out in Part 4, the only caveat is enabling the VMM flag when installing or updating Catalina. For Big Sur, the VMM flag is not needed.

If I understand correctly, in part 4, while logged in Mojave, I download the Catalina/Big Sur installer and run it, then select Disk A.
In general, the installation can be done from any existing installation or a USB installer. By now, many users have already installed Catalina and may simply wish to install Big Sur from there.

Also, in part 1, you should mention clearly the OS users have is Mojave, when they reboot after disk blessing.
That's because it doesn't have to be Mojave. Installing OpenCore can be done from any natively bootable macOS installation. Mojave is given as an example in the warning message at the beginning of Part 1.

I guess I'm used to the old guide structure which was very clear. Basically, you made the guide to focus on OpenCore basic>advanced installation, then at the very end to install a newer OS into a separate disk, am I seeing this right?
Yes. The focus should be OpenCore, but clarity is more important, so the wiki should be edited if anything remains unclear! Please let me know.
 
I thought you are using OC, technically these patches are not needed for a BS beta upgrade. Am I missing something? @cdf @startergo.
With the proper upgrades, a Mac Pro 5,1 is "essentially supported," requiring really nothing but -no_compat_check to run Big Sur. A pinch of hybridization (board ID spoofing) and a dab of clean, in-memory alterations (WhateverGreen and NightShiftEnabler) is enough to get the computer running as if it were supported. That's the point of this thread.

Some older Macs, however, are not "essentially supported." In that case, rigid patching may be necessary to enable essential features like graphics acceleration. For "essentially supported" machines like the Mac Pro 5,1, my opinion is that rigid patching should be considered undesirable.
 
Some older Macs, however, are not "essentially supported."
@Macdctr is using a 5,1 MacPro. Also, I don't run -no_compat_check with hardware acceleration. I asked all these details because 11.3 release is imminent and I would like to get a clear answer if we can upgrade to it.
 
@Macdctr is using a 5,1 MacPro.
Yes. And as I mentioned above, rigid patching on a Mac Pro 5,1 should be considered undesirable. In this case, perhaps rigid patching does not present the NVMe issue because it is using old kernel extensions. That only hides the issue.

Also, I don't run -no_compat_check with hardware acceleration.
You've misunderstood. I'm not saying that you should run with -no_compat_check. I'm saying that the Mac Pro 5,1 is so nearly supported that it is possible to boot Big Sur without OpenCore with only that boot argument.
 
I'm saying that the Mac Pro 5,1 is so nearly supported that it is possible to boot Big Sur without OpenCore with only that boot argument.
I see, I did not know this. Now, related to 11.3 on NVMe, do we expect any upgrade roadblock from current 11.2.3?
 
I see, I did not know this. Now, related to 11.3 on NVMe, do we expect any upgrade roadblock from current 11.2.3?
Perhaps a delay in updating. Even on hacks, the 11.3 betas are problematic with PCIe devices. With betas, it's always a moving target. I prefer to wait for the release version before addressing issues.
 
  • Like
Reactions: David403
For those that have configure the Hybridzation portion, I could use a second set of eyes on this...
does this seem correct for the "Clean up the NVRAM" ?

I started off with Martin Lo's config.plist, which has more parts/pieces that is described in post#1
So unsure if I need to retain the csr-active-config through run-efi-updater parts or nuke them?

1616725586422.png


The info in Post#1 shows this:
1616733193475.png


Martin Lo's OC Pkg looks like this (untouched)
1616733225079.png


So I am unsure if I need to be removing line 405 and then change the tags for line 403 && 404 and nuke lines 406-409 ?? I also reached out to Martin on his youtube video. This is very confusing.



UPDATE: Side Note, Also attempting to enable SIP in this same section, I noticed that trying to disable SIP using the BigSur Recovery Partition DOES NOT work. I'll need to get my OEM GPU back in and either boot from a USB installer or see if my vanilla Mojave recovery will allow SIP to be disabled, then I can reattempt this.
 
Last edited:
I started off with Martin Lo's config.plist, which has more parts/pieces that is described in post#1
Martin's package is like a Swiss army knife. It contains almost everything you'll ever need. On the other hand, the approach in the guide here strives for minimality.

So unsure if I need to retain the csr-active-config through run-efi-updater parts or nuke them?
If you want to use SIP as intended by macOS, then you should not be setting csr-active-config in OpenCore. Also, run-efi-updater does not work in Big Sur.

So I am unsure if I need to be removing line 405 and then change the tags for line 403 && 404 and nuke lines 406-409 ??
If you've already done the hybridization as described in the guide, then you can go ahead and delete the key and corresponding dictionary block in the Add section and delete the key and corresponding array in the Delete section.

This is very confusing.
If you've opted for the hands-on approach described in the guide, then I would recommend building your configuration from the sample file provided in the guide.

UPDATE: Side Note, Also attempting to enable SIP in this same section, I noticed that trying to disable SIP using the BigSur Recovery Partition DOES NOT work.
That's because you've enabled SIP in OpenCore. That setting takes precedence.
 
@cdf I do not disagree on what you said with Martin Lo's being a swiss army knife, I'm a fan of his work by far!... It's made this implementation much easier!

Per your comments, I need a little more clarification:

If you've already done the hybridization as described in the guide, then you can go ahead and delete the key and corresponding dictionary block in the Add section and delete the key and corresponding array in the Delete section.
The very next section after Hybridization says to keep the key [Post#1 - Clean up the NVRAM]
You are now say to delete the key/dict in the Add and Delete sections. Would you be able to modify the Post#1 to match what you are suggesting?

1616772533480.png


As for SIP, I am wanting to have OC manage this, so I will need to boot into recovery with mojave and disable it, then reboot. Once that is complete, I will need to update OC config.plist with:
where dwgAAA = OFF and AAAAAA = ON (per Martin's instruction)
1616773086920.png

....but you just mentioned to Delete the Key/Dict for NVRAM.


Maybe I am mixing 2 things up here?
Martin Lo's implementation doesn't cover Hybridization.... So if you elect to use Hybridization, then you cannot delete the NVRAM key/dict from the Add/Delete sections? Or am I incorrect on this?
 
Maybe I am mixing 2 things up here?
Yes, you are. Unless you already have a good understanding of how to configure OpenCore, you should not try to adapt the configuration from Martin's package by following the guide here. Martin's package is intended for users that want all the features without being bothered by the details of the configuration process and don't mind running with settings that are really intended for debugging, such as boot arguments and SIP override.

Martin Lo's implementation doesn't cover Hybridization....
It does. Everything is already set up in the most generic way possible.

The very next section after Hybridization says to keep the key [Post#1 - Clean up the NVRAM]
You are now say to delete the key/dict in the Add and Delete sections.
What I am saying is consistent with the guide: "Find NVRAM and delete..."

As for SIP, I am wanting to have OC manage this, so I will need to boot into recovery with mojave and disable it, then reboot. Once that is complete, I will need to update OC config.plist with:
where dwgAAA = OFF and AAAAAA = ON (per Martin's instruction)
View attachment 1749651
....but you just mentioned to Delete the Key/Dict for NVRAM.
That's because I don't recommend using SIP like this.
 
I contemplated using OC to disable SIP but I often boot into Mojave without OC for various reasons and want it disabled all the time. There is no getting around it.

another option is to use RefindPlus chainloader setup which has an option to disable sip manually from there, to avoid having to go to recovery mode to do it. However the irony is that in order to bless the EFI, you have to disable sip in recovery mode to begin with. So there is no getting around going to recovery mode at least once and I just leave it disabled after that anyway.

I guess refindplus makes it easy to turn sip off and on at will once you have blessed the efi partition that has OC and RP config. I never turn it back on anyway though.

Cdf I am curious what other reasons you reccomend to not disable sip in OC?
 
You don't have to delete keys when experimenting with config.plist, you can comment out lines...

e.g. like this:

<!--
<key>csr-active-config</key>
<data>dwgAAA==</data>
-->

Comment out lines in plist.png


This makes my SIP work normal

"Added support for xml comments in plist files" from OpenCore 0.6.3.
 
Last edited:
@cdf
I do apologize.... After re-reading for the 4th time, I see the error of my mistake.
I was stuck in a path from the previous step of "Change THIS TO THAT", when this step wants 2 parts removed.
Remove THIS and THAT (The boxes below).

Couple more question on this...
  • Is the "Clean up NVRAM" instruction part of the Hybridization and Related settings" ?
  • What is the purpose of removing these two sections?
This is from the sample config.plist
1616784915478.png
 
Last edited:
Another item.... This refers to the cosmetic issue some have experienced with Vega 64's showing as NA in VideoProc

I have the following set:
Set the key/string for model and name

Is there a specific number of words that are allowed for the string? 3 vs 4?
AMD Radeon Vega 64 ?
AMD Vega 64 ?
Or is placement of these 2 lines critial withing the dictionary?
1616803269167.png


And made sure DeviceProperties was enabled
1616803320373.png


Rebooted...
But still getting:
1616803359387.png
 
Last edited:
Cdf I am curious what other reasons you reccomend to not disable sip in OC?
I was referring to how SIP is treated in that configuration: it has csr-active-config in both the Add and Delete sections, completely overriding the value set by csrutil. Notice that in the Acidanthera sample, csr-active-config is found only in the Add section, ensuring a default value while preserving the functionality of csrutil.

The point of setting SIP in OpenCore is to ensure a default value (00000000 or ON) after an NVRAM reset. This practice is useful for non-Apple hardware. But for real Macs, the default is already managed properly, and changing that default (to OFF or a variant thereof) may be considered undesirable.

Of course, that's not to say that managed defaults are always better. For example, UIScale defaults to 1 on the classic Mac Pro, but when using HiDPI displays, it makes sense to completely override it to 2. The same can be said about DefaultBackgroundColor. Of course, these are both cosmetic concerns. SIP, however, is a security concern.
 
Couple more question on this...
  • Is the "Clean up NVRAM" instruction part of the Hybridization and Related settings" ?
  • What is the purpose of removing these two sections?
I suppose that cleaning up the NVRAM is part of the "Related settings," but it's not a functional requirement for hybridization; it's a recommendation that is consistent with how OpenCore and other Acidanthera projects are designed so that boot arguments are for temporary configurations.
 
@cdf
....then I unsure how/why I am not getting the prepended "AMD" to display on my graphics card.
I'll revert the changes I mentioned for this issue and chalk it up as an "unknown" issue for now.... especially since it is purely cosmetic at this point.

Should someone else have any possible solutions to this in the future I will revisit the issue.

I greatly appreciate everyone's help, this thread has a TON of value!
Should also have my new unbooted BootRom soon from Alexandre to correct my NVRAM.
 
....then I unsure how/why I am not getting the prepended "AMD" to display on my graphics card.
You may want to try adding the string as a data value instead. For that you'll have to convert the string into base64.
 
Note that device properties can only be added if they are not already present in the I/O Registry.
I will add or if they are deleted "if present"
.then I unsure how/why I am not getting the prepended "AMD" to display on my graphics card
You have to delete an existing property in the delete section of the device properties before it is modified.
 
  • Like
Reactions: Dayo and cdf
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.