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.
Hi
I've installed Martin's config OC 0.7.0 on both cMP5,1(Mid2012) and Big 11.2.3 w/ Radeon RX580 and a cMP4,1(Early 2009) flashed to 5,1 w/ Radeon HD 7950. Both running gr8.

However, on each Mac I'd like to re-enable SIP. I checked csrutil status and csrutil authenticated-root status and both are disabled.

I booted into Recovery and csrutil enable and csrutil authenticated-root enable...when I boot back it returns

csrutil status
System Integrity Protection status: disabled.

csrutil authenticated-root status
Authenticated Root status: disabled

In Recovery I also tried csrutil clear; then did enable. On normal boot both are still disabled

any ideas, cheers Claudio

This has to do with how SIP is managed in the OpenCore configuration you are using. To be able to manage SIP yourself through recovery like on any supported Mac, you can remove
Code:
<key>csr-active-config</key>
<data>dwgAAA==</data>
and
Code:
<string>csr-active-config</string>
from the NVRAM section of your config. For more information, start reading at post #7,645. See #7,653 for my take on setting SIP in OC.
 
There is the new feature AllowToggleSip

Code:
AllowToggleSip
Type: plist boolean
Failsafe: false
Description: Enable entry for disabling and enabling System Integrity Protection in OpenCore picker.
This will toggle Apple NVRAM variable csr-active-config between 0 for SIP Enabled and a practical default value for SIP Disabled (currently 0x26F).
Note 1: It is strongly recommended not to make a habit of running macOS with SIP disabled. Use of this boot option may make it easier to quickly disable SIP protection when genuinely needed - it should be re-enabled again afterwards.
Note 2: OC uses 0x26F even though csrutil disable on Big Sur sets 0x7F. To explain the choice:
csrutil disable --no-internal actually sets 0x6F, and this is preferable because CSR_ALLOW_APPLE_INTERNAL (0x10) prevents updates (unless you are running an internal build of macOS).
CSR_ALLOW_UNAPPROVED_KEXTS (0x200) is generally useful, in the case where you do need to have SIP disabled, as it allows installing unsigned kexts without manual approval in System Preferences.
CSR_ALLOW_UNAUTHENTICATED_ROOT (0x800) is not practical as it prevents incremental (non-full) OTA updates.
Note3: For any other value which you may need to use, it is possible to configure CsrUtil.efi as a TextMode Tools entry to configure a different value, e.g. use toggle 0x6F in Arguments to toggle the SIP disabled value set by default by csrutil disable --no-internal in Big Sur
 
  • Like
Reactions: splifingate
Hi guys .. I need advices, I'm lost now. What's best ? Last Martin's OC ? OCLP ? OC+refind ?
 
Depends… if you run legacy Systems (csm Windows, Linux) or none-uefi ones imho refindPlus is the way.

oclp is a nice one if you have a bunch of patches to implement and you want a quick solution.

Martins package is nice for modern GPUs.

this basic package in this thread is fine if you want as little as possible modifications or you want to look deeply under the hood.

…. where RefindPlus can be combined with oclp or Martin’s package - or vice versa
 
Last edited:
OpenCore v0.7.2 just released:

v0.7.2
  • Fixed OSBundleLibraries/OSBundleLibaries64 handling
  • Added GraphicsInputMirroring to fix lost keystrokes in some non-Apple graphical UEFI apps
  • Added support for stack canaries (security cookies / stack guards)
  • Fixed unintialised memory access in AudioDxe causing audio playback failure
  • Changed Default Apple Secure Boot model to x86legacy for better security and compatibility
  • Increased default APFS MinDate and MinVersion to macOS Big Sur for better security
  • Updated builtin firmware versions for SMBIOS and the rest
  • Improved SSDT-PNLF compatibility with Windows and newer graphics
  • Fixed CLANGPDB OpenCore builds by shortening OC magic
 
Plistlib Generator 1.1.4 was released with support for OC 0.7.2 (see notable changes), you will need to perform several minor changes to your current setup.py file, prior executing the usual upgrade process.

@cdf, SidecarFixup was replaced with FeatureUnlock.
 
