Sidebar Sidebar
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

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.
cdf said:
Here is a set of instructions for preparing an OpenCore CD. Pay close attention to the disk identifier, because using the wrong identifier can lead to data loss!

Preparing an OpenCore Rescue CD

You will need:

An EFI folder placed in your home folder, filled with the all necessary OpenCore subfolders (OC and BOOT) and files, including a working configuration file with RequestBootVarRouting turned off (for native blessing)​

Create the EFI with all the files
  • Open Terminal
  • Create a RAM disk by entering hdiutil attach -nomount ram://409600
You should see the identifier of the disk created: /dev/diskA. Replace the actual identifier in the following steps.
  • Format the temporary disk by entering newfs_msdos -v 'EFI' /dev/diskA
  • Assign a mount point to the disk by entering mkdir OpenCoreCD; mount -t msdos /dev/diskA OpenCoreCD
  • Copy your EFI folder to the disk by entering cp -r EFI OpenCoreCD/
  • Unmount the disk and delete the mount point by entering umount OpenCoreCD; rm -r OpenCoreCD
Create an iso of the EFI
  • Make an image file of the disk by entering dd if=/dev/diskA of=OpenCoreCD.img
  • Convert the image to an iso and cleanup the files by entering hdiutil convert OpenCoreCD.img -format UDTO -o OpenCoreCD.iso; mv OpenCoreCD.iso.cdr OpenCoreCD.iso; rm OpenCoreCD.img
Burn the iso to a CD or DVD
  • Right click OpenCoreCD.iso in your home folder and select "Burn to Disk..."
Click to expand...

Works nicely :)

Took 0.72 package and config.plist from Post 1, set RequestBootVarRouting to false and burned it to a disc.

At 1st step I "burned" it to a thumb drive with Etcher. Booted when selected with the native boot picker. But not with the c - key as a preboot key. I just had hope...
 
c is for booting an installer, on CD, DVD or USB Drive.

If we find a way to force USB with the c-key it would be a major win.

I guess using etcher is the same as just DD the image to the thumb drive.

I am not at the box until tomorrow, so if someone else will try ;-)
 
TECK said:
What changes we should perform? Personally I leave the Mojave SSD in first bay, and I use Latebloom together with Big Sur on one nVME disk, while Windows is on another nVME disk. Can you attach an example of a new simplified config so I understand better what changes?
Click to expand...
This is all very exploratory and still needs to be confirmed, but having Mojave present and using it to format disks to which Big Sur is installed seems to exacerbate the race condition. Thus I have recently replace Mojave by an OpenCore CD for carrying out maintenance. If there is no need for earlier versions of macOS, then a few settings in the config can be simplified. I mentioned these simplifications at the end of post #8,659. To avoid creating a conflict with the current config in the guide, I would rather not include a new config just yet.

Macschrauber said:
c is for booting an installer, on CD, DVD or USB Drive.
Click to expand...
This seems to be correct. Directly from Apple:

Startup key combinations for Intel-based Macs - Apple Support

Learn about the startup key combinations you can use with Intel-based Macs.
web.archive.org

However, I have never been able to boot from a USB drive by holding C. Maybe it's limited to old install media? If we could get it to work, then it would certainly be the ideal solution for this.
 
  • Like
Reactions: TECK and PeterHolbrook
Most people probably already know this, but for someone that don't:

The APFS driver is embedded into the APFS partition itself. The BootROM have just a small part of the driver, the APFSJumpStart, that loads the full EFI driver from the beginning of the APFS partition. This way Apple can improve the real driver successively without issuing new BootROMs. You can read about the details with the Apple paper below:


Why this is important? Mojave APFS driver, that is on any Mojave formatted APFS disk, is now incompatible with BigSur and seems to be the cause of some of data corruption people had. Since my data loss, I had to nuke and format all my APFS data disks with BigSur. Other thing, having a Mojave disk as a rescue disk installed seems to exacerbate the 11.3+ race/kernel panics.
 
  • Like
Reactions: JeDiGM, 0134168, Enricote and 3 others
Considereing the compatiblity issues between formats from Mojave to BSur/Monterey, some days ago I decided to extract my small SSD containing my base Mojave and keeping it in one drawer.
In case of a Opencore problem I just need to extract the HDD with my Opencore EFI so I can boot natively using Mojave without Opencore and without a EFI GPU.
Do you see this approach useful?
 
Last edited:
Enricote said:
Considereing the compatiblity issues between formats from Mojave to BSur/Monterey, some days ago I decided to extract my small SSD containing my base Mojave and keeping it in one drawer.
In case of a Opencore problem I just need to extract the HDD with my Opencore EFI so I can boot using Mojave without Opencore and without a EFI GPU.
Do you see this approach useful?
Click to expand...
If you also nuke and reformat any APFS data disks with BigSur, yes.

