Your configuration is problematic: it is using automatic mode with the old failsafes. Please refer to the guide to learn how to build a working configuration.
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
Anyone know if there's an OS version limit OC can boot? Just updated to v0.6.7 and all is fine when booting into a patched version of Catalina running on my MP3,1. However, attempting to boot into vanilla El Capitan (10.11) which resides on an HFS+ partition, caused a kernel panic and hard reboot.
OC log attached.
Rephrased for simplicity: can OC boot an OS installed on an HFS partition? Pinging @cdf
Edit: is HfsPlus.efi still required by v0.6.7 for booting a Mac OS installed on an HFS+ volume?
OC log attached.
Rephrased for simplicity: can OC boot an OS installed on an HFS partition? Pinging @cdf
Edit: is HfsPlus.efi still required by v0.6.7 for booting a Mac OS installed on an HFS+ volume?
Last edited:
i guess this means the only way to manage apfs partition of Big Sur boot volume is by booting to install media through oc or a second Big Sur volume is needed to boot through oc for the purpose of managing apfs of the actual main Big Sur boot volume?
Not sure I follow.
If I need to mess with BS volumes, I either boot directly into BS via OC, or the BS recovery installer via OC. I don't use BS to manipulate data volumes predating it, or vice versa.
i guess this means the only way to manage apfs partition of Big Sur boot volume is by booting to install media through oc or a second Big Sur volume is needed to boot through oc for the purpose of managing apfs of the actual main Big Sur boot volkme
sometimes you can't manipulate the boot volume you're currently booted to. In that case you will need to boot with something else. And it sounds like that something else needs to be BigSur also. Reading Dayo's post earlier, it sounds like it still might be possible to boot into Big Sur recovery or BigSur installer without OC, but make sure SIP is disabled first.
Just to understand, for what purpose would you need to manipulate the BS boot volume?
(shrug), dunno right now. I'm just responding and wondering...it has been put forth that its not safe to use the Mojave disk utility to touch the Big Sur APFS volume. First of all, can anyone else confirm that is actually true?
From what I've read, the way APFS is managed in BS is significantly different than Mojave and Catalina. This is why whenever I boot into Mojave, a warning always appears about an incompatible disk being present. Personally, I wouldn't risk trying to manipulate BS data volumes with an older version of Disk Utility on a production machine, or at least without a clone handy in case the directory tree gets messed up.
If you really need to alter it, OC depending on how it's configured, readily shows BS' recovery volume in the boot picker. Just use that.
Last edited:
@Dayo - you can boot into BS without OC and with SIP enabled. I usually do that as I use OC on a USB stick for updates as I wait for it to settle out (though 0.6.7 is working really well and shows my processor correctly on my 5,1). I do usually use Catalina since I also use VMWare Fusion which won't work on BS with our 5,1's.
My method is to modify the PlatformSupport.plist in the Preboot and Recovery partitions on the BS volume (I do that on Catalina as well) so that my MacPro5,1 appears supported. With that I don't need _no_compat_check. I do have to occasionally redo the plist - at a minimum they get replaced with every OS update.
Regards,
sfalatko
The problem is not in -no_compat_check. If you boot through the Apple boot picker and you have compatibility corrected you are OK But rEFInd can not boot directly even with compatibility and SIP enabled. OC and RP can handle that case.
@cdf, regarding latest 0.6.7 instructions, I notice you have changed the instructions to set both the Cpuid1Data and the Cpuid1Mask to
previously we only had to set the Mask, not the data...do both fields need to be set as above for enabling VMM with Catalina?
Previously the default was both fields set to
Now you have the default, both fields set to
also you removed the terminal command for verifying if VMM is enabled, could you remind us what that was? Some of us are still using VMM and Catalina. EDIT: for anyone needing this this is it:
AAAAAAAAAAAAAACAAAAAAA== in order to enable VMM for Catalina (and the default has now been changed to disabled).previously we only had to set the Mask, not the data...do both fields need to be set as above for enabling VMM with Catalina?
Previously the default was both fields set to
AAAAAAAAAAAAAACAAAAAAA==. and the action to disable it was to set the mask to AAAAAAAAAAAAAAAAAAAAAA==.Now you have the default, both fields set to
AAAAAAAAAAAAAAAAAAAAAA==, but I guess you're saying we should set them both back to AAAAAAAAAAAAAACAAAAAAA== in order to enable it.also you removed the terminal command for verifying if VMM is enabled, could you remind us what that was? Some of us are still using VMM and Catalina. EDIT: for anyone needing this this is it:
sysctl machdep.cpu.features
Last edited:
Unfortunately, ocvalidate will complain if a Cpuid1Data bit is set to 1 and the corresponding Cpuid1Mask bit is set to 0, so to satisfy the specification, we now set both Cpuid1Data and Cpuid1Mask to
AAAAAAAAAAAAAACAAAAAAA== to turn on the VMM flag and set both to AAAAAAAAAAAAAAAAAAAAAA== to turn it off. I tried making a case for the previous setting on the Acidanthera bugtracker (because the setting works and is logically valid according to the reference manual), but my request was rejected 
EDIT: Other option is to leave Cpuid1Mask as
AAAAAAAAAAAAAACAAAAAAA== and set Cpuid1Data to AAAAAAAAAAAAAACAAAAAAA== to turn on the VMM flag and set it to AAAAAAAAAAAAAAAAAAAAAA== to turn off the VMM flag. This is the same as what we were doing before, but with Cpuid1Mask and Cpuid1Data interchanged...Sure. I should probably still include it in the guide:
sysctl machdep.cpu.features
Last edited:
Quick question: I've done a Catalina OpenCore setup with this guide a few months back with OC 0.6.4 I think. Is there an upgrade guide to BigSur or do I have to start over with the guide and a fresh install?
best
best
I would recommend that you start by upgrading to OpenCore version 0.6.7. It has nice improvements for OEM preservation, which is useful on Apple hardware. Part 3 of the guide explains how to update OC. Then, as long as your Mac is booted through OC, you can proceed to do a fresh install or update from Catalina (see Part 4 of the guide and make sure to back up first!). Note that with hybridization, the VMM flag is not needed for installing or updating Big Sur.
Plistlib Generator
@cdf, here are the differences between your configuration and mines, please add comments:
1.0.10 is out. No changes required to setup.py, see significant changes for OC 0.6.7 and the list of improvements since OC 0.6.6.@cdf, here are the differences between your configuration and mines, please add comments:
- Misc/Boot/PickerVariant set to default Auto, so icons match the choses custom background, you used Default
PlatformInfo/SMBIOS/PlatformFeature set to default 0, you used 4294967295 32bits intfixed, see #89
Last edited:
Auto is fine. However, PlatformFeature should be set to the failsafe 4294967295 (0xFFFFFFFF) to preserve the OEM value (which is a missing table in the case of the Mac Pro 5,1). A value of 0 will set the table to 0x00000000.
Yes, zero is wrong as it is has a specific connection as on cMP7,1.
Btw, you can use "-1" instead of "4294967295". It applies for any "0xF ... F" value.
Are you still able to with 0.6.7? El Capitan is not booting via OC on cMP3,1. You can boot it natively of course but strange that it doesn't work through OC.
Might be a config thing somewhere or something is broken. I presume no one specifically watches out for the older OS as changes go in.
I haven't tried with 0.6.7, and unfortunately, I don't have that disk anymore...
Have you tried with all spoofing disabled?
As El Cap needs HFS+, does 0.6.7 still require HfsPlus.efi to boot? If so, then perhaps that's my issue as ConfigFactory is not deploying that driver to EFI/OC/Drivers. Just a thought.
Same with El Capitan on an HFS+ volume. It shows me the forbidden sign for about 30 seconds before it kernel panics due to watchdog timer.
What about for systems that can still boot 10.11 natively? This is my issue on the MP3,1.