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.
There have been reports of difficulties with OpenCore on NVMe drives, but also note that the EFI partition your NVMe drive cannot be blessed properly if your Mac is already booted through OC with RequestBootVarRouting enabled.
Just to clarify, I have no issues performing a simple bless --mount /Volumes/EFI --setBoot with RequestBootVarRouting: True from recovery, on my Samsung 970 EVO Plus.

1608787509445.png


1608787611116.png


1608787726629.png
 
It is not compatible with OC. Only UEFI mode is.
Got ya. Thanks!

I'll probably just do the single instance boot drive route from within OS X to select Windows then. I don't have the technical skills to deal with the backplane/NVRAM issue. I have an extra tray laying around but I don't want to *have* to use it.
 
There have been reports of difficulties with OpenCore on NVMe drives, but also note that the EFI partition your NVMe drive cannot be blessed properly if your Mac is already booted through OC with RequestBootVarRouting enabled.

Thanks a lot, I changed the value of that entry rebooted, bless the EFI on the NVME, rebooted and voilà, then returned to enable RequestBootVarRouting
 
  • Like
Reactions: cdf
Just to clarify, I have no issues performing a simple bless --mount /Volumes/EFI --setBoot with RequestBootVarRouting: True from recovery, on my Samsung 970 EVO Plus.
See here:

 
  • Like
Reactions: Eschers
Just to clarify, I have no issues performing a simple bless --mount /Volumes/EFI --setBoot with RequestBootVarRouting: True from recovery, on my Samsung 970 EVO Plus.

View attachment 1700236

View attachment 1700237

View attachment 1700238
If you bless some partition from system booted with OC it is similar to selecting a startup disk. To illustrate this behavior suppose you chain loaded OC through refind. Blessing Refind will just make Refind the default boot option in the OC boot menu. Same logic applies if you booted OC and then selected recovery partition. Blessing this way is like selecting the startup disk, but only for the partitions booted through OC. The actual blessing of OC has to be performed when you have booted outside of OC. My setup includes RefindPlus chainloading OC. Refind is set on an HFS+ drive as a boot.efi just like in a regular HFS+ boot partition like HS. Because both bootloaders are installed on the "upper" SATA drive after NVRAM reset it becomes the boot candidate. I have "boot protect" enabled and OC's BOOTx64 deleted. On the first boot I get RefindPlus boot picker and I can reset SIP options. On the second boot it jumps straight to OC and selects the first in order boot option by default. There is no default option selected by OC yet. If I now bless a partition either through CTRL+ENTER from the boot menu or startup disk selection/blessing after the system is booted it sets the default boot option for OC. Say you have in the OC boot menu an option for its own boot loader. If you bless OC in a booted from OC system you will set OC as the default boot loader from OC. Now this is not supported and it will kick you back to the OC boot menu. In my case if I want to boot any boot loader or OS outside of OC I have to reset the NVRAM. If you want permanent chain loading @Dayo MyBootmanager offers such an option.
 
A minor query, I'm sure, but I'm puzzled; I use Carbon Copy to back up my system drive and Win10 VM every night to two other drives for security. The OC bootpicker can see the BS system drive to boot from, but not the System Preferences Startup Drive app. That just shows the older Mojave drives and not the BS drives. Why is this? Should I re-bless the BS boot drive?
 
Your extra keys are all failsafe keys, you are repeating what is already set as default value by OC.

Currently works that way but the OpenCore devs have pointed out a few times that they actually do not have defaults and the behaviour on encountering such missing/unspecified fields is not defined.

Basically, while it currently uses the failsafe in such instances, it might fail on the next release, or, perhaps worse still, work as if you had input an undesirable entry. If you explicitly specify it as done in MyBootMgr however, you will get the failsafe.
It begins ... https://github.com/acidanthera/bugtracker/issues/1392.

MyBootMgr will always explicitly spell out the failsafe value but something for those that only include changes to note.
 
  • Like
Reactions: TECK
Just tried upgrading opencore and lost my config and I can't get into my catalina drive. Will try to restore from backup.

I think you guys should put in the wiki for upgrades just get a new drive and do the whole process from 0 for opencore. Verify this works and then move it back to your main EFI boot drive.

Is there and optimised config.plist somewhere?
 
Just tried upgrading opencore and lost my config and I can't get into my catalina drive. Will try to restore from backup.

