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.
paalb said:
Try this:
Open Terminal.
Write: cd
Add space behind.
Drag the folder from Finder that contains config.plist into terminal.
Hit Return or Enter.

Now you are in the right place and can run the plutil command. I recommend copy/pasting it from the guide.
Click to expand...
Thanks for the answer. but the problem was that the file wasn't in the right folder (Home Folder). It was may Failure. But I got to other problems:
1. The boot picker isn't visible (I didn't disabled it). I can change wich volume I want to boot with the arrow keys and enter but I can't see it.
2. due to the invisible boot picker I can't see if the USB for Windows is there to pick and Boot it.

If you have any Ideas it would be awesome!
 
startergo said:
View attachment 978630
No VMM only firmware features and firmware mask from iMacPro1,1 (and board-id)
Click to expand...
Thanks for the confirmation.

I only tested with a very early Big Sur beta full installer which stored in my backup drive, that doesn't allow me to install Big Sur (the usual BIErrorDomain error 4). Hopefully Apple keep the mechanism as per the last beta, so that one OpenCore config will be good enough for both daily use, and macOS update.
 
  • Like
Reactions: PeterHolbrook
Hey all looking for a quick bit of help.

A few weeks back I followed the guide and got OC, Catalina and everything in the guide completed up to but not including installing Windows. The guide was great and I was able to follow along fairly easily.

I have decided that I'm going to tackle the Windows installation next, so I read through that section of the guide and for the most part it looks straight forward and either easy to follow or a rehash of what I did before. There is one small part of the guide though that has me a little confused... maybe it will become very obvious as I'm doing it, but rather than finding mid installation that it still doesn't make sense and then reaching out for help I thought id be proactive.

Prepare the installer

Use the actual volumes names in the following step:
  • Enter: rsync -r /Volumes/CCCOMA_X64/ /Volumes/USB
Let the task complete.
Click to expand...

what does the above mean by replace with actual volumes names?

  • Is this like mounting the EFI volume step, where the example used for the location was "diskAs1" but for me it was slightly different so I replaced it. So with the instruction above I would replace "CCCOMA_X64" and "USB" with the equivalent names on my system?
  • Is this something else, but like the rest of the guide once I reach that step and I am knee deep in this installation it will be blindingly obvious what that instruction refers too?
As I said the rest of the guide up to this point was easy to follow, this was the one step reading ahead of time that seemed a bit nebulous but that could be because I am reading ahead of time, if so just tell me :)

Thanks in advance.
 
cdf said:
I believe that the 0x0 is normal in the debug log. The log indicates that 3840x2160 has been set.


How are you connecting the display? For testing, you might want to connect another display along with the UltraFine (this may help getting an image out to the UltraFine).
Click to expand...
When I have both displays connected I continue to get no output from OpenCore on both of them - having the Ultrafine plugged in interferes with my other monitor. I only get output with the LG Ultrafine totally disconnected. 🤔
 
RottenCotton said:
Is this like mounting the EFI volume step, where the example used for the location was "diskAs1" but for me it was slightly different so I replaced it. So with the instruction above I would replace "CCCOMA_X64" and "USB" with the equivalent names on my system?
Click to expand...

That's right.
 
h9826790 said:
Hopefully Apple keep the mechanism as per the last beta, so that one OpenCore config will be good enough for both daily use, and macOS update.
Click to expand...
As @cdf mentioned Mojave-->Catalina still needs VMM. After unenrolling from the beta seed:
1604425297504.png
 
jackluke said:
Doesn't worked, I mean booting first opencore, then selecting refind_x64.efi (added to Tools) has a similar behavior of Bootkicker .
Click to expand...
refind relies on the config file for booting and it has a folder structure like OC it is not a standalone tool. If you have refind installed on another EFI drive then OC should list it as a boot option. But what would be the purpose of such chainloading?
 
  • Like
Reactions: jackluke
startergo said:
refind relies on the config file for booting and it has a folder structure like OC it is not a standalone tool. If you have refind installed on another EFI drive then OC should list it as a boot option. But what would be the purpose of such chainloading?
Click to expand...

It's for BigSur on some unsupported Mac (since are applied many kext patches) I need to apply some opencore fixes, then continue booting through apple startup manager or refind because only from there can select as bootable APFS either Preboot or System, while from opencore only Preboot is available For APFS drives and for patched BootKernelExtensions.kc won't work properly, while apple startup or refind work with patched BKE .

If you make this booting route through refind, select opencore, then from opencore select again refind it should work, but if Bootkicker.efi works after opencore would be very useful .
 
Last edited:
Messages app - not working with Big Sur ? macPro 5,1

I updated to 0.61 OC with BS beta 10. I then updated OTA to 11.0.1.

On the same machine booting through the same OC 0.6.1 the Messages app works perfectly in both Mojave and Catalina.

When booted in to Big Sur through OC 0.6.1 the app opens for a second or two and then asks for my Apple Sign in. I do the Sign in then it loops to a repeat of the Sign in again and again and again .... ad infinitum!

