Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

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.
Hi All, I took a dive into OpenCore last week in an attempt to fix OTA updates while running Big Sur beta on a 2012 9,1 Macbook Pro. I previously used the dosdude patcher to successfully upgrade this machine to Big Sur 11.1 and was trying to find a solution to the lack of OTA updates. While going via the OpenCore route, I seem to have done more harm than good.

I downloaded the Opencore code, created a USB flash drive, booted to that on the mac and created both the Opencore configuration for this machine as well as installed it. I did this via the Opencore boot menu. In the process, the changes appear to have caused a conflict with whatever it wrote onto the machine's firmware.

I did a full erase and install of the built-in SSD and I am now successfully running Catalina on the same machine without issues. My erase and install sufficiently cleaned the hard drive, but obviously there could still be opencore changes present on the machine's logic board. The patched big sur installer will no longer run- and when trying to boot to the patched USB installer I receive the "Prohibited" sign.

In short my question is this- is there an easy way to remove any configuration changes that Opencore made to my machine (not just the hard drive)? If not, is there a way to re-flash the firmware with the original EFI boot firmware that would have been on my machine prior to attempting to go the OpenCore route?

Lesson learned on my end..... thanks!
 
Bmju said:
As I'm (slowly) getting to understand what OpenCore can do for us, it's starting to look more and more that an awful lot of the discussion on this thread is applicable to using OpenCore on any legacy Mac, not just the Mac Pro (cf the question above, actually!).

So I was just wondering:

Do people agree that that impression is true?

Is the thread open to questions about using OpenCore (at least, with configs based off the page 1 config) on Macs other than the Mac Pro?

If yes to the above, I was also wondering, is it possible/likely that the thread title &/or the p.1 info might be updated to point out that some/much of this approach, and discussion, might be relevant not just on the Mac Pro? Or if not, I suppose would it be an idea to have another thread for this?

I'm asking the last question particularly because, although I've been dipping in and out of this thread, I've mainly been on this one instead, and been assuming (because of the title and p.1 description) that the basic steps on p.1 here were 'not for me' (with a MacBookPro10,2) - but now that I understand OC better, and having been pointed back here again by several people, I can see that the basic config and parts of the advanced config are just fine for me, and cleaner (far fewer unnecessary settings) than any other OC config I've come across too, which I greatly prefer! 🥳

Thanks! (Esp. to @cdf, @h9826790 and others for working on this approach! 😊)
Click to expand...

Dortiana has now added a new guide specifically for Legacy Macs. It currently is a work in progress. This promises to be a useful resource for all owners of Legacy Macs. The URL to this guide is not included on their main guide page yet but I have included the URL below.

Dortania's OpenCore For Legacy Macs

The introduction states:

"This guide currently revolves around Big Sur support for legacy Macs, in the future we do plan to expand for more OS support. However please keep in mind this guide is for those who want to learn how to patch their machine, this is not an automated tool and you will be expected to do work." For more beginner friendly tools they provide links to recommended patchers.

The Legacy Macs guide provides specific OpenCore config.plist recommendations for:

​

 
  • Like
Reactions: Bmju
bpearson85 said:
If not, is there a way to re-flash the firmware with the original EFI boot firmware that would have been on my machine prior to attempting to go the OpenCore route?
Click to expand...
Now the question is:
Do you have a backup of that firmware (not the firmware in the Update, but your specific firmware backup)? If yes then it is easy.
 
bpearson85 said:
Hi All, I took a dive into OpenCore last week in an attempt to fix OTA updates while running Big Sur beta on a 2012 9,1 Macbook Pro. I previously used the dosdude patcher to successfully upgrade this machine to Big Sur 11.1 and was trying to find a solution to the lack of OTA updates. While going via the OpenCore route, I seem to have done more harm than good.

I downloaded the Opencore code, created a USB flash drive, booted to that on the mac and created both the Opencore configuration for this machine as well as installed it. I did this via the Opencore boot menu. In the process, the changes appear to have caused a conflict with whatever it wrote onto the machine's firmware.

I did a full erase and install of the built-in SSD and I am now successfully running Catalina on the same machine without issues. My erase and install sufficiently cleaned the hard drive, but obviously there could still be opencore changes present on the machine's logic board. The patched big sur installer will no longer run- and when trying to boot to the patched USB installer I receive the "Prohibited" sign.

