MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro

[cdf]

Surely this doesn't apply when you keep the Mojave disk outside the MP, and only reinsert it when you need to do maintenance? In that situation, you'll be booting into Mojave rather than Big Sur, so there shouldn't be any hanging?

Correct. Just in my case, never had to boot from Mojave for fixing yet.

Using an external Mojave disk for maintenance is possible, but without a flashed graphics card or another boot-selection strategy in place, the approach is not very practical. You'll have to resort to an extreme procedure (see "Emergency Recovery Procedure" in part 3 of the guide). This procedure involves a lot of manipulation:

1. Shut down your Mac
2. Remove Disk A (the one with OC and Big Sur) and connect Disk B (Mojave)
3. Start up your Mac, resetting the NVRAM to hopefully boot into Mojave by default
4. Use Mojave to bless Disk B
5. Shut down again
6. Reinsert Disk A
7. Start up and boot into Mojave again (previously blessed) and do the maintenance on Disk A

On the other hand, with Mojave present (which might be problematic with Big Sur 11.3+ as mentioned above), you can turn to the usual procedure (see "Disabling OpenCore" in part 3), which doesn't require opening up the machine to remove Disk A.

Ah, the pleasures of a classic Mac Pro without the native boot picker!

 

[Macschrauber]

I always recommend keeping a bootscreen GPU in the drawer. A GT120 is enough for the native mac firmware boot picker and blessing OC (with ctrl-key).

GT120 are bloody cheap if you have none...

 

[mode11]

@cdf If you reset NVRAM, won't the Mac always boot from SATA bay 1? This was my experience recently (to my annoyance) after I re-flashed my Bootrom. I only managed to boot from NVMe again by selecting that drive from the Startup Disk pane in Mojave (attempts at 'blessing' didn't work).

Another approach may be to have OC on multiple disks (I have it on my Windows SATA SSD in bay 1 as well). Won't need to be the latest version to give the boot picker. In my case, the reason I have it there is to protect against accidentally booting into Windows without OC. Though I guess if the NVRAM reset works, it's unnecessary anyway - and if it doesn't, the Mac will still boot to the Big Sur disk.

@Macschrauber Yeah, I've still got one of those in a drawer (and a flashed 680GTX). Can you bless the OC drive from the boot picker?

 

[Dayo]

Using an external Mojave disk for maintenance is possible, but not very practical:

1. Shut down your Mac
2. Remove Disk A (the one with OC and Big Sur)
3. Connect Disk B (Mojave)
4. Start up your Mac, resetting the NVRAM to hopefully boot into Mojave by default
5. Use Mojave to bless Disk B
6. Shut down again
7. Reinsert Disk A
8. Start up and boot into Mojave again (previously blessed) and do the maintenance on Disk A

A bit involved but not particularly impractical for infrequent occurrences. Certainly less involved than retrieving a boot screen capable GPU from a drawer and sticking this in ... which itself is fine for such demands.

With a RefindPlus chain-loading arrangement though, the list above becomes:

1. Shut down your Mac
2. Connect Disk B (Mojave)
3. Start up, boot into Mojave via RefindPlus and do the maintenance on Disk A

Looking into adding a feature to RefindPlus that will disconnect a volume (such as Mojave in this instance) so that it can stay in and not be visible to Big Sur when that is being booted. When maintenance is needed, the process will become:

1. Reboot into Mojave via RefindPlus and do the maintenance on Disk A

Early days on that though.

 

[cdf]

@cdf If you reset NVRAM, won't the Mac always boot from SATA bay 1? This was my experience recently (to my annoyance) after I re-flashed my Bootrom. I only managed to boot from NVMe again by selecting that drive from the Startup Disk pane in Mojave (attempts at 'blessing' didn't work).

No. My AHCI PCIe disk (with OC and Big Sur) has precedence after an NVRAM reset. On the one hand, it's great because OC will always boot after an NVRAM reset, and with LauncherOption enabled, it will automatically be reblessed. On the other hand, it's not so great if something goes wrong with OC.

Can you bless the OC drive from the boot picker?

Yes. Control+Enter with the native boot picker.

A bit involved but not particularly impractical for infrequent occurrences.

