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.
I am able to boot from cold boot and shutdown without any issue; however, when I do a restart, the startup screen terminates with the stop symbol, circle with a diagonal through it. This is reproducible.
I may have changed a setting in my config.plist inadvertently as I have been using OpenCore 0.7.4 since it was released without this issue.

What could be causing this problem? I have attached my 0.7.4 config.plist. Many thanks.
Have you recently updated Lilu to 1.5.7? This version was causing issues for some setups.

Another thing I just noticed in this 0.7.5 update that has changed is several things related to DeviceProperties. Several things were removed, and a couple of them were changed from data fields to integer fields...
The agpdmod property was removed because of the change to the MacPro7,1 board ID, and the shikigva property was removed in order to avoid accumulating settings as the focus of the guide shifts to the latest version of macOS (for DRM in Catalina, you'll want to keep shikigva). As for the integer fields, they result in data values of the form <00 00 00 00>, which are more typical for GPU properties than the previous data values of the form <00>.
 
Here's a little quirk which appears on my MacPro5,1 occasionally. Sometimes, usually when booting from cold (or so I imagine) I get the following error from Lilu:

Code:
Lilu      dev: @ failed to obtain model information, retrying...

A little digging turned up very few reports of others seeing this, so I took a peek at the code and as expected, it's trying to pull the model and board identifiers from the EFI. Have other people seen this? Should I be worried?

IMG_1903.jpeg


My solution is to turn it off and back on again, usually everything is fine on the next attempt. This is happening with OC REL-075-2021-11-02, Lilu v1.5.7, though it also happened on earlier versions.
 
  • Like
Reactions: bax2003
Have you recently updated Lilu to 1.5.7? This version was causing issues for some setups.

This process involved updating everything according to the OC 0.7.5 guide, including Lilu. Monterey seems to be running, but some weird stuff happened during the process I want to report since you asked me to let you know.

Here is what happened the second attempt where I attempted using VMM instead of FirmwareFeatures, SecureBootModel, UpdateNVRAM during install.

I cloned Catalina Volume, booted to it in OC VMM with the new 0.7.5. settings (attached here) and then ran software update.

The updater run through its various steps, rebooting several times. Strangely, I had named the boot volume as "Monterey" but it chose to rename it to "Mojave" at some point. Unless I accidentally typed "Mojave" when I named the cloned Catalina volume, I can't be sure now, just mentioning it in case it matters.

On the final reboot, where the "Install MacOS" volume no longer showed up BootPicker...it froze the progress bar halfway through.. I let it sit over night and it did not complete or move. I repowered the computer and this time it booted up into Monterey...however, an updater snapshot of some kind was left hanging around:

Screen Shot 2021-11-15 at 9.12.46 AM.jpg


I'm guessing that was leftover from when the boot progress bar froze halfway through, but I really have no idea.

(for DRM in Catalina, you'll want to keep shikigva). As for the integer fields, they result in data values of the form <00 00 00 00>, which are more typical for GPU properties than the previous data values of the form <00>.

Ok, next question is, then if I leave those in there for Catalina, will Monterey run ok? Seems like the guide should mention it is needed for Catalina.

I myself will be mainly running Catalina until more of my software works on Monterey. A couple key things still don't even run on BigSur much less Monterey.
 

Attachments

  • config.plist.zip
    3.9 KB · Views: 101
and the shikigva property was removed in order to avoid accumulating settings as the focus of the guide shifts to the latest version of macOS (for DRM in Catalina, you'll want to keep shikigva).

If that is the case, the sadly I may not be able to follow the guide anymore with monthly updates until more of my software is ready for Monterey and it appears that there is becoming increasingly differences in what is required to run Catalina on OC compared to BigSur and Monterey.

I can always stick with the last known working setup of OC 0.7.4 and just leave it alone indefinitely until I'm completely done with Catalina, but I have no idea how long that may be, and would certainly prefer to keep testing out the newer versions of MacOS and OC; even dual booting would be the biggest preference of all for me...but it sounds like the guide is going to lead me astray from here on out in terms of keeping Catalina going strong...
 
This process involved updating everything according to the OC 0.7.5 guide, including Lilu.
The issue with Lilu should not pose a problem in most cases, but it can explain the kernel panics that some are experiencing.

I repowered the computer and this time it booted up into Monterey...however, an updater snapshot of some kind was left hanging around:
The presence of such snapshots are normal (even for supported Macs).

Ok, next question is, then if I leave those in there for Catalina, will Monterey run ok? Seems like the guide should mention it is needed for Catalina.
Yes, Monterey will run fine.

If that is the case, the sadly I may not be able to follow the guide anymore with monthly updates until more of my software is ready for Monterey and it appears that there is becoming increasingly differences in what is required to run Catalina on OC compared to BigSur and Monterey.
but it sounds like the guide is going to lead me astray from here on out in terms of keeping Catalina going strong...
Although the focus of the guide has to be on the most recent version of macOS, that doesn't mean that the guide doesn't apply to Catalina. In fact, the guide depends on being able to boot Mojave! Currently, the only thing missing for Catalina is the shikigva device property for DRM. I'll probably include a note for it.
 
Thanks again for clarifications..

My suggestion would be to have a separate section for each version of MacOS...going back perhaps to Mojave, which is the highest official version that can run on 5,1 without OC. For each section make relevant notes that apply, such as the DRM thing needed for Catalina and/or anything else in the future if you remove some things to avoid config.plist clutter for those running only the latest MacOS.

For Catalina I think the current 0.7.5 relevant points are:
  1. Keep Shikigva for DRM
  2. Keep FirmwareFeatures, SecureBootModel and UpdateNVRAM set as previously ('', Disabled, false), use VMM for updates and install (including on Monterey)

In my case, I boot Mojave without OC when I use it. Catalina was really the first motivating reason to even use OC at all. But I do understand some people might be using OC book picker to get to Mojave, so they may need to know about that too, but IMHO, if I wanted to use Mojave I'd just wipe my machine and avoid OC altogether.

So Catalina works great. BigSur and Monterey also work fine it seems as I have been trying to follow the changes and keep up with OC updates, but basically some important software I use, some of it rather mainstream in my industry (audio production), do not yet support Monterey. So really Catalina is as far as I can go for now, other then to test out the latest version of LogicPro or test out OC updates and continue to test Monterey to see if its ready for me to run all my stuff.

Care has to be taken also related to APFS volumes, as I think this volume that I have upgraded to Monterey from Catalina...and then later wiped it (using Catalina diskutil) to clone it again and re-attempt the upgrade, etc..it left some oddities such that I'm not 100% confident of the volume's integrity due to incompatibilities between the various versions of APFS between OS and diskutil, etc. I may need to use a PC to 100% wipe the drive absolutely clean and reformat it again and start over actually..not sure at the moment. That's a separate issue I guess.
 
  • Like
Reactions: prefuse07 and cdf
The presence of such snapshots are normal (even for supported Macs).

In this case it has left around this "snapshot" and it shows up on my desktop as a volume now. I don't think this is normal. Its not a Time Machine snapshot...its obviously an AFPS snapshot that was created while attempting to update Monterey...but wasn't able to complete and get rid of the snapshot. I have no idea if the actual update itself completed..whatever it was suppose to do.

This is what it looks like as a mountable volume now:

Screen Shot 2021-11-15 at 12.33.07 PM.jpg


My guess is that this was created and end up partway finished when the boot I described early froze halfway through the progress bar...
 
So I've got a 2012 5,1 cMP. 12 cores @ 2.66
Running an RX580 GPU

I'm not a coder by any stretch of the imagination, but I understand the basic concepts and am willing to spend time researching whatever I don't know or understand. (Also good at following directions.) After a solid weekend of trial and error, I've now got a copy of Big Sur 11.6.1 running on my machine.

Wanted to pay it forward to the next person like me with a few lessons learned + recommendations.

I tried three different approaches (and combinations thereof) for doing this – 1) using OCLP, 2) following the instructions in the first post of this thread and 3) using Martin Lo's configuration.