In short my question is this- is there an easy way to remove any configuration changes that Opencore made to my machine (not just the hard drive)? If not, is there a way to re-flash the firmware with the original EFI boot firmware that would have been on my machine prior to attempting to go the OpenCore route?

Lesson learned on my end..... thanks!
Click to expand...
If you don't have a dump from your BootROM image, totally forget it.

The generic upgrade image Apple provide is not the complete BootROM, but just the updated parts common to all Macs of your model, without any personalisation. If you use it, you will lose the ability of login with iCloud/Messages/FaceTime.

BTW, differently from Mac Pros, you will have to flash externally via a SPI flash programmer. You can't use flashrom/ROMTool to flash it like we do.
 
Bmju said:
any of the DataHub, Memory, PlatformNVRAM and SMBIOS sections can be validly completely omitted
Click to expand...
I will keep all of them and their failsafe values into plistlib generator because it will remove the burden of setting these values if end-user decides to use one custom setting for any of the above listed properties. As @vit9696 mentioned, the correct approach is to define ALL properties and their matched keys/failsafe values into config.plist file.
 
bpearson85 said:
Hi All, I took a dive into OpenCore last week in an attempt to fix OTA updates while running Big Sur beta on a 2012 9,1 Macbook Pro. I previously used the dosdude patcher to successfully upgrade this machine to Big Sur 11.1 and was trying to find a solution to the lack of OTA updates. While going via the OpenCore route, I seem to have done more harm than good.

I downloaded the Opencore code, created a USB flash drive, booted to that on the mac and created both the Opencore configuration for this machine as well as installed it. I did this via the Opencore boot menu. In the process, the changes appear to have caused a conflict with whatever it wrote onto the machine's firmware.

I did a full erase and install of the built-in SSD and I am now successfully running Catalina on the same machine without issues. My erase and install sufficiently cleaned the hard drive, but obviously there could still be opencore changes present on the machine's logic board. The patched big sur installer will no longer run- and when trying to boot to the patched USB installer I receive the "Prohibited" sign.

In short my question is this- is there an easy way to remove any configuration changes that Opencore made to my machine (not just the hard drive)? If not, is there a way to re-flash the firmware with the original EFI boot firmware that would have been on my machine prior to attempting to go the OpenCore route?

Lesson learned on my end..... thanks!
Click to expand...
Hi! There is no big issue here, I believe. (And you will be glad to know... if I am right!)