For infrequent occurrences, yes. But for heavy testing (especially playing with Latebloom parameters), it can quickly become annoying!

RefindPlus is definitely a nice strategy, but recently I've really enjoyed the simplicity of popping in an emergency OpenCore CD and bypassing Mojave altogether to fix my main config...

 

[HanYolo]

I have a cMP 5,1. Recently I installed Catalina using dosdude1 method without problems. Then I purchased a flashed alpine ridge thunderbolt card. The instructions tell me I have to install opencore for thunderbolt to be recognized and to also get hot swap support. Can Opencore be installed on 5,1 Catalina after using dosdude1 method?

 

[Dayo]

For infrequent occurrences, yes. But for heavy testing (especially playing with Latebloom parameters), it can quickly become annoying!

Yeah, definitely painful testing something with a high chance of failure.

I've really enjoyed the simplicity of popping in an emergency OpenCore CD

Would that not be similar to having an OC instance on a USB? I suppose the advantage of the CD is being able to get it to use that specific instance without having to pull disks etc.

Once I started dabbling in OC, I very quickly realised an ability to readily boot into multiple OC instances at will was a must and built the MyBootMgr setup around this.

 

[cdf]

Can Opencore be installed on 5,1 Catalina after using dosdude1 method?

Yes, but it's not at all recommended.

 

[cdf]

Would that not be similar to having an OC instance on a USB? I suppose the advantage of the CD is being able to get it to use that specific instance without having to pull disks etc.

The main advantage here is always being able to access a boot picker by holding C on start up. It's just like holding Option with a supported graphics card. (Apparently, holding C also works for USB drives, but I haven't found that to be the case.)

Another possibility is D: By using a shim called diag.efi in /System/Library/CoreServices/.diagnostics/ on an appropriately formatted volume, it might be possible to access a boot picker (OC or RefindPlus) by holding D.

 

[Macschrauber]

@cdf

maybe you explain how the cd should be made?

just HFS with a folder EFI?

special settings as it cant write to the FileSystem?

having a rescue cd is a neat thing for users without Bootscreen GPUs.

 

[TECK]

With a complete reformatting, you'll lose your natively bootable Mojave lifeline

Wien my new job responsibilities I have to boot into Windows every week day. Before I used to leave the Mac on sleep and never have issues. Now because I'm forced to use Windows every day, rebooting several times to get back to Big Sur is a real pain. I have no idea how I did not have issues in the past rebooting 10 times. There are days I can reboot fine several times and days when I have to reboot at least 5 times until I'm back to Big Sur.

I don't know what to do, sometimes I'm tempted to get a Mac Pro 2013 and be done with all current issues.

 

[cdf]

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..."

 

[mikas]

I don't know what to do, sometimes I'm tempted to get a Mac Pro 2013 and be done with all current issues.

I do feel for you. Just reconsider for a while before jumping that 6,1 road.
I woke up last saturday morning and checked the results of shutdowncause with terminal.
Last login: Sat Aug 7 14:09:13 on console

I'm pretty much sure I was sleeping allready at the time of those late night boots, and I don't know what was happening there. Big Sur 11.5.1 running now. I'm not so reassured of the latest Bug Sir update.

Most of the programs do recover from those boots, I reckon. I think not everybody bothers to bother about these incident that much with 6,1's because of this recovery process. My main program does not recover that gracefully though. It needs some user interaction to fully recover. Maybe because I fire a lot of instances of that program all the time. That's how it works. An instance for one project. Or an instance of a program for one file that is.

Sorry I am OT. I am on 6,1 now. Maybe I should go with 5,1 OC+LB, and maybe get a more reliable alternative to this 6,1.

 

[tsialex]

Wien my new job responsibilities I have to boot into Windows every week day. Before I used to leave the Mac on sleep and never have issues. Now because I'm forced to use Windows every day, rebooting several times to get back to Big Sur is a real pain. I have no idea how I did not have issues in the past rebooting 10 times. There are days I can reboot fine several times and days when I have to reboot at least 5 times until I'm back to Big Sur.

I don't know what to do, sometimes I'm tempted to get a Mac Pro 2013 and be done with all current issues.