Last edited:
After searching for a solution I am unable to find a solution for my problem.
At Part 1 when trying to confirm OC is loaded I get the "nvram error getting variable"

Trying to proceed and do the Post install settings in the config.plist, when I want to verify and load the configuration I get the error "file does not exist.."

Any help would be appreciated.
 
Trying to proceed and do the Post install settings in the config.plist, when I want to verify and load the configuration I get the error "file does not exist.."
Make sure that you've copied config.plist to your home folder to carry out the edits.
 
Is asking for a download link to 11.2.3 allowed on this forum? I missed the boat on upgrading my Mac Pro 5 1 and I'd like to update it to the last version before the issues started with 11.3. I've searched around on the internet looking for a legit link but only found shady torrents.
 
Is asking for a download link to 11.2.3 allowed on this forum? I missed the boat on upgrading my Mac Pro 5 1 and I'd like to update it to the last version before the issues started with 11.3. I've searched around on the internet looking for a legit link but only found shady torrents.
 
Is asking for a download link to 11.2.3 allowed on this forum? I missed the boat on upgrading my Mac Pro 5 1 and I'd like to update it to the last version before the issues started with 11.3. I've searched around on the internet looking for a legit link but only found shady torrents.



When you are finished, just run the downloaded file, InstallAssistant.pkg , and you will have the installer in your Applications folder.
 
My 2 cent to OpenCore community. I found useful add this alias to ~/.zshrc (~/.profile using bash)
Bash:
alias efimount="sudo diskutil mount /dev/disk0s1"
alias efiumount="diskutil umount /dev/disk0s1"
alias ocedit="sudo diskutil mount /dev/disk0s1; bbedit /Volumes/EFI/EFI/OC/config.plist"
Note that disk0s1 must be replaced by your own OC EFI partition, and
bbedit can be replaced by your favourite editor.
I tried to use universal syntax for mounting the partition, but went in error with apostrophes and quotation marks.

EDIT: I replaced the command above as suggested by @Syncretic. Even other expert users suggested more complete solution, I think that this three simple commands could have sense anyway.
Bash:
alias getmacos='curl -O -L https://raw.githubusercontent.com/munki/macadmin-scripts/main/installinstallmacos.py && sudo python installinstallmacos.py'
alias efimount='u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed "s/.*GPT,\([^,]*\),.*/\1/"); if [ "$u" != "" ]; then sudo diskutil mount $u && open /Volumes/EFI/ ; fi'
alias efiumount='u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed "s/.*GPT,\([^,]*\),.*/\1/"); if [ "$u" != "" ]; then diskutil umount $u; fi'
alias ocedit='u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed "s/.*GPT,\([^,]*\),.*/\1/"); if [ "$u" != "" ]; then sudo diskutil mount $u && open /Volumes/EFI/ ; fi; bbedit /Volumes/EFI/EFI/OC/config.plist'
 
Last edited:
  • Like
Reactions: Dayo
disk0s1 must be replaced by your own OC EFI partition
In multi disk setups, it is impossible to be certain that any one particular disk will always be assigned a /dev/diskX id on every single boot. Basically, a /dev/diskX id should never be hard coded as it can vary between boots.

To avoid, you will need your aliases to call a script that determines the current disk id and then use this.
 
In multi disk setups, it is impossible to be certain that any one particular disk will always be assigned a /dev/diskX id on every single boot. Basically, a /dev/diskX id should never be hard coded as it can vary between boots.

To avoid, you will need your aliases to call a script that determines the current disk id and then use this.
One time I've nuked 2TB of past macOS installers going back to Jaguar with a diskutil zerodisk because I've forgot to check the current device after a reboot.

This still haunts me.
 
Well, as described in the guide, OpenCore exposes the EFI partition to which it's installed. You can mount the EFI
by entering u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.*GPT,\([^,]*\),.*/\1/'); if [ "$u" != "" ]; then sudo diskutil mount $u && open /Volumes/EFI/ ; fi in Terminal.
 
In multi disk setups, it is impossible to be certain that any one particular disk will always be assigned a /dev/diskX id on every single boot. Basically, a /dev/diskX id should never be hard coded as it can vary between boots.

