Your config looks good. I think the problem is that OCAT is using an older version of ocvalidate. Note that if you ever want to update macOS ≥12.3, you'll need to add the ASPP-Override kext.
Got a tip for us?
Let us know
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
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I will stop using OCAT and just use ocvalidate to verify, going forward, thanks again!
Trying to update to 11.6.5 isn't going so well, however... I've got SecureBootModel set to Default, Hybridization, and even tried enabling the VMM Flag, can't get past the Apple logo during boot after selecting MacOS Installer...
Do we need the ASPP-Override kext to update to 11.6.5, or just for Monterey?
Edit: After experiencing some weirdness (crossout @ boot, followed by: "apple.com/startup") Per this explanation , I think i'm just gonna hold off on 11.6.5 for now...
Last edited:
Well in the spirit of "take 2 aspirin and call me in the morning"...
You might try doing a deep NVRAM reset (5 chimes) and also reblessing your efi/OC install.....
yup, I did exactly that, and 0.8.0 is working perfectly, but i'm still holding off on 11.6.5 until I do more research -- that (/) + boot loop/kernel panic was scary as hell! (bricking is my biggest fear, even though I have a MATT card and rebuilt ROM that I regularly reflash).
Last edited:
It really should just work. Remember if you use the VMM flag, you'll need to set SecureBootModel to Disabled.
Just Monterey. The issue was introduced with kernel version 21.4.0.
Would this refer to one particular setup (for instance, just for Big Sur, or Catalina), or is it applicable in all circumstances (for instance, for the latest versions of Monterey)? Would failure to set SecureBootModel to Disabled cause the boot process to always fail if the VMM flag is set?
Yes, this recommendation applies in general. I believe it's something that we tested in Big Sur and early versions of Monterey, probably around the time when the SecureBootModel=Default mechanism changed. As a sanity check, I just confirmed that using the VMM flag with SecureBootModel=Default causes a boot loop in macOS 12.3.1. Note that if you ever encounter this boot loop, you can still boot into macOS Recovery to fix your config through Terminal. Another option is to use an OpenCore rescue CD (see Maintenance > Creating a rescue CD in post #1).
Again: The VMM flag requires SecureBootModel=Disabled (see macOS in post #1).
So is this info out of date/irrelevant now, or am I just confusing myself?
The below process still applies, in order to update, yes?
Code:
➋ Clean install with bootable installer, or installer app in Big Sur and later, or OTA update in Big Sur and later
SecureBootModel is set to Default
Hybridization is used
Firmware features are updatedAnd then if you want to do Big Sur>Monterey, use the ASPP-Override kext, yeah? nothing else extra is needed? (just some courage)
Last edited:
Post #1 is up to date. It describes two options:
- VMM flag and SecureBootModel=Disabled
- Hybridization (with updated firmware features) and SecureBootModel=Default
Option 1 is now recommended if you are uncertain about the health of your firmware chip. In your case, since you have a Matt card, you can instead safely use option 2, which constitutes the settings that you should use when running macOS under normal circumstances.
Correct. You could even add it now with MinKernel set to 21.4.0. It'll be ready when you update.
Only if you're experimenting with untested approaches!
Last edited:
I have used option 2. Hybridization to update to 11.6.5. with OC 0.7.5. No problems at all.
Hello everyone,
Apologies in advance if this is an inappropriate place to post - will remove if so.
Late last year/early this year I installed OpenCore onto my machine via Martin's bundle/instructions and upgraded to Catalina and everything has worked flawlessly until this morning. I went to send a quick email before work and was met with a grey screen (no text, completely frozen, no cursor available). I did a hard shut down by holding the power button, waited a minute, and then re-powered back on, however nothing happened after this. No chime or OpenCore boot screen - nothing. I left it running for about 45 minutes before shutting down and trying again, but was met with the same results.
When I started it back up, I took the side panel off and noticed when I turn press the power button, the RAM LED lights up and then shuts off after a few seconds, as does the LED on the OWC Accelsior S that I have my system drive plugged into (the latter of which, I believe, usually stays illuminated while the Mac Pro is powered on). The fans inside (both the Mac's fans and GPU's fans) turn on at their normal speed and stay running. If it matters, I've had no power outages and this machine is plugged into a surge protector.
I'm currently at work, so I won't be able to take a look until later this evening, but wanted to post this in the meantime to see if anyone had any preliminary ideas or similar experiences. Apologies if I've not given enough info or said something ignorant - certainly not an expert in this field.
Appreciate any help anyone has and I'm happy to give additional information about the machine if needed.
Thanks for your time.
Specs of my machine here:
2009 Mac Pro 4,1 (Flashed to 5,1)
MacOS: Catalina (10.15.?)
CPU: Dual Intel Xeon x5680 - Delidded
GPU: Sapphire Radeon Pulse RX 580 8GB
RAM: Samsung 96GB (6 x 16GB) DDR3 1333 MHz ECC
System Drive: Samsung 1TB 860 EVO SATA III (Formatted APFS, TRIM enabled) connected via the OWC Accelsior S in PCIe slot 4
Apologies in advance if this is an inappropriate place to post - will remove if so.
Late last year/early this year I installed OpenCore onto my machine via Martin's bundle/instructions and upgraded to Catalina and everything has worked flawlessly until this morning. I went to send a quick email before work and was met with a grey screen (no text, completely frozen, no cursor available). I did a hard shut down by holding the power button, waited a minute, and then re-powered back on, however nothing happened after this. No chime or OpenCore boot screen - nothing. I left it running for about 45 minutes before shutting down and trying again, but was met with the same results.
When I started it back up, I took the side panel off and noticed when I turn press the power button, the RAM LED lights up and then shuts off after a few seconds, as does the LED on the OWC Accelsior S that I have my system drive plugged into (the latter of which, I believe, usually stays illuminated while the Mac Pro is powered on). The fans inside (both the Mac's fans and GPU's fans) turn on at their normal speed and stay running. If it matters, I've had no power outages and this machine is plugged into a surge protector.
I'm currently at work, so I won't be able to take a look until later this evening, but wanted to post this in the meantime to see if anyone had any preliminary ideas or similar experiences. Apologies if I've not given enough info or said something ignorant - certainly not an expert in this field.
Appreciate any help anyone has and I'm happy to give additional information about the machine if needed.
Thanks for your time.
Specs of my machine here:
2009 Mac Pro 4,1 (Flashed to 5,1)
MacOS: Catalina (10.15.?)
CPU: Dual Intel Xeon x5680 - Delidded
GPU: Sapphire Radeon Pulse RX 580 8GB
RAM: Samsung 96GB (6 x 16GB) DDR3 1333 MHz ECC
System Drive: Samsung 1TB 860 EVO SATA III (Formatted APFS, TRIM enabled) connected via the OWC Accelsior S in PCIe slot 4
Seems you have a brick, take a photo of the diagnostic LEDs while pressing the DIAG button.
P.S.: this is not the correct thread for this type of problem. Seems that you can't even complete POST, so the most probable is that you have a brick or dead SPI flash memory. Maybe it's better to move to a more appropriated thread.
I'd like to point out you should test your computer with an other OS that's natively supported instead of jumping to assumptions that your computer is somehow "bricked".
your SSD could have very well died and the chime is also controlled by Mac OS itself so it can be easily muted by you muting your sound when you last used it or by an error so that's no indication of anything.
I say you prepare an USB stick of your favorite linux distro and try to boot to it (having unplugged all your SSDs and HDDS) after you reset you power management by unplugging the computer for a few minutes. if it boots you have a perfectly good computer, but your installation of Mac OS is borked. you can go on from there.
Mac Pro POST chime is not related to the macOS volume at all, but to the SystemAudioVolume NVRAM entry. Newer (>2015?) Macs also have BootAudio.
Anyone else getting random prohibitory symbols after updating to 11.6.5? or perhaps on Monterey?
Was in Windows for a while, then tried to come back to MacOS, the apple logo was super slow in loading up, then ^ hit, and the computer was just stuck, so I had to do a manual reboot.
I booted into recovery and ran repair on my Mac SSD, and then rebooted and OC was finally able to load MacOS, but I read a post from @tsialex that this is common with 11.6.5 and 12.3.1?
I just reflashed my BootROM as part of my usual routine a few weeks ago, but now I'm wondering if I should do another deep NVRAM Reset and then reflash it again, now that I am updated to 11.6.5? Also thinking about setting SecureBootModel = Disabled, but I really don't think that's necessary..... and maybe not the root cause for this?...
Was in Windows for a while, then tried to come back to MacOS, the apple logo was super slow in loading up, then ^ hit, and the computer was just stuck, so I had to do a manual reboot.
I booted into recovery and ran repair on my Mac SSD, and then rebooted and OC was finally able to load MacOS, but I read a post from @tsialex that this is common with 11.6.5 and 12.3.1?
I just reflashed my BootROM as part of my usual routine a few weeks ago, but now I'm wondering if I should do another deep NVRAM Reset and then reflash it again, now that I am updated to 11.6.5? Also thinking about setting SecureBootModel = Disabled, but I really don't think that's necessary..... and maybe not the root cause for this?...
Last edited:
In my previous tests, this happens only while you still have all the payload from the updates inside the VSS store, if you deep reset the NVRAM, or reboot with
sudo nvram ResetNVRam=1, the payload is removed.If you removed the staging and still have problems, my bet is on a config.plist error.
No need to re-flash if you successfully deep reseted the NVRAM, or did a reboot with
sudo nvram ResetNVRam=1, and now have the expected VSS available space. If you don't want the trouble to check, you can always re-flash the never booted BootROM image and move on.
If I run the following:
Code:
sudo nvram ResetNVRam=1 && sudo rebootDo you think my boot order will get messed up, and potentially inject Windows security certs into the EFI? I have my Windows drive sitting in SATA bay 1, my MacOS SSD currently sits in an OWC PCIE adapter @ the top PCIE slot. Am I freaking out about nothing?
Last edited:
sudo nvram ResetNVRam=1 only removes the variables/entries marked for deletion, so "should" be safe and preferred to a deep NVRAM reset when you already flashed a never booted BootROM image previously.Even more so with a UEFI Windows install like yours in ambush, just waiting for the right moment to kill the NVRAM volume.
The thing is, this NVRAM variable that triggers the garbage collection was just discovered by @Syncretic and we still don't know of any unwanted/adverse effects/failures that happen when you use it. The theory is very sound, let's see if any problems appear with a broad usage by MacPro5,1 users.
Making things abundantly clear here, deep NVRAM reset is preferred when you have a long running NVRAM volume since over the years there are lot's of valid orphans variables or even incorrectly formatted variables that still have the valid byte enabled, Windows UEFI SecureBoot data or even the NVIDIA web drivers blobs. Not your case.
Always use the correct tool for the job.
Edit: as @Syncretic corrected me below (thanks!), both
sudo nvram ResetNVRam=1 and forcing a deep NVRAM reset will erase all variables, so in your scenario you can also inadvertently boot your UEFI Windows install and Windows SecureBoot will sign the BootROM when using sudo nvram ResetNVRam=1.
Last edited:
That's not quite correct. Here's the brief (for some definitions of "brief") version of how the Mac Pro 4,1/5,1 NVRAM works, based on the EFI code itself:
- When a new variable is added, it's added to the end of the list of variables.
- When a variable is deleted, it's just marked as deleted, and its space becomes "dead" until it's reclaimed by garbage collection.
- When a variable is modified, the old version gets marked as deleted, and the new version gets appended to the list of variables (basically, it's a "delete, then add"). Both adding and modifying variables consumes free space.
- When the free space in the VSS is less than 2048 bytes at boot time, garbage collection is run. Garbage collection (GC) consists of:
- VSS2 gets erased, then marked as "GC in progress"
- All valid (non-deleted) variables are copied from VSS1 to VSS2 (after which VSS2 is effectively a copy of VSS1 with all the "dead space" converted into "free space")
- VSS2 gets marked as "GC not in progress"
- VSS1 gets erased, then marked as "GC in progress"
- VSS2 gets copied back to VSS1
- VSS1 gets marked as "GC not in progress"
- (Note that VSS2's only purpose appears to be as a "scratch area" for garbage collection. Assuming no problems, VSS2 should always appear to be either empty or contain only valid variables, no deleted variables. Outside of garbage collection, VSS2 is not used.)
- At boot time, if VSS1 is found to be marked as "GC in progress," it's assumed that the system failed/rebooted during GC, and VSS1 is considered invalid. If VSS2 looks valid, VSS2 is copied to VSS1 and the system continues to boot. If VSS2 does not look valid, both VSS1 and VSS2 are erased (no variables are preserved), and booting continues.
- Garbage collection ONLY runs at boot time, not after the OS (MacOS/Windows/Linux) has loaded. This is why some installers cause problems or fail - if the VSS is nearly full when the installer is run, and/or if the installer writes a large amount of variable data, the VSS will overflow and errors will occur.
- The 2048-byte GC threshold only applies at power-up initialization. During EFI DXE operation, SetVariable() looks for VSS overruns (past the end of the VSS), and triggers GC to prevent them. Thus, it's possible to end up with variables extending into those final 2048 bytes of the VSS. I consider this to be a serious shortcoming/oversight in the code. (SetVariable does the same check after MacOS loads, but instead of triggering GC, it just discards the new variable and returns an error.)
- When VSS1 looks invalid at boot time, both VSS1 and VSS2 get completely erased.
- Holding
Cmd-Opt-P-Rat boot time causes 4 bytes of zero to be written into VSS1's first variable header (effectively invalidating it), then immediately forces a reboot. During that next immediate boot, VSS1 should appear invalid, and both VSS1 and VSS2 should get completely erased (no variables preserved). From there, certain other modules will re-create their variables (e.g. SystemAudioVolume, etc.).- Above, I used the word "should" because the
Cmd-Opt-P-Rhandler does NO error checking, it just blindly writes the zeros and reboots. Because of this, it appears that sometimes the writing of the zeros silently fails (possibly due to NVRAM timing or contention issues), and the reboot doesn't actually erase VSS1 because it still looks valid. It is my belief that this lack of error checking is why holdingCmd-Opt-P-Rthrough multiple reboots is sometimes necessary to achieve VSS1 erasure - sometimes, it just doesn't work. There is no visible mechanism in the MP4,1/5,1 ROM that behaves any differently on the second, third, or tenth reboot while holding downCmd-Opt-P-R- it just keeps trying to write those 4 zeros and rebooting. When it finally succeeds, VSS1 and VSS2 are completely erased, no variables are preserved.
- Above, I used the word "should" because the
- If a variable named
ResetNVRamexists at boot time (its value doesn't matter), both VSS1 and VSS2 are completely erased (no variables are preserved). Error checking is performed, and there is no reboot, so this method is more reliable and effective thanCmd-Opt-P-R- it's immediate and unconditional. (Cmd-Opt-P-Ris obviously necessary when the system is not bootable, or you're otherwise unable to create theResetNVRamvariable.)
- Garbage collection reclaims "dead space" that's consumed by deleted variables. Garbage collection preserves existing variables. Garbage collection appears to ONLY be triggered by free space going below 2048 bytes - there is no apparent way to trigger it manually.
- Both
Cmd-Opt-P-RandResetNVRamcause both VSS1 and VSS2 to be completely erased; no variables are preserved.Cmd-Opt-P-Rseems less reliable (can require multiple reboots) because it performs no error checking; however, it can be used when the system is unbootable or you can't create theResetNVRamvariable.ResetNVRamdoes error checking, and does a complete VSS1/VSS2 erasure immediately (during boot, not the moment you set the variable).
(Sorry for the off-topic wall of text. I really just wanted to clarify when variables do/don't get preserved.)
Last edited:
Just wanted to point out a potential issue with OC 0.8.0 that I posted about this morning thinking it was possibly a Monterey 12.3 issue.
It seems that OC 0.8.0 breaks Apple Watch unlock for me in Monterey. I will test some more and post a bug if it seems to true but wonder if anyone else is seeing this.
It seems that OC 0.8.0 breaks Apple Watch unlock for me in Monterey. I will test some more and post a bug if it seems to true but wonder if anyone else is seeing this.
Hi, I'm new here, but today I update my pro 5.1 to latest Monterey using OpenCore. Working great, but one main problem that I've got is only one display works instead of two. The display which works is connected via HDMI and second via DP.
Specs: Pro5.1
Proc: Xeon x5860
Graph: GTX680
Does anyone had problem like that too?
Specs: Pro5.1
Proc: Xeon x5860
Graph: GTX680
Does anyone had problem like that too?
Monterey has no drivers for Kepler GPUs. One of the possibilities is using OpenCore Legacy Patcher with its posts install patches.
This will hack Kepler drivers into Monterey.
This will hack Kepler drivers into Monterey.
Ok, I'm just going to put my MacOS SSD in SATA Bay 1 to avoid that, thank you for following up. I would have needed to do that anyway, for the project I am carrying out this weekend (more to follow on that later).
Thanks again!