Maybe a dedicated NUC for your Windows usage would be better suited, some are really inexpensive. While tempting, late-2013 Mac Pro also have lot's of issues, same NVRAM problems, same UEFI Windows issues (just take more time to become a problem), extremely limited internal storage, very weak GPUs, USB2.0, TB2.0 and more problems that MacPro5,1 don't have like the extremely complex procedure (21+ steps) to replace the RTC battery and really expensive replacement parts.

Said all that, I'll have a late-2013 Mac Pro when a decent one in my price range appears, still around US$ 1550+ for a D300 basic config locally.

 

[tsialex]

I do feel for you. Just reconsider for a while before jumping that 6,1 road.
I woke up last saturday morning and checked the results of shutdowncause with terminal.
Last login: Sat Aug 7 14:09:13 on console
View attachment 1816298
I'm pretty much sure I was sleeping allready at the time of those late night boots, and I don't know what was happening there. Big Sur 11.5.1 running now. I'm not so reassured of the latest Bug Sir update.

Most of the programs do recover from those boots, I reckon. I think not everybody bothers to bother about these incident that much with 6,1's because of this recovery process. My main program does not recover that gracefully though. It needs some user interaction to fully recover. Maybe because I fire a lot of instances of that program all the time. That's how it works. An instance for one project. Or an instance of a program for one file that is.

Sorry I am OT. I am on 6,1 now. Maybe I should go with 5,1 OC+LB, and maybe get a more reliable alternative to this 6,1.

First thing that I'd check for SMC errors with a MP6,1 is the RTC battery. I know that the absolute majority of MP6,1 owners will NEVER replace it (you have to take it all apart) and when the RTC counters become stuck, you have all sort of issues with sleep and SMC.

Sorry for the off-topic.

 

[mikas]

Thanks Alex. I'll check that.
edit. sorry for OT too. Gosh I am embarrased again.

 

[TECK]

Maybe a dedicated NUC for your Windows usage would be better suited, some are really inexpensive.

I need something powerful like the 5,1 setup I have now, thank you for letting me know about all 6,1 issues. It looks like is best to stick with 5,1 and try Latebloom.

 

[TECK]

I added Latebloom support into OC Plistlib Generator, see #111 and #112. I had to format Latebloom the zip file as it was not properly formatted for some reason (see command used into PR). I also updated the documentation.

 

[0134168]

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..."

So nice!

 

[dataid]

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

Great contribution. Could you incorporate this as Part V of the wiki post?

 

[cdf]

Great contribution. Could you incorporate this as Part V of the wiki post?

I was planning to include it earlier in the guide as one of three methods for initially blessing OC:

1. Current approach with Mojave* (bless command in recovery mode)
2. Standard approach with an EFI graphics card (Control+Enter)
3. OC CD (Control+Enter)

*We've long considered Mojave to be an integral part of using OC on the Mac Pro 5,1. But that should perhaps change because of the apparent incompatibility with Big Sur and Monterey (APFS differences and the race condition). In fact, dropping older versions of macOS results in a config that is not only more minimal (Mac Pro 7,1 board-id, no agdpmod, no shikigva, no Apple Boot Policy override), but also more secure (Apple Secure Boot model).

 

[Dayo]

Mac Pro 7,1 board-id

Doesn't that preclude running Catalina (or earlier for MP3,1)?

 

[cdf]

Doesn't that preclude running Catalina (or earlier for MP3,1)?

Mac Pro 7,1: +10.15.1
iMac Pro: +10.13.2

We used the latter to be able to boot Mojave, Catalina, and Big Sur with OpenCore.

The point here is that different versions of macOS require different settings. If we are just interested in running the latest OS (which is what Apple apparently considers as desirable for supported Macs), then to keep things nice and minimal and tractable, we want to avoid accumulating unnecessary settings and procedures.

 

[Dayo]

If we are just interested in running the latest OS

Forgot the 7,1 came out during the reign of Catalina. Makes no difference if on a 5,1 (or for others if the interest is as stated indeed).

 

[TECK]

But that should perhaps change because of the apparent incompatibility with Big Sur and Monterey (APFS differences and the race condition).

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?