in order to allow yourself to boot into the patched installer you need to boot into recovery mode (as you probably know, boot holding down CMD+R), then open a Terminal (from recovery Tools menu), and type nvram boot-args="-no_compat_check" and press return. Then restart, and you will (I pretty sure) be able to boot your patched installer. (EDIT: It's meant to show a no entry sign, on an unpatched Mac of your model! Apple says it is not compatible with your hardware.)

The issue is not that OpenCore has left something that is stopping things from working, but rather that you have lost something temporary (an NVRAM value; which can always be removed by an NVRAM reset, i.e. boot with CMD+OPTION+P+R) which OC left behind which was making things work!
 
Last edited:
TECK said:
I will keep all of them and their failsafe values into plistlib generator because it will remove the burden of setting these values if end-user decides to use one custom setting for any of the above listed properties. As @vit9696 mentioned, the correct approach is to define ALL properties and their matched keys/failsafe values into config.plist file.
Click to expand...
Please, leave them in, and the reason you have mentioned for doing so is a good reason. But it's still true that, notwithstanding your link and the apparent long-standing advice, the docs have just recently been updated to make it quite explicit that you do not have to include those specific sections under well defined circumstances. I have not got that wrong! Equally, though, you certainly still can include them, even under those circumstances, and you've given one perfectly good reason for doing so.

Screenshot 2021-02-08 at 17.12.54.png
 
bpearson85 said:
I took a dive into OpenCore last week in an attempt to fix OTA updates
Click to expand...
Just to correct something mentioned a few times in your post. OpenCore does not change nor write anything to the firmware.

If you used the OCLP as opposed to the setup provided in Post 1 of this thread as I suspect might have been the case, then what happened was that OpenCore was used to present your machine as another model by the OCLP as it does "Full Spoofing", basically in the same way a Hackintosh works. This is not how the settings in Post 1 work as they are designed for real Macs.

Anyway, when you then ran the BigSur Update, seeing your machine as something else, updates for that something else were written to your firmware by the BigSur Update Package (Not OpenCore).

I know you still ended up with your firmware corrupted while using OpenCore, but just wanted to point out the real instigator.

Hopefully you have a BootROM backup and can recover the situation.
 
Bmju said:
Please, leave them in, and the reason you have mentioned for doing so is a good reason. But it's still true that, notwithstanding your link and the apparent long-standing advice, the docs have just recently been updated to make it quite explicit that you do not have to include those specific sections under well defined circumstances. I have not got that wrong! Equally, though, you certainly still can include them, even under those circumstances, and you've given one perfectly good reason for doing so.

View attachment 1727110
Click to expand...
Oh dear, and despite my having got the contents of the documentation right, I have got what you are allowed to remove completely wrong, because I am used to using Automatic=true (not to do a full SN fake, but as a different way to do a hybrid, board-id only fake...) and you are using Automatic=false, so you really should not remove them. I apologise.
 
@bpearson85:

Dayo said:
Just to correct something mentioned a few times in your post. OpenCore does not change nor write anything to the firmware.

If you used the OCLP as opposed to the setup provided in Post 1 of this thread as I suspect might have been the case, then what happened was that OpenCore was used to present your machine as another model by the OCLP as it does "Full Spoofing", basically in the same way a Hackintosh works. This is not how the settings in Post 1 work as they are designed for real Macs.

Anyway, when you then ran the BigSur Update, seeing your machine as something else, updates for that something else were written to your firmware by the BigSur Update Package (Not OpenCore).

I know you still ended up with your firmware corrupted while using OpenCore, but just wanted to point out the real instigator.

Hopefully you have a BootROM backup and can recover the situation.
Click to expand...

I'd like to repeat and reemphasize what @Dayo says. OpenCore is very clean, it does not work by changing things on your Mac, it works by 'injection', i.e. only if you start it it changes things in memory only, and as they are loaded.

I'm replying to @Dayo's reply, though, to say again that I don't think your firmware is bust at all. On my similar-ish model MacBookPro10,2 I got no entry signs all the time when playing around sometimes with and sometimes without OpenCore. It is completely normal.

I do think that if you want to use Big Sur with delta OTA updates, then you are going to have to set up a config where you essentially always - or at least normally, by default - boot through OC, otherwise you are going to keep seeing no entry signs for Big Sur (and its installers), because it is an incompatible OS on your machine, and you are going to keep having to apply manual fixes.

There are extensive discussions of all this on this other thread, by the way.
 
Last edited:
TECK said:
Until a novice adds ONLY one property custom key/value and ocvalidate shoots a ton of errors about the missing properties.
Click to expand...
It is currently academic, since like I admitted, I got it completely backwards and you guys (on Automatic=false) are NOT allowed to remove these sections anyway!

For someone on Automatic=true (where the sections optionally, but officially, can be left out) (or, perhaps, for the Memory section, which has a separate rule and can be left out if CustomMemory is false) perhaps the decision is moot - I mean OC thought so, enough to make the sections officially optional in those circumstances, with clarification to confirm it. But I can certainly see the sense in the view you are taking, I must say. There is much greater added convenience for the more experimental user if all the properties are there already! Thank you.
 
Last edited:
@Bmju With CustomMemory=False, Memory property keys are ignored, regardless you have them present or not. However, there is a different story when you set CustomMemory=True.

Also, from a developer perspective, I would not set Automatic=True on a Mac because I want to use the OEM values, not Generic values.
 
TECK said:
No, OC does everything for you. Same for Catalina, not just Big Sur.
Click to expand...
TECK,

Where can I see how to set it up? Is there a guide to the settings needed for enabling Continuity? I would appreciate any pointers.

Right now I am actually only using OC on a USB stick to do updates and am generally booting just using no_compat_check. I have a flashed GTX680 so really have no issues between Mojave, Catalina, and as of a few days ago Big Sur.

Regards,
SMF
 
TECK said:
@Bmju With CustomMemory=False, Memory property keys are ignored, regardless you have them present or not. However, there is a different story when you set CustomMemory=True.

Also, from a developer perspective, I would not set Automatic=True on a Mac because I want to use the OEM values, not Generic values.
Click to expand...
I agree with the first.

I'd still like to try to point out, again, what seems like it must be a misapprehension behind the second: you can have auto-detected, OEM values with Automatic=true. Read the OC docs, even if you don't believe it just from me! I'm not therefore suggesting that all projects immediately change to Automatic=true, and I *agree* with you about the undesirability of faked serial numbers. "Because it's used for fake values in the Hackintosh community" is not the same was "it can only be used to fake values". Honestly!
 
Bmju said:
I'd still like to try to point out, again, what seems like it must be a misapprehension behind the second: you can have auto-detected, OEM values with Automatic=true. Read the OC docs, even if you don't believe it just from me!
Click to expand...
Yes, but only since very recently. Please give people the chance to adjust.
 
  • Like
Reactions: Bmju
Bmju said:
Read the OC docs, even if you don't believe it just from me!
Click to expand...
I may be wrong but my understanding is that @TECK design goal is to, more or less, automate the production of the config in Post 1. If that understanding is correct, then unless @cdf changes the config, @TECK is not going to be straying away from that.

The config changes about one a month.
 
  • Like
Reactions: Bmju
Bmju said:
you can have auto-detected, OEM values with Automatic=true. Read the OC docs, even if you don't believe it just from me
Click to expand...
This is from latest master branch:

The Warning is clear, set it to False while doing minor corrections of SMBIOS, like we do, therefore I'm leaving the property set to False.

1612814389457.png
 
  • Like
Reactions: cdf
I have successfully installed OpenCore, and then clean-installed Big Sur on that same drive, on my Mac Pro (4,1 > 5,1) with dual E5520 (Nehalem) processors. Much praise to the developers is due: besides the advantages of updating, doing so resolved two issues I had using Catalina on this same machine, namely a recurring kernel panic after sleeping, as well as the infamous crackling audio bug. It has been previously mentioned in this thread that OpenCore is not a solution for the audio bug, and the only accepted solution in the relevant thread is to replace the processors, but hey, I guess I'm in luck (knock on wood and all that).

Any advice on what parts of the advanced configuration I should apply? It appears to me that hardware acceleration is not supported with my graphics card, so I don't believe that to be necessary.
 
Dayo said:
I may be wrong but my understanding is that @TECK design goal is to, more or less, automate the production of the config in Post 1
Click to expand...
Actually, my goal is to provide a vanilla config.plist with all failsafe (default) OC settings, as you can see into current setup.py file. Next, I provide a wiki page where all settings @cdf has defined into OP are applied (including hardware acceleration, external disks to internal, Night Shift enabler etc.) so users understand how easy is to maintain and upgrade their OC tree and config.plist by maintaining only the setup.py file. The advantage of this custom setup.py example is that it allows users to easily see what is changed, compared to original OC settings. Plus, they can also see the historical changes between several OC versions behind, which is the most important part. This gives a lot of flexibility to users, testing custom settings they want to experiment with, while generating the entire EFI and config.plist with the press of a button.

Example:
Code: 
'Booter': {
    'Quirks': {
        'ProtectSecureBoot': True
    }
}
The OC Booter failsafe ProtectSecureBoot value is False, but you can set it easy to True into setup.py file. Your config.plist will contain the updated value True, instead of False.

Since I maintain the failsafe settings (in collaboration with @cdf), the end-user will always have very little work effort on his side, his setup.py will only change during major macOS releases like it happened with Big Sur.
 
Last edited:
  • Like
Reactions: Bmju, Norbert Mikołajczyk and Dayo
startergo said:
In what respect? Please elaborate. is this an MSI card? If it is see this:
github.com

Installer not working with 5700XT (pikera) · Issue #901 · acidanthera/bugtracker

Z390 - ASUS-Z390F i9 9900k 5700XT OC 0.5.8 Latest - Lilu 1.4.4 and Whatevergreen - 1.3.9 When clean install using 5700XT installer fails with crash. Installer Log 6-May-2020.txt Removed pikera mod ...
github.com github.com
Click to expand...
in the respect of modifying my config file. it is an MSI card. nothing is crashing, i don't know what pikera is.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back