Personally, I'm keeping all my storage disks with the old and trusty HFS+, so I can use any past macOS release if/when needed and have access to my data. Just my main and scratch disks are now APFS formatted by Big Sur, everything else is back to HFS+.
 
  • Like
Reactions: JeDiGM, paalb and Enricote
Is there a way to "sanitize" an existing Mojave disk? Would there be a "live" manner of doing it? If that isn't possible, would it be feasible, for instance, to back up the existing Mojave disk, then nuke it, reformat it as APFS using Big Sur or Monterey and, lastly, restore the backup to said disk?
 
PeterHolbrook said:
Is there a way to "sanitize" an existing Mojave disk? Would there be a "live" manner of doing it? If that isn't possible, would it be feasible, for instance, to back up the existing Mojave disk, then nuke it, reformat it as APFS using Big Sur or Monterey and, lastly, restore the backup to said disk?
Click to expand...
This don't make sense, if you update the APFS driver at the start of the APFS partition it will be incompatible with Mojave itself.

Remove your Mojave disk from your Mac Pro, install you Mojave fail safe disk only when needed.

Backup any APFS data disks formatted by HighSierra/Mojave/Catalina, destroy the partition table (nuke it), recreate it with Big Sur.
 
  • Like
Reactions: Enricote and PeterHolbrook
^Yes, I "discovered" weeks ago that the main culprit (in my case) for the consistent failure to make BS 11.3+ boot on my Mac Pro 5,1 was the presence of a complex disk with a mixture of HFS+ partitions and APFS containers for Snow Leopard, High Sierra and Catalina. I nuked that disk and now it is just one single APFS container with Mojave. I'm not claiming to be the discoverer of anything, although I did "discover" it as far as my case is concerned; others may have discovered something similar well before I did.

Now, admittedly, I've only booted Mojave once ever since and there were no issues, and my latest attempts to boot Big Sur 11.5.1 have all been successful. In other words, the mere presence of my Mojave disk doesn't seem to be a detrimental factor. Are you saying that if I were to boot Mojave more often, there would be a non-zero likelihood that my Big Sur disk might get corrupted? Or that if I entirely remove Mojave from the equation I'll get a guaranteed 100% success rate in booting BS 11.3+ and Monterey?
 
PeterHolbrook said:
^Yes, I "discovered" weeks ago that the main culprit (in my case) for the consistent failure to make BS 11.3+ boot on my Mac Pro 5,1 was the presence of a complex disk with a mixture of HFS+ partitions and APFS containers for Snow Leopard, High Sierra and Catalina. I nuked that disk and now it is just one single APFS container with Mojave. I'm not claiming to be the discoverer of anything, although I did "discover" it as far as my case is concerned; others may have discovered something similar well before I did.

Now, admittedly, I've only booted Mojave once ever since and there were no issues, and my latest attempts to boot Big Sur 11.5.1 have all been successful. In other words, the mere presence of my Mojave disk doesn't seem to be a detrimental factor. Are you saying that if I were to boot Mojave more often, there would be a non-zero likelihood that my Big Sur disk might get corrupted? Or that if I entirely remove Mojave from the equation I'll get a guaranteed 100% success rate in booting BS 11.3+ and Monterey?
Click to expand...
I've been crystal clear with my previous posts, just the presence of any APFS disk formatted by Mojave/High Sierra exacerbate the 11.3+ KPs.
 
  • Like
Reactions: PeterHolbrook
tsialex said:
Most people probably already know this, but for someone that don't:

The APFS driver is embedded into the APFS partition itself. The BootROM have just a small part of the driver, the APFSJumpStart, that loads the full EFI driver from the beginning of the APFS partition. This way Apple can improve the real driver successively without issuing new BootROMs. You can read about the details with the Apple paper below:


Why this is important? Mojave APFS driver, that is on any Mojave formatted APFS disk, is now incompatible with BigSur and seems to be the cause of some of data corruption people had. Since my data loss, I had to nuke and format all my APFS data disks with BigSur. Other thing, having a Mojave disk as a rescue disk installed seems to exacerbate the 11.3+ race/kernel panics.
Click to expand...
The bless command will re-embed the APFS driver. https://github.com/joevt/bless/blob/739da07c50c38e450f8983f84d4c61ed6e855155/handleFolder.c#L371
Maybe reblessing from Big Sur all your APFS partitions is sufficient? I haven't done any testing though. You have to verify that the source is the apfs.efi of Big Sur and not the one from the System Volume of the container that you are blessing (/usr/standalone/i386/apfs.efi) Would be nice to have an app to check the versions of all the embedded APFS drivers.
 