I think you guys should put in the wiki for upgrades just get a new drive and do the whole process from 0 for opencore. Verify this works and then move it back to your main EFI boot drive.

Is there and optimised config.plist somewhere?
Not really optimised for Catalina, but my config will allow you to boot into that. Then you can perform your necessary recovery actions.
 
  • Like
Reactions: 0488568
Not really optimised for Catalina, but my config will allow you to boot into that. Then you can perform your necessary recovery actions.

Thank you will give it a look.

I was able to finally get back in to my catalina drive. If you don't inject the correct SMBIOS settings the drive won't boot....
 
Last edited:
Ever since I discovered this thread, and that was months ago, I’ve found the first post to be awe-inspiring, given the thoroughness of its presentation of the issues involved. In addition, it probably presents the safest way to set up OpenCore on an unsupported classic Mac Pro without concerns. Those who closely follow the detailed walkthrough provided will surely succeed.

I must confess, however, that I’ve never followed the installation guide as advised, not even the first time. Although once or twice I did encounter problems (even show-stoppers) of my own making, I’ve found a less perfect, but simpler way to get OpenCore running. It doesn’t require extra disks, nor does it address the issue of running legacy or UEFI Windows. The method I use might be dangerous for some, and I don’t suggest that anyone follow it, unless two conditions are met:
  • You are proficient in the use of basic Mac procedures, such as choosing a boot device, even without an Apple EFI bootscreen.
  • You have a failsafe method to boot your computer in case the procedure somehow fails. That failsafe method may involve booting from a secondary operating system, such as High Sierra or Mojave. Or, if Catalina itself hasn’t been compromised, booting from Catalina itself WITHOUT OpenCore (provided the nvram boot-args=“-no_compat_check” parameter was entered successfully beforehand in pre-Catalina times).
