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
Sorry, I didn't see your reply - thank you.
But am still confused, I'm really sorry. I don't want to be rude - or look stupid! - but I've expanded ALL sections of p.1 and forward searched in the browser for the text
ocvalidate - before making my claim! And I've just run it again and also searched through §3 by eye, and I'm still not seeing it - what should I be looking at?
Right - I needed to expand *everything* - that's a bit annoying since it basically means no way to forward search through the whole text I think? (Not your fault, if so!) Maybe I'll pm you, if okay?
EDIT: Okay you can search the whole text, without needing to expanding anything first, by searching the HTML source - I actually assumed it was probably loading those bits on demand, but it's not - I'll remember that next time. Still have some queries about whether
EDIT: Okay you can search the whole text, without needing to expanding anything first, by searching the HTML source - I actually assumed it was probably loading those bits on demand, but it's not - I'll remember that next time. Still have some queries about whether
ocvalidate mightn't be able to better replace some uses of plutil now, which I will pm to you.
Last edited:
I seem to recall @tsialex saying previously that some USB sticks don’t support booting. Perhaps try a different USB stick.
I use OC on an external USB stick as I wait to see how it matures. I generally boot into Catalina and Big Sur without OC just no_compat_check and use OC to perform updates. In this context using an external USB stick is perfect.
Regards,
sfalatko
I am using all the time 87F which includes 0x800 and I can update BS. Which update is prevented?
87F= csrutil disable + csrutil authenticated-root disable
Issued from recovery.
@startergo - thanks -
github.com
Please do confirm as requested: if you are getting OTA updates and especially incremental OTA updates then something is up and (I think) needs addressing. Thanks for your input.
Correct values to use for disable SIP · Issue #1657 · acidanthera/bugtracker
I've got this comment from @startergo on Macrumors: Bmju said: CSR_ALLOW_UNAUTHENTICATED_ROOT (0x800) is not practical as it prevents incremental (non-full) OTA updates. I am using all the time...
github.com
Please do confirm as requested: if you are getting OTA updates and especially incremental OTA updates then something is up and (I think) needs addressing. Thanks for your input.
Last edited:
Hi all
Trying to understand the OC config.plist I compiled a fresh copy of OC, which contains a sample plist. In it in the patch section there is this code:
is this to be deleted or can it be left as is?
Thanks!
Trying to understand the OC config.plist I compiled a fresh copy of OC, which contains a sample plist. In it in the patch section there is this code:
XML:
<key>ACPI</key>
<dict>
..........................
<key>Patch</key>
<array>
<dict>
<key>Base</key>
<string></string>
<key>BaseSkip</key>
<integer>0</integer>
<key>Comment</key>
<string>Replace one byte sequence with another</string>
<key>Count</key>
<integer>0</integer>
<key>Enabled</key>
<false/>
<key>Find</key>
<data>ESIzRA==</data>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data></data>
<key>OemTableId</key>
<data></data>
<key>Replace</key>
<data>RDMiEQ==</data>
<key>ReplaceMask</key>
<data></data>
<key>Skip</key>
<integer>0</integer>
<key>TableLength</key>
<integer>0</integer>
<key>TableSignature</key>
<data></data>
</dict>
<dict>
<key>Base</key>
<string>\_SB.PCI0.LPCB.HPET</string>
<key>BaseSkip</key>
<integer>0</integer>
<key>Comment</key>
<string>HPET _CRS to XCRS</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<false/>
<key>Find</key>
<data>X0NSUw==</data>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data></data>
<key>OemTableId</key>
<data></data>
<key>Replace</key>
<data>WENSUw==</data>
<key>ReplaceMask</key>
<data></data>
<key>Skip</key>
<integer>0</integer>
<key>TableLength</key>
<integer>0</integer>
<key>TableSignature</key>
<data></data>
</dict>
</array>is this to be deleted or can it be left as is?
Thanks!
Last edited:
That sample is a general example.
If you want to make your own config, it's much easier to build it from the sample included here. This sample is a safe, minimal working solution for the Mac Pro 5,1.
If you use the sample @cdf has provided and then run
ocvalidate on it (which is included with the OC download in Utilities), then it will warn you of any settings added to OC very recently. If there are any, then it is usually safe to add them by using the settings (just for those particular missing values) from the sample plist that comes with OC.That should work fine, but also, this is still something you have to do by hand, so if you are just getting started, you would be much safer to use @cdf's current config with OC's current 0.6.9 release (not the 0.7.0 pre-release).
I am getting OTA and incremental updates with 87F which is the Apple default SIP+authenticated-root in latest BS. When BS came out originally it was 877, but then it changed to 87F.@startergo - thanks -Correct values to use for disable SIP · Issue #1657 · acidanthera/bugtracker
I've got this comment from @startergo on Macrumors: Bmju said: CSR_ALLOW_UNAUTHENTICATED_ROOT (0x800) is not practical as it prevents incremental (non-full) OTA updates. I am using all the time...
Please do confirm as requested: if you are getting OTA updates and especially incremental OTA updates then something is up and (I think) needs addressing. Thanks for your input.
tyvm - yes, 0x77 for csrutil disable was the Catalina default, and it changed to 0x7F early in Big Sur, I agree.
I also tend to agree with you that my experience was that there was no issue with getting updates with 0x77 or 0x7F (although I've been using SIP enabled almost all the time for ages, so can no longer be quite sure; as I already had my own tool to quickly toggle SIP, before winning the case to be allowed to add something similar to OC), but I'm being told that cannot be so...
thank you for your input
Exactly, that is why you need to run plutil first. BTW, I also use xattr to clean files with extended attributes.
Last edited:
As described into ocvalidate, you can only validate configs generated for same OC version. Since you are running 0.7.0, it will report errors on 0.6.9 config file. But you can easily look at the manual and add/update the old config keys/values, if you want.
Hi. I'm trying to mount my EFI partition, so I can turn on the VMM flag and get the last few supplemental updates to Catalina. When I enter "diskutil mount /dev/disk0s1" (my EFI partition), I get the message "Volume on disk0s1 failed to mount. Perhaps the operation is not appropriate (kDAReturnNotPermitted)". Has anyone seen this before and know how I might fix it? MacOS runs fine otherwise.
Edit: fixed it. The guide on post 1 had missed the sudo before the diskutil mount, in the section that talks about VMM.
I believe I'm currently on OC 0.5.9 (I installed it last summer). Would there be much benefit to updating to the last version? The main reason for upgrading would be Big Sur support, though I'll hold off on that to see if the 11.3 issue is sorted first.
If I upgrade OC, would it require new versions of all the supplementary files (whatevergreen etc.)? I assume so. The set up guide seems to have changed a quite a lot, so I'd need to go through it all and figure everything out, which will take a while.
Edit: fixed it. The guide on post 1 had missed the sudo before the diskutil mount, in the section that talks about VMM.
I believe I'm currently on OC 0.5.9 (I installed it last summer). Would there be much benefit to updating to the last version? The main reason for upgrading would be Big Sur support, though I'll hold off on that to see if the 11.3 issue is sorted first.
If I upgrade OC, would it require new versions of all the supplementary files (whatevergreen etc.)? I assume so. The set up guide seems to have changed a quite a lot, so I'd need to go through it all and figure everything out, which will take a while.
You're forgetting "sudo":
sudo diskutil mount /dev/disk0s1Version 0.6.8, for example, brought some nice changes. Have a look at the official release notes.
Not necessarily. But it's definitely a good idea to update everything. Don't forget OcBinaryData.
Thanks cdf. I can't pretend to understand most of what the changelog refers to, but much of the one for 0.6.8 seemed to involve improvements to OpenCanopy. Does OpenCore have any effect on macOS once booted? The boot picker already works fine for my purposes, but I'll upgrade OC anyway once I've got some free time in the summer.
I presume most of the improvements to OC are for platforms other than the MP 5,1?
I presume most of the improvements to OC are for platforms other than the MP 5,1?
TL/DR:
- SIP bit 0x10 (present in 0x7F, 0x77, 0x87F etc., but not in 0x6F, 0x26F etc.) blocks OTA updates, period. (I have just replicated this.)
- SIP bit 0x800 apparently blocks incremental OTA updates. (I would tend to trust this until proven otherwise.)
Once macOS is booted, OC is out of the way. However, the beneficial changes applied by OC remain.
Actually, many improvements were developed specifically for minimally spoofed Macs such as the Mac Pro 5,1.
Well, 0xF87 I would expect to offer an update anyway (possibly not an incremental update but that is not tested).
0x87F is a valid counterexample though, I agree. (And as mentioned in the issue, I have now found counterexamples too.)
Genuinely, thank you very much for your input - but I hope you're okay with the final decision (now publicly endorsed by Vit, ofc, too) that since these bits are known (incl. replicated by me yesterday) to cause problems on some systems, the warnings stay in, and the choice not to set them in our default value stays. (I gather that if you know enough about the internals of the update system, that you'd expect that they would cause problems - but I don't - at least so far.)
0x87F is a valid counterexample though, I agree. (And as mentioned in the issue, I have now found counterexamples too.)
Genuinely, thank you very much for your input - but I hope you're okay with the final decision (now publicly endorsed by Vit, ofc, too) that since these bits are known (incl. replicated by me yesterday) to cause problems on some systems, the warnings stay in, and the choice not to set them in our default value stays. (I gather that if you know enough about the internals of the update system, that you'd expect that they would cause problems - but I don't - at least so far.)
Last edited:
Hi all, I have a question that I've searched around but can't find the thread that I'm sure exists somewhere. Hopefully this will help someone else as well.
I have the latest Opencore on my PCIe SSD running Catalina in my 5,1 (disk A). On the second SSD drive of the PCIe card I have Mojave as my fallback drive (disk B).
I installed Big Sur 11.2.3 on a HDD in one of the Sata drives on the cMP to try it out (disk C). Big Sur was running well enough that I started installing apps and things, thinking my old-school OS X mentality that I could simply clone Disk C to Disk A and be done with it. Ah, but can I? The other thing is that where I live my internet is quite slow, so not downloading FCP, Photoshop, etc. again to install to to Disk A would be great (I wanted to make sure everything was working well in BS before committing to it).
Since Big Sur's file system is different than Catalina's, I'm assuming I'd need to wipe Disk A. So my thought was to do this:
1) Format Disk A/OC+Catalina while booted in Disk C/Big Sur
2) While booted in Big Sur/Disk C, can I use CCC 6 to clone itself/Disk C to Disk A? I'd be basically making a bootable backup of itself to the Disk A SSD.
3) Boot into Disk B/Mojave and re-install OC on Disk A and reboot to select Disk A as my startup disk.
I've found quite a few threads doing Big Sur > Big Sur backups but none that quite matched this situation.
Thank you -- any assistance is helpful.
I have the latest Opencore on my PCIe SSD running Catalina in my 5,1 (disk A). On the second SSD drive of the PCIe card I have Mojave as my fallback drive (disk B).
I installed Big Sur 11.2.3 on a HDD in one of the Sata drives on the cMP to try it out (disk C). Big Sur was running well enough that I started installing apps and things, thinking my old-school OS X mentality that I could simply clone Disk C to Disk A and be done with it. Ah, but can I? The other thing is that where I live my internet is quite slow, so not downloading FCP, Photoshop, etc. again to install to to Disk A would be great (I wanted to make sure everything was working well in BS before committing to it).
Since Big Sur's file system is different than Catalina's, I'm assuming I'd need to wipe Disk A. So my thought was to do this:
1) Format Disk A/OC+Catalina while booted in Disk C/Big Sur
2) While booted in Big Sur/Disk C, can I use CCC 6 to clone itself/Disk C to Disk A? I'd be basically making a bootable backup of itself to the Disk A SSD.
3) Boot into Disk B/Mojave and re-install OC on Disk A and reboot to select Disk A as my startup disk.
I've found quite a few threads doing Big Sur > Big Sur backups but none that quite matched this situation.
Thank you -- any assistance is helpful.
Last edited: