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

[tsialex]

@Syncretic's done their magic again, was able to boot a MacPro4,1 to 12.1 Beta 1!View attachment 1882706

@Syncretic rules, no doubt!

I'm curious, how did you made a Westmere hex-core run on a MacPro4,1? Did you replaced all the CPU support EFI modules and added the necessary microcodes inside the MP4,1 EFI or it's just a cross-flashed early-2009 to MP5,1 with Model Identifier = MacPro5,1?

 

[Dewdman42]

Correct. The presence of this bit does not affect booting previous versions of macOS.

check.

In any case, the NVRAM usage of modern macOS is so much more than what the BootROM of the MacPro5,1 was designed for, so it's becoming increasingly important to use a Matt card as a precautionary measure, or at least to periodically refresh a clean BootROM image.

I hear you. A MATT card is not practical for me, I'm just getting a couple more years of use out of this box before moving on to Apple Silicon. I'm definitely going to refresh my bootROM every couple months. In fact I am going to do so right now.

Near as I can tell, Bootcamp was filling up NVRAM way more than this would I guess

I've tested SecureBootModel set to Default with Big Sur and Monterey. Since 0.7.4, the Default option takes the model matching the board ID. I haven't tested this in Catalina.

ok. I just read up about it, I'm amazed that when I installed OC 0.7.4 with this parameter set to default, that Catalina continued to boot, considering the docs on Dortania say the following:

But it seems like changing it to "disabled" should be fine though arguably less secure. I will give that a try. If so then I can use one single OC config for both Catalina and Monterey.

My recommendation for installing Monterey (SecureBootModel and updated firmware features) was based on the release candidates, which had VMM left out. The flag will likely work with future updates (without SecureBootModel and firmware features), so that might be your answer.

I see. So you're saying in the future we may want to use a more simple OC, without firmware features, without T2 fake out...just use VMM for installing and updating, but turn off VMM the rest of the time?

 

[cdf]

I'm definitely going to refresh my bootROM every couple months. In fact I am going to do so right now.

?

ok. I just read up about it, I'm amazed that when I installed OC 0.7.4 with this parameter set to default, that Catalina continued to boot, considering the docs on Dortania say the following:

The documentation is outdated. As of 0.7.4, Default takes the model matching the board ID, so it makes sense that Catalina can still boot because iMacPro1,1 (and MacPro7,1) are supported in Catalina. Thanks for confirming.

But it seems like changing it to "disabled" should be fine though arguably less secure. I will give that a try. If so then I can use one single OC config for both Catalina and Monterey.

But if Catalina can still boot with Default, you could just use that.

I see. So you're saying in the future we may want to use a more simple OC, without firmware features, without T2 fake out...just use VMM for installing and updating, but turn off VMM the rest of the time?

Correct. Just like with Catalina.

I got around to doing more testing and was able to install Monterey with the VMM flag, SecureBootModel set to Disabled, and the original firmware features. So the VMM issue seems to have been limited to the release candidates. Nevertheless, I still find that SecureBootModel set to Default and updated firmware features is a more vanilla choice.

 

[Dewdman42]

The documentation is outdated. As of 0.7.4, Default takes the model matching the board ID, so it makes sense that Catalina can still boot because iMacPro1,1 (and MacPro7,1) are supported in Catalina. Thanks for confirming.

No wait, maybe I had that backwards. So I have been booting Catalina with SecureBootModel=DISABLED.

The question at hand is whether it will book up ok in Catalina should I change it to DEFAULT.

I will have to just try it and let you know. Worst case it won't boot and I'll have to go back to Mojave to change it back. Stay turned.

I got around to doing more testing and was able to install Monterey with the VMM flag, SecureBootModel set to Disabled, and the original firmware features. So the VMM issue seems to have been limited to the release candidates. Nevertheless, I still find that SecureBootModel set to Default and updated firmware features is a more vanilla choice.

Got you. let me try booting Catalina with SecureBootModel set to Default. I suspect actually it won't work unless you're right that those docs are not up to date and it can really go older than BigSur with Default setting.

