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.
Considering the title of this thread reads "Manually Configured OpenCore on Mac Pro" should one understand this to mean that OpenCore can be installed without the editing described above or is the manual configuration of this software mandatory? I am new to anything Apple, so even a simple task appears daunting.

 
There are other packages that utilize OpenCore as the base, and that configure automatically to the authors preferred settings.

This thread deals with bare-bones OpenCore, and walks you through installation and configuration. It's highly stable and no so many hacks.
 
Sorry I am a noob. What is the best practice for installing open core boot loader? Is it best to install on it's own SSD? I want to have Mojave boot disk and Monterey boot disk, and maybe a linux boot disk. Thanks
 
Sorry I am a noob. What is the best practice for installing open core boot loader? Is it best to install on it's own SSD? I want to have Mojave boot disk and Monterey boot disk, and maybe a linux boot disk. Thanks

Check out post#1:
Boot natively > Choose your ESP

It would benefit you to read through all of post#1 first before you go any further, advice that I was given too when I was starting out. ;) You'll learn more about the end-to-end process and you'll be more satisfied in problem solving any issues that come up.

To answer your question about the disk you choose for your EFI, there's a big hint in post#1 mentioned above
A typical choice for your ESP is the EFI volume of the disk on which you plan to install macOS Catalina, Big Sur or Monterey. If your choice corresponds to the current boot disk, make sure that you have another disk with a natively bootable installation of macOS.
 
So is there any compelling reason to upgrade OC. My rig functions perfectly AFAIK. What’s YOUR take?
Feature-wise: unless you use audio assist or are bothered by the order of the boot-picker Shutdown and Restart buttons, there's little reason to update from 0.9.7. That being said, I always update :cool:
 
That being said, I always update :cool:
Well, I may go ahead and do this just for the practice. I'm not up to it at the moment though. I scanned over the Maintenance section and it seems like I have to boot back into Mojave to copy all the files over again. I think I messed up my Mojave install by accessing it from Monterey to copy files. So it may take more work than I currently feel like doing. I don't suppose I could simply mount my ESP from within Monterey and do the copy?

Is there more to it than copy and reboot?

I have to figure out if Mojave can be repaired too.
 
I don't suppose I could simply mount my ESP from within Monterey and do the copy?
Yes, everything can be done from Monterey. But you're absolutely right: by referring to Basic setup in Maintenance, the guide does make it seem like you should boot natively to install the basic components because that's how the procedure is described in Basic setup. I've added a clarifying remark in the guide. Thanks!

Is there more to it than copy and reboot?
No, that's it!
 
  • Like
Reactions: crjackson2134
Sweating bullets there for a few minutes. Had a non-bootable Monterey. I worked through it, and it's back AFAIK.

I'll double check a few things tomorrow (or later tonight if the caffein catches up). I guess I needed to go through this to learn how it works.

Any idea why the version number isn't known?
Screen Shot 2024-02-07 at 7.41.33 PM.png

 
Last edited:
I have a legacy windows install. If I remove my open core NVME install so that I can boot into windows, are there any boot rom issues if I do the BIOS conversion without the open core drive inside?
 
I have a legacy windows install. If I remove my open core NVME install so that I can boot into windows, are there any boot rom issues if I do the BIOS conversion without the open core drive inside?
when you boot uefi windows without OpenCore there will be certificates written into the nvram stream. If you restart often enough to let the garbage collection happen you will get certificates in both streams.

Booting the USB Windows installer thumb drive is enough to get the bootrom signed.

Don't do that without protection.

Do a bootrom backup before. If you get yours signed you can flash the backup back. I wrote a tool for reading, analysing and writing the Mac Pro firmware. See https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801
 
when you boot uefi windows without OpenCore there will be certificates written into the nvram stream. If you restart often enough to let the garbage collection happen you will get certificates in both streams.

Booting the USB Windows installer thumb drive is enough to get the bootrom signed.

Don't do that without protection.

Do a bootrom backup before. If you get yours signed you can flash the backup back. I wrote a tool for reading, analysing and writing the Mac Pro firmware. See https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801
I am not trying to install via USB. I already have a legacy boot windows 10 install from years ago. This is not recognised in opencore however without refind. I am simply going to convert it to a UEFI install via mbr2gpt /convert /disk:0 /allowfullos.
 