The 'Preferences' are greyed-out on the mac's Messages app works on my iPhone and my iPad pro.

In Big Sur all the other iCloud services work fine.

As Ive go this version of Big Sur configured just about the way I want it I don't want to wipe the SSD and start again.

Any suggestions?
 
David403 said:
Messages app - not working with Big Sur ? macPro 5,1

I updated to 0.61 OC with BS beta 10. I then updated OTA to 11.0.1.

On the same machine booting through the same OC 0.6.1 the Messages app works perfectly in both Mojave and Catalina.

When booted in to Big Sur through OC 0.6.1 the app opens for a second or two and then asks for my Apple Sign in. I do the Sign in then it loops to a repeat of the Sign in again and again and again .... ad infinitum!

The 'Preferences' are greyed-out on the mac's Messages app works on my iPhone and my iPad pro.

In Big Sur all the other iCloud services work fine.

As Ive go this version of Big Sur configured just about the way I want it I don't want to wipe the SSD and start again.

Any suggestions?
Click to expand...
You don't change any serial numbers, right?
 
startergo said:
I doubt it will work for your purposes, but you can test it. Bootkicker will definitely not work like that (tested)
Click to expand...

I guess copying to an EFI volume in BOOT folder the refind bootx64.efi then OC folder (with its config) and refind folder (with its config), so on refind menu can detect opencore, select opencore.efi , then I should reselect refind (or even BootKicker.efi should work without green screen, because the Graphic output protocol used is from refind bootx64.efi) but this implies HideSelf No (that worked till OC 0.5.8), which newer opencore feature use to unhide the internal EFI on opencore menu?
 
Last edited:
It appears that the Big Sur installer bypasses some or all previous OpenCore attempts (before OC 0.6.4) to thwart firmware updates. Given the seriousness of this situation, can anyone comment whether some hardened version of spoofing by itself solves the issue or if we should wait until OC 0.6.4 is released (in December?), or if there is some workaround to the issue? In the worst case scenario, I'm thinking about the possibility of, before booting to the first step of the Big Sur installer, we could perhaps boot to something like High Sierra and then mount the EFI volume and, inside the /EFI folder, delete the /APPLE subfolder. Once that is done (and the Trash is emptied) I suppose that booting back to the initial step of the Big Sur installer would work with no ROM-bricking issues.
 
Last edited:
PeterHolbrook said:
. Given the seriousness of this situation, can anyone comment whether some hardened version of spoofing by itself solves the issue
Click to expand...
First lets elaborate on this. Are you getting attempts to upgrade the firmware?
Do you have this setting:
Code: 
</data>
                <key>run-efi-updater</key>
                <string>No</string>
If that did not work for you can you try adding this (if you are using iMac Pro board-id):
Code: 
<key>BIOSVersion</key>
            <string>1554.40.41.0.0</string>
You can get latest biosversion from here

Found this
github.com

run-efi-updater flag no longer works in macOS 11, Big Sur · Issue #1255 · acidanthera/bugtracker

With macOS Big Sur, it seems that even though the NVRAM variable is set macOS will still bless the firmware update during both install and update processes: 15:835 00:005 OCB: Perform boot EFI to d...
github.com github.com
Interestingly, vbiosupdater is still broken and causes crashes when ATY,Rom# is a string instead of data OR has unexpected format. To fix that RX 5xxx owners should inject something like 123-456-789 via DeviceProperties. Last mentioned in #901.
Click to expand...
 
Last edited:
PeterHolbrook said:
some workaround to the issue?
Click to expand...
Build OpenCore yourself as at the commit that addresses the issue and just use this until 0.6.4 is released.
The config file is still at the same state almost the same as it was at the 0.6.3 release so just a matter of replacing the efi files and adding the missing key.

startergo said:
Do you have this setting:
Code: 
</data>
                <key>run-efi-updater</key>
                <string>No</string>
Click to expand...
See: https://github.com/acidanthera/bugtracker/issues/1255
 
Last edited:
  • Like
Reactions: PeterHolbrook
startergo said:
First lets elaborate on this. Are you getting attempts to upgrade the firmware?
Do you have this setting:
Code: 
</data>
                <key>run-efi-updater</key>
                <string>No</string>
If that did not work for you can you try adding this (if you are using iMac Pro board-id):
Code: 
<key>BIOSVersion</key>
            <string>1554.40.41.0.0</string>
You can get latest biosversion from here
Click to expand...
I am also thinking if we should spoof the BIOS version as well.

This should be very cosmetic under most situation. 144.0.0.0.0 or 1554.40.41.0.0 doesn't really matter for normal daily use. But keep that at the latest firmware (or even some numbers that above the current version e.g. 1999.0.0.0.0) which match the board ID should able to avoid macOS installer / updater attempt to update the firmware.

Even OpenCore should protect the BootROM, but this may able to serve as another fail safe protection,
 
Hi everybody, I have a flashed 4,1 in 5,1 with dosdude catalina 10.15.5 and rx580. What are the steps to go OpenCore ?
 
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