To avoid, you will need your aliases to call a script that determines the current disk id and then use this.
In my case, since I play around with OC, nvme disk didn't move from disk0 identifier. Even booting from recovery.
One time I've nuked 2TB of past macOS installers going back to Jaguar with a diskutil zerodisk because I've forgot to check the current device after a reboot.

This still haunts me.
Mounting a partition will not be so dangerous, even if someone get an erroneous identifier.
Well, as described in the guide, OpenCore exposes the EFI partition to which it's installed. You can mount the EFI
by entering u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.*GPT,\([^,]*\),.*/\1/'); if [ "$u" != "" ]; then sudo diskutil mount $u && open /Volumes/EFI/ ; fi in Terminal.
To long to remember or to write... so this involves copy & paste. I find very much easier write "efimount" or "ocedit". I tried to put the command above in an alias, but went in error with apostrophes and quotation marks.
 
If you are looking for a clear, quick and easy way to mount, dismount and identify EFI volumes I suggest you head over to Github for Andrej Antipov's MountEFI utility program. MountEFI

MountEFI is a shell script program which operates in Terminal. MountEFI provides a Terminal GUI for searching and mounting EFI/ESP partitions for macOS versions Maverick to Big Sur.

After you download the MountEFI-master.zip file look in the MountEFi-master folder for MountEFI.zip file.
Unzip MountEFI.zip to get the MountEFI.app. When you click on the app it will start Terminal and present its GUI main menu.

As noted in several previous posts macOS reassigns disk numbers on restarts. A particularly nice feature of MountEFI is that the setup menu provides the ability to create or edit an alias for physical device/media. This feature is provided through letter A of the Setup Menu. Looking at the screenshot of my Main Menu example below look at SATA device #5. This is the native name of my Samsung SSD disk. Disks 1 to 4 have been re-named using the alias feature. These disk names can follow any scheme you want and are retained between cold and warm restarts which eliminates confusion as to which disk has which EFI and operating system. There are many other useful features for loading and configuring config.plist files that you can explore.

Screenshot of the Main Menu:
MountEFI by Andrej Antipov.png


Screenshot of I - Extra Menu

MountEFI extra menu .png

Screenshot of S - Setup Menu

MountEFI setup menu.png
 
I tried to put the command above in an alias, but went in error with apostrophes and quotation marks.

alias efimount='u=$(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed "s/.*GPT,\([^,]*\),.*/\1/"); if [ "$u" != "" ]; then sudo diskutil mount $u && open /Volumes/EFI/ ; fi'

Or just put it into a shell script somewhere in your path. I have a bunch of these saved as scripts, so they work no matter which shell I'm in at the time, e.g.
checkOCversion: nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
 
In my case, since I play around with OC, nvme disk didn't move from disk0 identifier.
That's like saying you have been driving around your entire adult life at speed without wearing seat belts and haven't yet died from an accident.

There is a reason it works for you so far (Single NVME drive) but the important point is that you are suggesting this approach to others that are likely to have different set ups and worse still, might infer it is OK to to hard code Disk IDs for use in other contexts.

Best use the suggestion by @Syncretic instead
 
Best use the suggestion by @Syncretic instead
I edited my alias and my previous message, in accordance with @Syncretic suggestion. Thanks to all.

But now I've another (for me) more important question. After I tried to convert my existing Windows SSD from MBR to GPT with windows mbr2gpt tool (tool said with success, but now windows won't boot) , I tried to install windows 10 (build 1903) from scratch to an empty drive in accordance of the steps in the appendix in page 1. All steps seems to be went well, but after a few minutes that the Windows installation starts, appears the blue screen with this message error: "CLOCK_WATCHDOG_TIMEOUT". That's the same error message that mostly appears trying to boot my previous windows installation (in the recovery attempts I had also see other messages).
Any idea? Maybe, if I find how to remove the error in the new installation, I might find the solution for booting my previous windows too.
I'll add that previous windows volume is readable while booting the computer from another source, can boot his internal recovery procedure that in some case asked me for my windows user password (but was unable to recover windows boot)... so it's not unreadable at all.
And even recover my previous windows installation could be a bit out of topic, make work a new installation is covered in page 1 of this thread.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.