joevt said:
The bless command will re-embed the APFS driver. https://github.com/joevt/bless/blob/739da07c50c38e450f8983f84d4c61ed6e855155/handleFolder.c#L371
Maybe reblessing from Big Sur all your APFS partitions is sufficient? I haven't done any testing though. You have to verify that the source is the apfs.efi of Big Sur and not the one from the System Volume of the container that you are blessing (/usr/standalone/i386/apfs.efi) Would be nice to have an app to check the versions of all the embedded APFS drivers.
Click to expand...
If your tests confirm that the blessing from Big Sur really make the current APFS driver to be embedded, this would eliminate the need of nuking APFS data disks.

My empirical observation, also observed by other developers, is that Mojave don't like, I'll refrain to say that is incompatible, the Big Sur APFS driver and it's probably the source of some of the data corruption people were having.
 
Last edited:
cdf said:
configuration file with RequestBootVarRouting turned off
Click to expand...
Is it possible to check what RequestBootVarRouting or other OC options are set to from Terminal?
I suppose only stuff stored in the NVRAM such as opencore-version can be so checked.
 
tsialex said:
If your tests confirm that the blessing from Big Sur really make the current APFS driver to be embedded, this would eliminate the need of nuking APFS data disks.

My empirical observation, also observed by other developers, is that Mojave don't like, I'll refrain to say that is incompatible, the Big Sur APFS driver and it's probably the source of some of the data corruption people were having.
Click to expand...
The bless command embeds the apfs driver if you are doing the --setboot option for an apfs volume and you see "This is not an APFS Data-Volume-Parameter-Driven Pre-SSV to SSV case" in the verbose output. It usually embeds the apfs driver that is on the disk that you are blessing. You can override that with the --apfsdriver option.

So, from Catalina, I can do this to my Mojave volume:
Code: 
sudo bless --verbose --folder /Volumes/Mojave6/System/Library/CoreServices --file /Volumes/Mojave6/System/Library/CoreServices/boot.efi --setboot --apfsdriver /usr/standalone/i386/apfs.efi
 
  • Like
Reactions: PeterHolbrook
Dayo said:
Is it possible to check what RequestBootVarRouting or other OC options are set to from Terminal?
I suppose only stuff stored in the NVRAM such as opencore-version can be so checked.
Click to expand...
Doesn't necessarily need to be in NVRAM.
In IORegistryExplorer.app, select the DeviceTree plane. Go to /efi
There's device-properties - this is a database of properties by EFI device path that are copied to the IO Registry.
There's configuration table - I suppose you could make your own configuration table in EFI and it would appear here. Is this where MaciASL gets ACPI from?
runtime-services - is like the configuration table - this has pointers to various functions including NVRAM read and write functions.
options - this is a copy of NVRAM variables (only the Apple ones). A kext driver can add properties here and they'll be saved to NVRAM?
 
joevt said:
Doesn't necessarily need to be in NVRAM.
Click to expand...
Thanks but looking for what a standard OpenCore implementation has. Not some changes I make to this.
It saves some items to NVRAM but don't think it saves its settings in general.

RequestBootVarRouting creates a namespaced NVRAM bit that might be possible to detect if present I suppose.
 
cdf said:
I suppose that you could use the OC booter path NVRAM variable to access the actual config file and get the settings from there.
Click to expand...
But the OC booter path is a UEFI device path that will need some fancy code to convert to a macOS path. I suppose the bless code might have a method. Or you could assume a GPT formatted disk, extract the partition UUID from the UEFI device path and just look for that.
 
Hi, BS on nvme and win 10 legacy on ssd, I want to install Mojave on another drive and start it via OC, what could go wrong ? :D
 
Hi guys. After an unsuccessful attempt to update my BS to 11.5.2 I went through over 14 hard restarts, the last four trying to switch OS disks via the picker to get the mac booted and troubleshoot.

I seem to have a lot of problems getting the picker to work. It always appears, but more often than not ignores my keyboard pressing (ESC, OPT, ESC+OPT, Banging the arrow keys, clicking the mouse etc) and only sometimes registers the random arrow presses and I manage to navigate to the right hd before it continues. Most of the time it just continues right through the picker and selects its default.

The keyboard is a pre-aluminium wired full apple keyboard and mouse. I've tried two of them, no differemce. My usual walumium keyboard is connected via an extender so doesnt register in the picker.

What is the procedure with the OC picker - which key to activate and when? Why would it ignore arrow key pressing and the esc/opt key most of the time.
 
Hi. On my MacPro I have a strange behavior that I guess is related to OpenCore. I can't be totally sure, because it's something I don't notice immediately but previously for some months I used Catalina through Dosdudes patcher and didn't notice it (and sure it didn't happen before). What going on? Every time I reboot my MacPro, Archicad says license key is damaged and need to be repaired. This means that I must upload the license on software house server and download it again. Nothing to bud, until key remains reparable and Graphisoft won't ask me way I have corrupted license even more times in a day.
Before I installed OpenCore, this happened only after a system update. Now it happens at every reboot. Is there someone that can figure what can cause this? And is there's something I can do to prevent it?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back