Besides being more vanilla this new way, it would avoid having to switch on VMM on and off for updates, etc..

 

[mangombia]

?



The documentation is outdated. As of 0.7.4, Default takes the model matching the board ID, so it makes sense that Catalina can still boot because iMacPro1,1 (and MacPro7,1) are supported in Catalina. Thanks for confirming.



But if Catalina can still boot with Default, you could just use that.



Correct. Just like with Catalina.

I got around to doing more testing and was able to install Monterey with the VMM flag, SecureBootModel set to Disabled, and the original firmware features. So the VMM issue seems to have been limited to the release candidates. Nevertheless, I still find that SecureBootModel set to Default and updated firmware features is a more vanilla choice.

My question is whether I can just change SBM in the config to "Disabled," reboot and be able to boot Mojave? Or but another way, can we get rid of the Firmware Features necessary/recommended for install of Monterey, change SBM to disabled, and only trigger the VMM flag for updates?

 

[Dewdman42]

But if Catalina can still boot with Default, you could just use that.

So I tried out booting Catalina with SBM=Default

result is that it booted into Catalina but I immediately got error messages about my AppleID being wrong or something, and I tried to re-enter my AppleID password over and over but it kept stuttering and asking again, and prompting for my admin password repeatedly also.

So.. I don't know if this would have resolved itself eventually, but I have changed back to Disabled for now. I think somehow Catalina doesn't hundred percent like the SBM=Default, or maybe its because I had installed it the other way first and was running it that way, maybe it would have resolved itself with time, hard to say.

 

[Kmilot]

Given the nature and location of the issue, I do not recommend even attempting to install 12.1b1 on a pre-Ivy Bridge Mac until my new patch is made public, or it's made available in OCLP or other packages. It's being tested even as you're reading this; please be patient. (Again: it's a speed bump, not a brick wall.)

Man you are a legend! Thank you!

 

[h9826790]

My question is whether I can just change SBM in the config to "Disabled," reboot and be able to boot Mojave? Or but another way, can we get rid of the Firmware Features necessary/recommended for install of Monterey, change SBM to disabled, and only trigger the VMM flag for updates?

John helps me to run many extensive tests in the last few days about this SecureBootModel (SBM) setting. Because I want to find out a single config that can boot Mojave, Catalina, Big Sur, and Monterey.

What we found so far.

1) If we set SBM = default, then we can boot Catalina, Big Sur, and Monterey. But cannot boot Mojave (we call this "Legacy Mojave" here).

2) If we set SBM = disable, then we can boot Mojave, Catalina, Big Sur. But cannot boot Monterey (official release, not early beta).

3) However, if we set SBM to Default, then we install Mojave (e.g. from a USB installer), we can actually boot Mojave (we call it "Secured Mojave") with SBM = Default.

4) AFAIK, when SBM set to default, something will be written to the NVRAM, and that's the key for booting "Secured Mojave".

5) If we remove OpenCore after "Secured Mojave" installed, then the cMP can't boot to that Secured Mojave anymore. However, if we perform a NVRAM reset. This will remove that "key", and revert that Secured Mojave back to Legacy Mojave. Then the cMP can boot this Legacy Mojave without OC again.

So, if anyone want to dual boot Mojave (the latest macOS that officially supported on cMP), and Monterey (the latest official released macOS), then...

A) You can keep changing the SBM setting to let you boot back to your existing Mojave, or Monterey. There is no need to touch the FirmwareFeatureMask.

B) You may set SBM = Default, then re-install Mojave. This should makes you can dual boot Mojave and Monterey with a single config. And all you need to remember is that on the day you remove OC, also perform a NVRAM reset. Otherwise, you can't boot to that Secured Mojave. However, on the day that you do a NVRAM reset, you will lost the ability to boot to Legacy Mojave until you set SBM to disable.

