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
Apparently I am also the lucky bastard that owns a GPU that lacks the necessary acpi-path property for adding other properties. Is there a list which GPU's are lacking this? The above solution works for me, so that's nice
FWIW my GPU is an AMD Radeon RX5700 reference card.
Cheers Jay
This may be useful
Thanks for the info. There's no list, but it seems that the Navi series is particularly affected.Apparently I am also the lucky bastard that owns a GPU that lacks the necessary acpi-path property for adding other properties. Is there a list which GPU's are lacking this? The above solution works for me, so that's nice
FWIW my GPU is an AMD Radeon RX5700 reference card.
Cheers Jay
@cdf - well I finally was able to swap out the GPU for my flashed GTX680 and confirmed both CDRWs that I burned are not bootable - they do not show up in the stock boot picker. This was a reburn of my working 0.7.7 files and a new 0.7.8 set with my unmodified config.plist.
I am stumped - any thoughts? Is my drive going bonkers?
Try ruling out your Mac's firmware by doing a deep NVRAM reset. If the CD still doesn't boot, then either something is off with its creation or the media itself is problematic.
I want to indicate in my dumper if
LauncherOption:Full
is set, I am sure there is a nvram variable set but need more details.
Background is that it is not too easy to get ridd of LauncherOption beside of a full nvram reset.
So it would be nice to get the information: check for ID xxxx-yyyy-zzzzz
LauncherOption:Full
is set, I am sure there is a nvram variable set but need more details.
Background is that it is not too easy to get ridd of LauncherOption beside of a full nvram reset.
So it would be nice to get the information: check for ID xxxx-yyyy-zzzzz
I'm sure the card was working before so i don't think its mis-installed. Since Bluetooth is still working fine i also don't think the card is faulty. Its the same card, right? But yeah even if i boot into Mojave without OC it says no hardware installed so maybe just the wifi part of the card broke? not sure if thats possible. I also installed some AirPort drivers when i was trying to get Wifi to work in Windows maybe that ****ed up something?
I tried your EFI config but that just made everything even worse
when i tried booting my Monterey install it would show some Error with the NVMEcontroller. I'm using a Sonnet 4x4 wich works absolutely fine with Martins package. Booting into Mojave through OC gave an error message that this OS isn't supported...After PRAM reset i was able to blindly boot into recovery, disable SIP, reboot into Mojave, install Martins package again and bless the OC EFI. Now everything is back to "normal" meaning no Wifi, no Standby and Monterey freezing + auto rebooting after ~10min.
Something else I noticed is that when I try to shutdown the system will shutdown but the MacPros fan will still be running and seems to be stuck somehow. This state is similar to when the Mac won't wake up from standby. no video output, no power LED on the MP. Can only press hold power button until it properly shuts down then reboot
When you are spoofing MacPro7,1, Mojave is unsupported - Catalina 10.15.1 is the first macOS release that supports 2019 Mac Pro.
You need to add -no_compat_check to your boot-args.
yes thats why martins package will load mojave from the bootpicker. makes sense. thank you!
there is still something very wrong with my install thou since i am still experiencing system freezing in monterey.
i tried to solve the issue with a software update but i can't load/install it within the timeframe before the mac will freeze haha
A word of caution, when installed open core Installed monterey following martins vid/steps to change the config. Did all the steps got an error. rebooted. mojave showed up, yet my disk name changed to "[hd/name] - Data." Now everytime i try to boot into recovery. Monterey recovery shows up, asking me to turn on a bluetooth mouse which i don't have nor the updated card, i broke the line thinking I'll never use wireless again. (why would you/I want latency anyways on a desktop and batteries to change?) no wired keyboard or mouse works in this recovery. everything is usb. So i can no longer boot into recovery or turn sip on/off. Data disk though? why the disk partition name change? I have no recovery?
I guess I can answer to myself
it seems it's the presence of OpenCore.efi at first in BootOrder
any complains?
Yes, this is true if LauncherOption=Full, but I wonder if it might not also be true otherwise. For instance:
- Does disabling LauncherOption after booting with it enabled change the Boot0001 entry?
- Can Boot0001 also be set to .../EFI/OC/OpenCore.efi by blessing .../EFI/OC/OpenCore.efi manually?
I don't see anywhere in the code where information about LauncherOption is added to nvram but the OpenCore code is hard to follow so I could be missing something.
Doesn't the LauncherOption just change the format of the path used for the launcher (between full path and not full path and system - whatever that means)? In that case you would have to examine the path to determine the format. But the format of the path won't tell you why it has that format - whether it was because of the LauncherOption config option or something else.
I don't know why you want to show the LauncherOption anyway. You can just show the boot vars and let the user determine what's going on.
First thing your dumper should do is interpret the nvram variables like UEFIExtract does so we're not looking at just hex. It is not clear what variables you are looking at and it's hard to make a comparison without a dump of all the variables.
https://github.com/LongSoft/UEFITool/releases
You could make a modified version of UEFIExtract to just output the parts you want into a single file.
Anything that deals with nvram variables could be modified by options in OpenCore so you can't trust the
nvram command or related commands such as bless. Which is where your romdump comes in handy since that bypasses the OpenCore's nvram modifications.Check the overrides that OpenCore makes to the UEFI GetVariable function. Maybe they leave a back door to get unmodified values. I looked at it for a second. Then averted my eyes before the abyss could stare back at me... so I don't know what is available to the user. Do they have documentation regarding how the nvram stuff works? The config documentation is not sufficient for allowing one to wrap their head around this.
Without a backdoor, my dumpallbootvars command is kind of useless except to show that OpenCore is protecting the boot vars. On my MacPro3,1, I get this (I don't know why it decided to have two 0080 in the BootOrder):
Code:
dumpallbootvars
BootCurrent:
BootNext:
Timeout: 5s
BootOrder: Boot0080 Boot0080
Boot0080 1 "Monterey 12.1 [P]" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(6,GPT,A23A5288-C60D-4FFE-A19E-3B375B67E02F,0xE8CFE68,0x1FA7CA20)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,99C8A576461A15418DD2EF7D52229657)/\288A096A-0C7C-3F74-A010-76E8E3E839EF\System\Library\CoreServices\boot.efi"
Boot0080 1 "Monterey 12.1 [P]" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(6,GPT,A23A5288-C60D-4FFE-A19E-3B375B67E02F,0xE8CFE68,0x1FA7CA20)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,99C8A576461A15418DD2EF7D52229657)/\288A096A-0C7C-3F74-A010-76E8E3E839EF\System\Library\CoreServices\boot.efi"
#Searching: Boot0000(1), Boot007F(-1), Boot0081(1)
Boot0081 1 "Mac OS X" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(1,GPT,D05988FB-BCA7-43AF-9462-5D07E83D57D7,0x28,0x64000)/\EFI\APPLE\UPDATERS\MULTIUPDATER\MultiUpdater.efi" "DpUtil.efi (-o -g -S -f efi-apple-payload1-data -v 537 efi-apple-payload2-data ) "
000000ca: 440070005500740069006c002e00650066006900200028002d006f0020002d00670020002d00530020002d00660020006500660069002d006100700070006c0065002d007000610079006c006f006100640031002d00640061007400610020002d007600200035003300370020006500660069002d006100700070006c0065002d007000610079006c006f006100640032002d0064006100740061002000290020000000
000000ca: D.p.U.t.i.l...e.f.i. .(.-.o. .-.g. .-.S. .-.f. .e.f.i.-.a.p.p.l.e.-.p.a.y.l.o.a.d.1.-.d.a.t.a. .-.v. .5.3.7. .e.f.i.-.a.p.p.l.e.-.p.a.y.l.o.a.d.2.-.d.a.t.a. .). ...
#Searching: BootFFFF(-1)
DriverOrder: Driver0080
Driver0080 1 "apfs.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\apfs.efi"
#Searching: Driver0000(1), Driver007F(-1), Driver0081(1)
Driver0081 1 "FakeUEFI2.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\FakeUEFI2.efi"
Driver0082 1 "ReloadPCIRom.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\ReloadPCIRom.efi"
Driver0083 1 "UgaOnGop.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\UgaOnGop.efi"
Driver0084 1 "CrScreenshotDxe.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\CrScreenshotDxe.efi"
Driver0085 1 "NvmExpressDxe.efi" "PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,97CD1709-FE99-4E1F-BF41-75D379A46CC4,0x28,0x64000)/\drivers\NvmExpressDxe.efi"
#Searching: DriverFFFF(-1)Of course my MacPro3,1 can't boot Monterey directly so the above output means OpenCore has hidden the real boot vars (which should be pointing to OpenCore). OpenCore doesn't hide the Driver boot vars.
What your dumper could do is show the real boot vars alongside the faked boot vars.
thanks a lot, I maybe have a simple solution
check the presence of EFI/OC/OpenCore.efi plus the presence of Boot0001 in the nvram part of the dump.
I scanned 200 plus firmware dumps and I don't got false positives. Even if I manually bless the file EFI/OC/OpenCore.efi it is Boot0080, not Boot0001
I need it simple because I want to detect things inside an OpenCore booted System and also directly from a rom dump file.
Last edited:
Question for the Group:
I have Monterey on position #2 of a dual NVMe adapter (position #1 is a non-bootable scratch drive). Mojave is on an SSD in SATA1, Win10 on an SSD in SATA2 (SATA3-4 are unpopulated). My OC EFI is on a USB with a full Monterey config (i.e., hybridization, NVRAM update, SecureBoot=default, etc.). I have a Mojave-only config, and when I want to boot Mojave I’ll open the EFI & rename the configs. OC default boots to Monterey.
If I pull the OC USB (e.g., OC is not loaded) will the cMP default boot to Mojave?
I was wondering with this setup whether switching configs is necessary? I rarely boot Mojave, but sometimes need to for testing & maintenance.
I have Monterey on position #2 of a dual NVMe adapter (position #1 is a non-bootable scratch drive). Mojave is on an SSD in SATA1, Win10 on an SSD in SATA2 (SATA3-4 are unpopulated). My OC EFI is on a USB with a full Monterey config (i.e., hybridization, NVRAM update, SecureBoot=default, etc.). I have a Mojave-only config, and when I want to boot Mojave I’ll open the EFI & rename the configs. OC default boots to Monterey.
If I pull the OC USB (e.g., OC is not loaded) will the cMP default boot to Mojave?
I was wondering with this setup whether switching configs is necessary? I rarely boot Mojave, but sometimes need to for testing & maintenance.