How did you upgraded, any special steps you performed?I'm running 11.3 Beta 4 on my 5,1 MacPro and OC 0.6.3 without issues so far on my PCIe NVME M.2 drive.
How did you upgraded, any special steps you performed?I'm running 11.3 Beta 4 on my 5,1 MacPro and OC 0.6.3 without issues so far on my PCIe NVME M.2 drive.
I followed barrykn's big sur micropatcher and followed his directions on this web page to install BS 11.3 on my MacProHow did you upgraded, any special steps you performed?
I thought you are using OC, technically these patches are not needed for a BS beta upgrade. Am I missing something? @cdf @startergo.Downloaded his latest v0.5.1 micropatcher.
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.@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).
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.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.
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.Also, in part 1, you should mention clearly the OS users have is Mojave, when they reboot after disk blessing.
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 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?
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.I thought you are using OC, technically these patches are not needed for a BS beta upgrade. Am I missing something? @cdf @startergo.
@Macdctr is using a 5,1 MacPro. Also, I don't runSome older Macs, however, are not "essentially supported."
-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.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.@Macdctr is using a 5,1 MacPro.
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.Also, I don't run-no_compat_check
with hardware acceleration.
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'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.
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.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?
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.I started off with Martin Lo's config.plist, which has more parts/pieces that is described in post#1
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 unsure if I need to retain the csr-active-config through run-efi-updater parts or nuke them?
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.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 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.This is very confusing.
That's because you've enabled SIP in OpenCore. That setting takes precedence.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.
The very next section after Hybridization says to keep the key [Post#1 - Clean up the NVRAM]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.
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.Maybe I am mixing 2 things up here?
It does. Everything is already set up in the most generic way possible.Martin Lo's implementation doesn't cover Hybridization....
What I am saying is consistent with the guide: "FindThe 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.
NVRAM
and delete..."That's because I don't recommend using SIP like this.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.
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.Cdf I am curious what other reasons you reccomend to not disable sip in OC?
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.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?
It shouldn't matter.Is there a specific number of words that are allowed for the string? 3 vs 4?
Also shouldn't matter.Or is placement of these 2 lines critial withing the dictionary?
That's a protocol override. It's not necessary.And made sure DeviceProperties was enabled
You may want to try adding the string as a data value instead. For that you'll have to convert the string into base64.....then I unsure how/why I am not getting the prepended "AMD" to display on my graphics card.
I will add or if they are deleted "if present"Note that device properties can only be added if they are not already present in the I/O Registry.
You have to delete an existing property in the delete section of the device properties before it is modified..then I unsure how/why I am not getting the prepended "AMD" to display on my graphics card