I am not sure if we can backup the boot ROM after we install Secure Mojave. And then restore the BootROM to allow us to boot Secure Mojave after NVRAM reset. We haven't test this yet. However, even it works, I personally don't quite like this solution.

 

[JedNZ]

Is this something that RefindPlus could come to the party with? Create alternate OC packages: OC_SBMDEF (SBM=Default), OC_SBMDIS (SBM=Disable) etc?

 

[h9826790]

Is this something that RefindPlus could come to the party with? Create alternate OC packages: OC_SBMDEF (SBM=Default), OC_SBMDIS (SBM=Disable) etc?

Definitely, this may be the most applicable solution which already exist.

 

[KernkraftX360]

Can anyone confirm that they can run Monterrey 12.0.1 on their Mac Pro 2008 3,1 ? I seem to have a graphics/boot issue, whereby I can hear the chime, but just completely pure black screen using a ASUS HD5770

 

[Bmju]

Oh sorry, you meant within the OS? If so, I believe the information is not simply in a runtime accessible NVRAM variable, for instance. I think someone (@joevt ??) would have to write a small program to use UEFI runtime services to locate and call FwGetCurrent of OC_FIRMWARE_RUNTIME_PROTOCOL.

@Dayo - I looked into this some more: although we are talking about the OC runtime protocol, this service is installed by - and you can only detect whether it is installed using - the UEFI boot services. Meaning, unless some additional info is added, e.g. an NVRAM variable explicitly to say that it is running, then there is no standard way of detecting whether it is running.

So it's not just a matter of s/one writing a userspace tool, as I thought, it's a matter of OC wanting to expose this info (probably as a new ExposeSensitiveData flag).

 

[Dayo]

Monterrey 12.0.1 on Mac Pro 3,1 ? I seem to have a graphics/boot issue, whereby I can hear the chime, but just completely pure black screen using a ASUS HD5770

The HD 5770 is not supported on Monterey without the type of Rigid Patching done by the OCLP.

As it appears you are already using the OCLP, you might want to ask for support on one of the OCLP support channels instead. Links to their official support channels can be found on their GitHub project page.

More importantly, please stop asking the same question in multiple threads as you seem to often do.

 

[Bmju]

@cdf I also asked some more about the possibility of using one OC (e.g. on USB) to bless another OC (e.g. on ESP), and while it is definitely possible to make (e.g.) a new OC picker key combination which blesses and bypasses boot var routing, Vit is also worried that this is too easy for users to shoot themselves in the foot with, as you would then be blessing various entries (some of which only OC can see) for the Mac startup, so quite easy to bless the wrong thing and make the Mac not boot.

If you are wanting to bless say the ESP OC from a USB OC, could you make the USB OC have RequestBootVarRouting off, while the ESP OC has it switched on? (I feel you've probably explained to me why something like this doesn't quite do what you want, already, so sorry for asking again, if so...)

 

[cdf]

@cdf I also asked some more about the possibility of using one OC (e.g. on USB) to bless another OC (e.g. on ESP), and while it is definitely possible to make (e.g.) a new OC picker key combination which blesses and bypasses boot var routing, Vit is also worried that this is too easy for users to shoot themselves in the foot with, as you would then be blessing various entries (some of which only OC can see) for the Mac startup, so quite easy to bless the wrong thing and make the Mac not boot.

Certainly makes sense. Thanks for asking! (Perhaps the danger of natively blessing something else could be eliminated if the option would be restricted to only the OC Bootx64.efi. Then again, it would also be useful to natively bless natively bootable versions of macOS. Admittedly, all this is for a very special use case and probably not worth the implementation.)

If you are wanting to bless say the ESP OC from a USB OC, could you make the USB OC have RequestBootVarRouting off, while the ESP OC has it switched on? (I feel you've probably explained to me why something like this doesn't quite do what you want, already, so sorry for asking again, if so...)

No, that's correct. That's exactly how the strategy will be explained in the next iteration of the guide here.

 

[Dewdman42]

Is this something that RefindPlus could come to the party with? Create alternate OC packages: OC_SBMDEF (SBM=Default), OC_SBMDIS (SBM=Disable) etc?