when you boot uefi windows without OpenCore there will be certificates written into the nvram stream. If you restart often enough to let the garbage collection happen you will get certificates in both streams.

Booting the USB Windows installer thumb drive is enough to get the bootrom signed.

Don't do that without protection.

Do a bootrom backup before. If you get yours signed you can flash the backup back. I wrote a tool for reading, analysing and writing the Mac Pro firmware. See https://forums.macrumors.com/thread...es.2333460/page-4?post=32055801#post-32055801
To clarify: In order to boot into the legacy install above, you cannot have opencore running, as it is a known issue with opencore that it does not recognise legacy bios installs of windows.
 
To clarify: In order to boot into the legacy install above, you cannot have opencore running, as it is a known issue with opencore that it does not recognise legacy bios installs of windows.
if you convert your legacy windows to uefi windows you will get certificates when you boot it without protection.

Anyway, you can add a bootscreen with EnableGop to your GPU and select uefi Windows with the native built in Apple Boot Picker.

As said, you should make a boot rom backup, just in case, when you plan to use uefi Windows. In case uefi Win is running without OC you can flash the backup back and get the certificates deleted.
 
To clarify: In order to boot into the legacy install above, you cannot have opencore running, as it is a known issue with opencore that it does not recognise legacy bios installs of windows.

11.6 OpenLegacyBoot​

OpenLegacyBoot is an OpenCore plugin implementing OC_BOOT_ENTRY_PROTOCOL. It aims to detect and boot legacy installed operating systems on supported systems, such as OpenDuet and Mac models capable of legacy booting.

Usage:

  • Add OpenLegacyBoot.efi and also optionally (see below) OpenNtfsDxe.efi to the config.plist Drivers section.
  • Install Windows or another legacy operating system as normal if this has not been done earlier – OpenLegacyBoot is not involved in this stage and may be unable to boot from installation media such as a USB device.
  • Reboot into OpenCore: the installed legacy operating system should appear and boot directly from OpenCore when selected.
OpenLegacyBoot does not require any additional filesystem drivers such as OpenNtfsDxe.efi to be loaded for base functionality, but loading them will enable the use of .contentDetails and .VolumeIcon.icns files for boot entry customisation.


11.6.1 Configuration​

No additional configuration should work well in most circumstances, but if required the following options for the driver may be specified in UEFI/Drivers/Arguments:
  • --hide-devices - String value, no default.
    When this option is present and has one or more values separated by semicolons
    (e.g. --hide-devices=PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,...)), it disables scanning the specified disks for legacy operating system boot sectors.
 
Is it possible for OpenCore to manage a BIOS emulation based Windows install?
I know it's supposed to protect the BootROM from EFI Windows's meddling, but Alex said in some circumstances Windows manages to break through and perform a write.
 
BIOS emulation based Windows install
Not sure what this means, but if you are inquiring about the legacy Windows there are no dangers for the NVRAM section if the partitioning scheme is MBR or Hybrid MBR (GPT with protective MBR).
The above limitation is probably the only limitation for such partition schemes.
 
Is it possible for OpenCore to manage a BIOS emulation based Windows install?
I know it's supposed to protect the BootROM from EFI Windows's meddling, but Alex said in some circumstances Windows manages to break through and perform a write.

UEFI installed Windows can bypass OpenCore ProtectSecureBoot when doing major software updates (boot coup), since OpenCore now supports BootCamp installed Windows, you can have a totally secure Windows install - no SecureBoot with BIOS/CSM/BootCamp installs.
 
  • Like
Reactions: startergo
Is it possible for OpenCore to manage a BIOS emulation based Windows install?
I know it's supposed to protect the BootROM from EFI Windows's meddling, but Alex said in some circumstances Windows manages to break through and perform a write.
You may be referring to OpenCore NVRAM emulation? IMO this _can_ protect the MacPro NVRAM from all the writes which Windows does - although it's never really caught on for that purpose as I hoped it would.

I have not experimented with Windows updates or installs using this (macOS updates, yes, ofc) - but based on what I've seen with macOS, I would say it's at least reasonably possible that Windows may succeed in updates (or even installs) using emulated NVRAM, even though it would effectively lose anything it writes to NVRAM on each boot.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.