Looks like you have an extra <dict> entry - 4th one down in your image. Did you confirm the config is Ok as indicated in Post #1?
Got a tip for us?
Let us know
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
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
I did some testing with ScanPolicy and Vault with the EFI package installed on an external USB drive. And it worked well.
But now as I moved the EFI package to an internal drive suddenly both features are not working anymore.
When the EFI is on the internal drive the NVMe PCI device shows only up with ScanPolicy 0 whereas with the EFI on the USB drive it showed up with ScanPolicy 0x10F0103 (17,760,515):
Why is the EFI behaving differently on an internal drive then on an external drive? Any ideas?
Same with the Vault. With the EFI on the external drive the signing was very easy and reliable. But as soon as I moved it to the internal drive the EFI didn't boot with the signing applied.
What could be wrong?
Thank you so much for your help.
But now as I moved the EFI package to an internal drive suddenly both features are not working anymore.
When the EFI is on the internal drive the NVMe PCI device shows only up with ScanPolicy 0 whereas with the EFI on the USB drive it showed up with ScanPolicy 0x10F0103 (17,760,515):
Why is the EFI behaving differently on an internal drive then on an external drive? Any ideas?
Same with the Vault. With the EFI on the external drive the signing was very easy and reliable. But as soon as I moved it to the internal drive the EFI didn't boot with the signing applied.
What could be wrong?
Thank you so much for your help.
First pic show the error output of config when I add the xml from post 1. when I remove xml for external drive I get the a okay. Ive copy pasted the XML in notepad with my PciRoot pasted in place of the generic one. every time I try something different I get the same error in a different line
Edit: you were right thanks for pointing that out!
Last edited:
As far as I can see nothing else is changed.
I made a few tests. Do you think I should report it as a bug? Maybe someone else would like to test it?
OK. Please try these in turn and report on outcome:
- 984835
- 987907
Because this is the only way to get the job done (at least true for the first few Bug Sur DP).
Thanks it now looks like this:
Edit: I got it, Thanks for your Help!
Last edited:
h9826790-
Martin what will happen if I use your 0.6.2 package to update my 0.6.1 OC? I have a GTX 680 mac edition GPU- I followed post 1 for my OC install that I put on a NVMe PCI Blade (Not my Catalina start drive) working fine. Will I have a problem if I use your package since my GPU has mac boot screen but I believe can’t be accelerated, no UEFI GOP. Also have a windows boot camp on separate SSD in bay 4 but with Legacy boot, don’t want to change to UEFI boot- Thanks for any information you can help me with!!
Martin what will happen if I use your 0.6.2 package to update my 0.6.1 OC? I have a GTX 680 mac edition GPU- I followed post 1 for my OC install that I put on a NVMe PCI Blade (Not my Catalina start drive) working fine. Will I have a problem if I use your package since my GPU has mac boot screen but I believe can’t be accelerated, no UEFI GOP. Also have a windows boot camp on separate SSD in bay 4 but with Legacy boot, don’t want to change to UEFI boot- Thanks for any information you can help me with!!
You should able to use my pre configured 0.6.2 package. Most functions won't work of course. But there should be no compatibility issue.
For 680 Mac Edition card, that's safe to try anyway. If anything goes wrong, just hold option to boot.
If I have Mac Pro 3,1, the final official supported OS is El Capitan.
Does it mean we can't use open core in Mac Pro 3,1 machine?
Does it mean we can't use open core in Mac Pro 3,1 machine?
You can follow Post 1 with some amendments to implement on your 3,1.
You can also try this alternative implementation path.
Started out as my 3,1 focused process before widening the scope. I use it with my DosDude Patched Mojave Instance on my 3,1.
Last edited:
@vit9696 - I don't know if you have a moment to answer this at all, or if anyone else can. If so, many thanks.
I am working on a mini bootable efi. I've got it switching to console output using ConsoleControlProtocol and successfully doing some input and output. It works for stand-alone boot and as an OpenCore tool. However, when I install it as an OpenCore tool, I'm struggling to get it to return control to OpenCore after exiting. It just hangs. As far as I can see, *any* .efi file which finishes with
I am working on a mini bootable efi. I've got it switching to console output using ConsoleControlProtocol and successfully doing some input and output. It works for stand-alone boot and as an OpenCore tool. However, when I install it as an OpenCore tool, I'm struggling to get it to return control to OpenCore after exiting. It just hangs. As far as I can see, *any* .efi file which finishes with
return EFI_SUCCESS; hangs on returning to OpenCore (and also hangs on returning to UEFI Shell if run from within that). Is this an Apple specific thing, like the conOut problem? It seems to apply to even the very simplest "Hello, World!" example code (which runs fine, but hangs on exit). Is there any trick to how to return, to allow OpenCore and/or UEFI Shell to pick up again after an efi completes?
That is a restriction on the UEFI shell open core uses. You may want to try older shells like the refit shell. Most of the EFI tools requiring text mode do not work in the opencore shell.
Hang on, just to try to understand - are you saying that OC itself is built out of a highly modified UEFI Shell? If so, that makes sense, if not, I'm not following yet, sorry.
Please take a look here:
Provide a way to run tools and custom entries in text mode · Issue #1081 · acidanthera/bugtracker
Some tools may require to be launched in text mode to be able to print any text onscreen. This is because: OpenCore implements ConsoleControl protocol, which hides any printed text in graphics mode...
github.com
Shell bugs on different systems · Issue #364 · acidanthera/bugtracker
There are multiple shell issues including, some of which have dedicated bugreports, some of which have patches upstreamed, or just nothing. This issue will be the parent issue for all separate ones...
github.com
This is missing a bit of nuance and anything requiring basic console text will work in OpenShell.
OpenCore does not provide the environment needed for a shell to use text mode display (everything is graphical, including the text bootpicker) but once you boot into OpenShell, ConsoleText is made available by OpenShell itself as part of its start up process (This is one modification to the standard shell made by the devs). You can then run other tools from OpenShell without issue as long as they do not leverage SimpleInputEx actions if on a Classic MacPro (Discussed later).
If you replace OpenShell with Refit's shell, or any other standard shell, and run this in OpenCore, you will get a blank screen as such shells expect to be running in an environment that already has ConsoleText made available. Refit, or derivatives such as Refind and RefindPlus, provide text mode for such shells when you trigger the shell. OpenShell, as said, activates this by itself.
On the opposite, if you take OpenShell and run it from Refit, Refind or RefindPlus, you will get the same outcomes as with Refit's shell. The environment will have ConsoleText but OpenShell does not need it as it can activate this itself.
Just to add the missing nuance in that there is nothing wrong with OpenShell and it is actually superior to Refit's Shell. The fact that some things cannot be done on it within the OpenCore environment is down to a separate issue ... with our venerable Classic MacPros.
Basically, OpenShell is a UEFI Shell which requires SimpleInputEx for some actions. SimpleInputEx is however not available on Classic MacPros and trying to use any such command will result in an error message (Without crashing/hanging your computer - This is another modification made by the devs as other shells would cause a crash). The OpenCore devs have decided that trying to provide SimpleInputEx for Classic MacPros is too much effort BTW.
Refit's shell is an EFI Shell which needs the older SimpleInput as opposed to SimpleInputEx. SimpleInput is available on Classic MacPros. You can therefore launch Refit's Shell from a Mac Bootpicker, where the older SimpleInput has been activated, and use it to its full abilities on a Classic MacPro. You just need to bear in mind that these full abilities exclude certain capabilities requiring SimpleInputEx.
PS: The text mode environment does not work on Classic MacPros when using vanilla rEFInd (as at v0.12.0) if not using a Mac bootscreen capable GPU and you need RefindPlus to get this.
Last edited:
Thank you. I tried both numbers without success. The NVMe is not showing up. The NVMe Adapter is an Angelbird Wings with a Samsung SSD 960 EVO.
I tried it also with the external USB drive again with the same results. So the external, internal drive swop was not the cause for the problem. I remembered that I reformatted the NVMe as APFS after my first successful tests. Maybe that is the reason...? But what could brake the scanning with reformatting the drive?
The Vault problem is solved. I figured out that there was a problem with the Xcode command line tool.
Right, but the only way to use the full abilities of the refit's shell is if you launch it from the original Mac Bootlpicker or any other loader like rEFInd, rEFIt or OC and start that old EFI 1.1 shell in such a manner afterwards. This implies using an EFI video card with either OEM EFI loader or the modified MVC vbios. I realize people are going to get confused now but it is hard to explain it in simpler words.
That was just testing a hunch. Thanks.
Reformatting shouldn't have such an outcome but what was it before out of curiosity?
Also, was the OpenCore version when it was showing up the same as it is now?
Correct apart from that it would not work when launched from OC.
OEM Mac Bootpicker and rEFIt variants would provide the required text mode environment for the shell which OC would not as OpenShell provides this by itself if not available.
Here are the details how to use multi configuration boot:
MyBootMgr: RefindPlus|OpenCore
This is a guide to using OpenCore and RefindPlus, to multiboot Classic MacPros (3,1 to 5,1) as well as equivalent Xserve (2,1 and 3,1). It involves booting Mac OS from one or more OpenCore instances chain-loaded from RefindPlus and booting other OS types directly from RefindPlus. The guide is...
forums.macrumors.com