This is what I do now for Catalina with one OC config setup for normal and one setup with VMM (for apple updates).

The one thing that is a little bit less then ideal is that you still have to manually choose which OC config to use (via RefindPlus), and then OC starts and you still have to then choose which volume to boot, manually. So that manual intervention means you can easily choose the wrong things and end up booting with the wrong OC config for a given boot volume.

I have not as of yet been able to figure out a good way to have a top level boot screen (RefindPlus) that is setup such that once I choose the OC config I want, the correct boot volume, among several, will be booted under OC.

OC's boot volume filters seem to be based on type, rather then by name or id.

Anyway, If anyone has any better suggestions about that, I am all ears.

 

[tiboug78]

Hello everyone,

I've recently updated my Mac Pro (mid 2010) from Mojave to Big Sur (11.6) using OCLP. Everything works fine and I gained new functionalities over Mojave. But I'm having trouble installing the last security update (11.6.1).
Before starting the update, I took care to rebuilt OpenCore which OCLP (0.3.1). Then I launched the update using the configuration panel. Once it's downloaded, the OS start the install process : the session is closed, the Apple logo and the progression bar appear but only for a few seconds. Instead of finishing the install, the computer reboot. I can see the Apple logo, then the Mac Boot Picker (the EFI boot is selected without my intervention), the the OpenCore Picker and Big Sur launch on his own. Once I'm logged-in I can see that I'm still on 11.6 and the configuration still suggest me to install 11.6.1.
I've done the process several times with the same result. Am I missing something to do the update ?
Thanks for your help.

 

[Dayo]

Am I missing something to do the update?

As it appears you are using the OCLP, you might want to ask for support on one of the OCLP support channels instead.
Links to their official support channels can be found on their GitHub project page.

 

[tiboug78]

As it appears you are using the OCLP, you might want to ask for support on one of the OCLP support channels instead.
Links to their official support channels can be found on their GitHub project page.

Thanks for the advice.

 

[I<3Coffee]

Thank you for your efforts!
The guide worked for Big Sur, after a few minor tweaks suggested. I have managed to install Monterey this morning through update.

It seems a little slower than before especially after logon page to desktop, not complaining since this is a 2009 machine! An amazing feat with its longevity - you guys take all the credits.

Appreciated.

 

[Charmandrigo]

A quick assistance here?
I recently updated my install to a better drive, moved also my opencore and blessed it to the new drive but I boot all the time to the bootpicker without the need to press Esc, any way to change to make it boot my default to my new macos partition and not the picker every time i boot it up?

 

[GSXB]

A quick assistance here?
I recently updated my install to a better drive, moved also my opencore and blessed it to the new drive but I boot all the time to the bootpicker without the need to press Esc, any way to change to make it boot my default to my new macos partition and not the picker every time i boot it up?

Open the config file with text edit and where it say showpicker true change to false

 

[Art Scrimshanker]

For disk labeling 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:

g5@G5s-Mac-Pro-2 BOOT % 
[/QUOTE]

[QUOTE="startergo, post: 29293857, member: 1145759"]

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

forgive me for banging on about an issue which has been resolved.....but, I've loaded disklabel in BOOT in my EFI folder, and have successfully executed this command:
/Volumes/EFI/EFI/BOOT/disklabel

However, I've run into problems trying to execute the following command in terminal:

sudo ./disklabel -e "YourLabel" .disk_label .disk_label_2x

I constantly get the following error messages, for example:

sudo: ./disklabel: command not known
or
sudo: /disklabel: command not known

Can you suggest what I am doing wrong?
Thank you
Art S

 

[Charmandrigo]

Open the config file with text edit and where it say showpicker true change to false

I already had it on false, so it's kind of odd..

 

[startergo]

Can you suggest what I am doing wrong?

You have provided the wrong path and terminal can't find disk label. Are you sure disklabel is in the path:
/Volumes/EFI/EFI/BOOT/disklabel?