OCLP feels like it wants to be easier than it is in reality. Not all that helpful if you don't know what you're doing with all the various patcher settings. The fact that the process requires boot screen access is prohibitive for owners of a GPU like mine that lack one. I tried a modified version of the OCLP process and it was pretty buggy after getting it all up and running.

The instructions offered in the first post of this thread are amazingly helpful (especially the "basic setup" section) and offer a great, foundational education for the basic concepts and Terminal commands you'll need to make it all work. Spending time going through the full process taught me a lot. That said – configuring your config file isn't as easy at it seems. At least for someone with my relatively limited ability. Don't think I managed to configure the config file correctly. I'm assuming I had the formatting wrong somehow, but I just gave up.

Lastly – thought I'd give Martin Lo's approach a shot. Having learned the overall process from this thread, it was an amazingly quick and easy process to get the right files in the right place, mount the EFI partition, bless the right partition, restart into recovery mode, etc. If you know the basic commands and you've got Martin's file, you really don't need much else.

And hats off to Martin. After trying to figure out trim settings and whether I needed SurPlus or not – I thought I'd give his "all in one" config file a shot. I don't know how he did it, exactly, but the thing. JUST. WORKS. So far so good.
 

Attachments

  • Screen Shot 2021-11-15 at 8.47.32 PM.png
    Screen Shot 2021-11-15 at 8.47.32 PM.png
    1.6 MB · Views: 748
One question for the experts...

So I disabled SIP to install Martin's config file.

I know what it does, but how important is it to turn it back on vs. leave it off? (How vulnerable is my machine if I leave it off?)

And if I turn it back on, does that prohibit any and all updates (security patches), or just version updates (e.g. Big Sur to Monterey)?
 
  • Like
Reactions: NC12
One question for the experts...

So I disabled SIP to install Martin's config file.

I know what it does, but how important is it to turn it back on vs. leave it off? (How vulnerable is my machine if I leave it off?)

And if I turn it back on, does that prohibit any and all updates (security patches), or just version updates (e.g. Big Sur to Monterey)?
How did you disable SIP? I have read docs, but unable to do it. Thanks.
 
configuring your config file isn't as easy at it seems. At least for someone with my relatively limited ability. Don't think I managed to configure the config file correctly. I'm assuming I had the formatting wrong somehow, but I just gave up.
As far as I know, nobody said it was "easy". But the guide is detailed enough so that anyone who pays due attention to the relevant instructions will succeed in making it work for their particular case. Ever since I found this thread, I modified the entire procedure for my own use, and have kept doing so, with some minor hiccups (all of them my fault), and the result is a resounding success. I generally like to know what I'm doing, why I'm doing it and why it works the way it does, and what I should do to make it behave differently or closer to my needs. That's why, good as it may otherwise be, Martin's package is not for me. It is obvious I'll never achieve the degree of expertise of Martin, cdf and many others, but I don't usually let others do the thinking for me.
 
How did you disable SIP? I have read docs, but unable to do it. Thanks.

You can set conflig.plist AllowToggleSip to true. This gives an auxiliary boot entry (space to show if not shown by default) which will toggle SIP and show you whether it is currently enabled or disabled in the name of the boot entry. (If you use this method to disable it, you should use this method to enable it again too.)
 
You can set conflig.plist AllowToggleSip to true. This gives an auxiliary boot entry (space to show if not shown by default) which will toggle SIP and show you whether it is currently enabled or disabled in the name of the boot entry. (If you use this method to disable it, you should use this method to enable it again too.)
Thank you so much.
 
Hoping someone can help me here.

I'm following the guide for installing OpenCore on a 2009 MP 4,1 updated to 5,1 and running Mojave

Even though I've followed through the steps twice, when I boot the OpenCore EFI, the machine boots ok, but on checking that OpenCore is loaded I get :

nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:eek:pencore-version': (iokit/common) data was not found.

After scratching my head, I just noticed in the introduction that there seems to be a cpu requirement :

Processor architectureWestmere (E56xx, L56xx, and X56xx) or Gulftown (W36xx)

The MP 4,1 that I am running has a Nehalem 2.66 GHz Q. Core Xeon W3520