So, how would “my” method work? It’s quite simple, really. I’ll exemplify it by assuming you have a quasi-pristine Catalina installation achieved through dosdude1’s Catalina Patcher. I also take it for granted your Catalina disk is on a GPT partition formatted as APFS. If so, the procedure would be something like this (refer to post #1 for the relevant explanation as to how to carry out each step):
  1. Once you have downloaded the latest version of OpenCore (including a config.plist that is known to work with said version) and, if necessary, Lilu, Whatevergreen, et cetera, mount the EFI volume of one (not two or more) of your internal disks. It needn’t be a system disk (provided it has a GPT-style partition map), and neither does it have to be the disk where Catalina is installed, but it may well be.
  2. Once it’s mounted, create the EFI folder inside said EFI volume, and copy the relevant OpenCore structure to said folder, including the config.plist file.
  3. Reboot to the Recovery partition and bless OpenCore (bear in mind that, in case a future “blessing” is required, you must boot into Recovery by itself, i.e., without recourse to OpenCore).
  4. Reboot the computer. If you have that possibility, you might want to press Option when you hear the chime and then select EFI Boot in the Startup Manager; then the Boot Picker (either text- or graphical-based) should give you the choice to boot into Catalina.
  5. Once you get to Catalina, you can consider the operation was successful. If you didn’t get to Catalina, or you think you need to fine-tune your OpenCore installation (such as, for instance, updating OpenCore itself), follow this maintenance procedure:
  • If OpenCore didn’t work at all, or you didn’t manage to actually boot into Catalina, boot into vanilla Catalina WITHOUT OpenCore, or an earlier version of macOS, such as High Sierra or Mojave.
  • Once you get to your Catalina, Mojave or High Sierra desktop, mount the EFI volume where OpenCore resides.
  • Copy and/or replace whatever is needed (for instance, a newer OpenCore version, newer versions of Lilu, et cetera) and/or edit your config.plist. If the current version of config.plist was already working, it might be a good idea to make a copy and name it, for instance “working copy of config.plist”. Edit whatever needs to be corrected in config.plist and save it.
  • Reboot your computer, boot using OpenCore and go to Catalina. If that doesn’t work, restart the maintenance procedure as many times as necessary and do whatever needs to be done, until you succeed.
 
Last edited:
I didn't follow neither the full process from post #1. But I think the process described there is the best to understand how it works and it will work for almost everybody. It's great having this post (big thanks to people maintaining it).

For me most important things to keep in mind are:
- avoid upgrading firmware
- always have a way to boot vanilla and being able to access a recovery partition (in my case it's mojave)

To disable OC, I've 2 ways:
- remove the opencore disk (it's the last spinning disk I have in my cMP, so easy to identify)
- zap the nvram (my BS drive is on a pcie card so mojave will always boot first)
 
OpenCore 0.6.4 worked a charm going all the way from High Sierra to Catalina to Big Sur.

Everything I need works 100%. Thanks again for all the work everyone puts into this wonderful project.
 

Attachments

  • Screenshot 2020-12-26 at 15.53.42.png
    Screenshot 2020-12-26 at 15.53.42.png
    812.2 KB · Views: 148
  • Like
Reactions: Enricote
For disk labling OC provides its own program called disklabel:
View attachment 1676598
Copy and paste that to your Bootx64.efi folder:
View attachment 1676600
cd to the folder in terminal and run:

Code:
g5@G5s-Mac-Pro-2 BOOT % /Volumes/EFI/EFI/BOOT/disklabel
Usage:
disklabel -d .disk_label image.ppm!
disklabel -e "Label" .disk_label .disk_label_2x
disklabel -bgra "Label" .disk_label .disk_label_2x
I normally pick the second option disklabel -e "OpenCore" .disk_label .disk_label_2x

Thanks for the information! I'm not having success, and wonder if there's a quick solution.

So far, I've moved disklabel to the boot folder, navigated to the appropriate folder in terminal, and tried entering the command, "disklabel -e "Label" .disk_label .disk_label_2x". At this point, I receive the following terminal response (also see screenshot):

disklabel: (null) must be a disk device
 

Attachments

  • 12_27_20__9_13_AM.jpg
    12_27_20__9_13_AM.jpg
    108.4 KB · Views: 128
Really appreciate the response! The addition of sudo got me a little farther (see screenshot). I have a couple of follow up questions: 1. If I have several GPT drives I want to label, do I need to place the disklabel utility inside each disk's EFI/Boot folder, navigate to those folders in terminal, and repeat the process? 2. If so, I might have been inside the wrong EFI folder, and incorrectly labelled a disk. Are you aware of a way to remove a label?
 

Attachments

  • Sudo_label.jpg
    Sudo_label.jpg
    24 KB · Views: 113
@dmcnaugh15 There is another default disklabel utility. If the OC disklabel is not installed system-wide you have to point to it directly. To install system wide you have to install it in /usr/bin overwriting the default one. If you just type disklabel you should see the options it has and if it is the default or OC disklabel you are accessing. If you install it system-wide then all you have to do is navigate to the folder you want to label and run it from there.
 
  • Like
Reactions: dmcnaugh15
Thanks again; I really appreciate your quick responses / advice. I still have questions about the syntax you provided above (sudo ./disklabel -e "YourLabel" .disk_label .disk_label_2x), as follows:
  • "YourLabel" = Is this, the desired new label to be created OR the current label to be targeted for labelling?
  • ".disk_label .disk_label_2x" = Are these, the desired new labels to be created (i.e. do I modify them with labels of my choosing?) OR are they ever modified at all?
 
Thanks again; I really appreciate your quick responses / advice. I still have questions about the syntax you provided above (sudo ./disklabel -e "YourLabel" .disk_label .disk_label_2x), as follows:
  • "YourLabel" = Is this, the desired new label to be created OR the current label to be targeted for labelling?
  • ".disk_label .disk_label_2x" = Are these, the desired new labels to be created (i.e. do I modify them with labels of my choosing?) OR are they ever modified at all?
Yes they are the name of the labels you want to create. The name of the label and the type of the labels.
 
  • Like
Reactions: dmcnaugh15
Yes they are the name of the labels you want to create. The name of the label and the type of the labels.
Okay, to make sure I've got this, "YourLabel" is the name of the label I want to create, and ".disk_label .disklabel_2x" are the types of labels to be applied, and that part of the syntax is never edited?
 
Okay, to make sure I've got this, "YourLabel" is the name of the label I want to create, and ".disk_label .disklabel_2x" are the types of labels to be applied, and that part of the syntax is never edited?
Correct. If just type disklabel it will give you 3 different options.
 
Great! I think I'm making headway. I can see now the two hidden files inside the boot folder. So, if I think I labelled them incorrectly, I should be able to just delete them and re-label, correct?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.