Can anyone confirm if this is likely to be the the issue ?

I can get to the OpenCore Boot menu at startup, and the machine will boot with a non metal graphic card ok, so am I wrong to think that it is actually loaded?
 
Lot's of releases today:
  • Monterey 12.1 Beta 3 (21C5039b)
  • Big Sur 11.6.2 RC 2 (20G306)
  • Xcode 13.2 beta 2 (13C5081f)
Btw, I literally just installed 20G303…
 
Hoping someone can help me here.

I'm following the guide for installing OpenCore on a 2009 MP 4,1 updated to 5,1 and running Mojave

Even though I've followed through the steps twice, when I boot the OpenCore EFI, the machine boots ok, but on checking that OpenCore is loaded I get :

nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:eek:pencore-version': (iokit/common) data was not found.

After scratching my head, I just noticed in the introduction that there seems to be a cpu requirement :

Processor architectureWestmere (E56xx, L56xx, and X56xx) or Gulftown (W36xx)

The MP 4,1 that I am running has a Nehalem 2.66 GHz Q. Core Xeon W3520

Can anyone confirm if this is likely to be the the issue ?

I can get to the OpenCore Boot menu at startup, and the machine will boot with a non metal graphic card ok, so am I wrong to think that it is actually loaded?
I had Nehalem up and running with Catalina. Since then I have changed to new Processor. See here: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/post-29396512
 
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:eek:pencore-version': (iokit/common) data was not found.
I can get to the OpenCore Boot menu at startup, and the machine will boot with a non metal graphic card ok, so am I wrong to think that it is actually loaded?
If the OpenCore boot menu appears, then you are indeed booting through OpenCore. The fact that the NVRAM variable is missing indicates an unhealthy firmware chip.

 
One question for the experts...

So I disabled SIP to install Martin's config file.

I know what it does, but how important is it to turn it back on vs. leave it off? (How vulnerable is my machine if I leave it off?)

And if I turn it back on, does that prohibit any and all updates (security patches), or just version updates (e.g. Big Sur to Monterey)?

Bump.
 
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:eek:pencore-version': (iokit/common) data was not found.

Check the ExposeSensitiveData setting in the config.plist. It needs to be set to 2 I believe.
According the OC Manual:

9. ExposeSensitiveData
Type: plist integer
Failsafe: 0x6
Description: Sensitive data exposure bitmask (sum) to operating system.
• 0x01 — Expose the printable booter path as an UEFI variable.
0x02 — Expose the OpenCore version as an UEFI variable.
• 0x04 — Expose the OpenCore version in the OpenCore picker menu title.
• 0x08 — Expose OEM information as a set of UEFI variables.

If that bit 0x02 is not set then the NVRAM command should have returned UNK-000-0000-00-00 not 'data not found'. Try clearing your NVRAM.

I normally set mine to 15 and can see:

Bash:
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-075-2021-11-02
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path    PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,B23BFB37-1721-48BA-823F-76152B5DC630,0x28,0x64000)/EFI\OC\OpenCore.efi%00
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-product
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-product    MacPro5,1
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-vendor
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-vendor    Apple Inc.
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-board
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-board    Mac-F221BEC8
macnb@MacPro-01 ~ %

And, the OC Boot Picker screen displays the OC Version too:

06202559.png
 
  • Like
Reactions: prefuse07
Check the ExposeSensitiveData setting in the config.plist. It needs to be set to 2 I believe.
According the OC Manual:

9. ExposeSensitiveData
Type: plist integer
Failsafe: 0x6
Description: Sensitive data exposure bitmask (sum) to operating system.
• 0x01 — Expose the printable booter path as an UEFI variable.
0x02 — Expose the OpenCore version as an UEFI variable.
• 0x04 — Expose the OpenCore version in the OpenCore picker menu title.
• 0x08 — Expose OEM information as a set of UEFI variables.

If that bit 0x02 is not set then the NVRAM command should have returned UNK-000-0000-00-00 not 'data not found'. Try clearing your NVRAM.

I normally set mine to 15 and can see:

Bash:
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version    REL-075-2021-11-02
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path    PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,B23BFB37-1721-48BA-823F-76152B5DC630,0x28,0x64000)/EFI\OC\OpenCore.efi%00
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-product
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-product    MacPro5,1
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-vendor
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-vendor    Apple Inc.
macnb@MacPro-01 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-board
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:oem-board    Mac-F221BEC8
macnb@MacPro-01 ~ %

And, the OC Boot Picker screen displays the OC Version too:

View attachment 1911926

Now that's super cool!
 
Hi.
My MacPro (2010) is running with Mojave just fine. Now I'm willing to upgrade to Monterey.

So I followed the guide until maintance. And unfortunatley my Mac refuses to start from my Mojave Main on APFS when OC is enabled. At approx 2/3 of booting it displays the ø sign.

My Mac is able to start from a second Mojave Clone of Main on HFS+ just fine with OC enabled.

Checked the settings for SecureBootModel=disabled, -no_compat_check=disabled, MinDate=-1 and MinVersion=-1 only the last two I'd to set.

Environment
Hardware Overview:

Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: 6-Core Intel Xeon
Processor Speed: 3,33 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 12 MB
Hyper-Threading Technology: Enabled
Memory: 16 GB
Boot ROM Version: 144.0.0.0.0
SMC Version (system): 1.39f11
SMC Version (processor tray): 1.39f11

Software
MacOs Mojave 10.14.6 (18G9323)
OpenCore 0.7.5

Disklayout
ESP
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Testfeld 255.7 GB disk0s2

Mojave Main
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_APFS Container disk3 4.0 TB disk1s2


/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +4.0 TB disk3
Physical Store disk1s2
1: APFS Volume Jupiter 2.1 TB disk3s1
2: APFS Volume PreBoot 21.2 MB disk3s2
3: APFS Volume Recovery 507.6 MB disk3s3
4: APFS Volume VM 20.5 KB disk3s4

Mojave Clone
/dev/disk4 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk4
1: EFI EFI 209.7 MB disk4s1
2: Apple_HFS Io 4.0 TB disk4s2


Any idea of this behaviour? Are logs available? plist.conf is attached.

Any help is appreciated.
 

Attachments

  • config.plist.zip
    3.5 KB · Views: 144
I have a 4,1→5,1, which I was using with Catalina and older OC version for quite some time without any issues. Recently I've upgraded OpenCore to 0.7.4 with h9826790's package, just like I did before, and then to Big Sur 11.6.1. Now I experience a very strange and reproducable issue with Finder.

After I run HandBrake video conversion for some time, while it is still running, clicking on the desktop makes Finder seemingly crash without any signs. After that I cannot launch it again, and cannot launch any other application until I restart.

I know it's a long shot, but maybe someone can suggest anything here? I've tried deleting Finder settings plist and clearing NVRAM three times. Apart from that I'm at a loss.

After I hit OK the finder disappeared leaving just the desktop background. CMD+OPT+ESC window still worked but was empty, no finder there.

I've tried to search this thread, and this is the only post I found with a similar problem, the symptom is exactly what I have, but in my case I can reproduce it reliably.
 
So I followed the guide until maintance. And unfortunatley my Mac refuses to start from my Mojave Main on APFS when OC is enabled. At approx 2/3 of booting it displays the ø sign.

My Mac is able to start from a second Mojave Clone of Main on HFS+ just fine with OC enabled.
I suspect your install of Mojave (APFS) is borked because I was able to successfully boot my install with your config. A fresh install might be a good idea at this point.
 
I just got an old iMac from 2011 - hooked it up with a driver board so I can use it as a display for my cMP. According to a quick google search the display should theoretically support night shift but I can't enable it. Any suggestions?
 
I just got an old iMac from 2011 - hooked it up with a driver board so I can use it as a display for my cMP. According to a quick google search the display should theoretically support night shift but I can't enable it. Any suggestions?
Night Shift is blocked on the MacPro5,1 (even when using hybridization), so you'll need NightShiftEnabler or FeatureUnlock.
 
  • Like
Reactions: macnu
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.