MP 1,1-5,1 Unexpected OpenCore behavior

[imrazor]

Recently I added a PCIe NVME card to my MacPro 5,1. The drive I chose to use with it was a WD Black 1TB SSD (model# SN750, which I believe is listed as compatible per the sticky thread on PCIe NVME.) The drive had an existing install of Linux, which I didn't think would be a problem. My Mac Pro has a Mojave install (2TB spinning rust), Monterey (OWC SATA III PCIe card w/ OWC 500GB SSD) and Windows 10 (Samsung 512GB SATA III SSD attached to optical drive bay SATA.) I still need to figure out the correct method to 'clone' my Monterey install to the NVME drive.

While I was in Windows, I attempted to go to the Boot Camp system tray icon and clicked on "Reboot into Mac OS X." Instead of rebooting into MacOS, I just got a black screen. I then removed the NVME drive, thinking that the system would then just boot into MacOS or Windows. It did not; I still just got a black screen. I remembered that CMD-ALT-P-R was supposed to clear the NVRAM and allow for a normal boot, I tried that three times thinking I would get booted into Mojave (since that is natively supported) or maybe Windows.

Instead I got dumped into Monterey. This is far preferable to a black screen, but I'm still curious why CMD-ALT-P-R didn't clear the OpenCore boot parameters from NVRAM.

To sum up, that leaves me with the following questions:

1) Why doesn't CMD-ALT-P-R purge the OpenCore boot parameters from NVRAM?
2) Why did "Reboot from Mac OS X" fail?

 

[sfalatko]

Recently I added a PCIe NVME card to my MacPro 5,1. The drive I chose to use with it was a WD Black 1TB SSD (model# SN750, which I believe is listed as compatible per the sticky thread on PCIe NVME.) The drive had an existing install of Linux, which I didn't think would be a problem. My Mac Pro has a Mojave install (2TB spinning rust), Monterey (OWC SATA III PCIe card w/ OWC 500GB SSD) and Windows 10 (Samsung 512GB SATA III SSD attached to optical drive bay SATA.) I still need to figure out the correct method to 'clone' my Monterey install to the NVME drive.

While I was in Windows, I attempted to go to the Boot Camp system tray icon and clicked on "Reboot into Mac OS X." Instead of rebooting into MacOS, I just got a black screen. I then removed the NVME drive, thinking that the system would then just boot into MacOS or Windows. It did not; I still just got a black screen. I remembered that CMD-ALT-P-R was supposed to clear the NVRAM and allow for a normal boot, I tried that three times thinking I would get booted into Mojave (since that is natively supported) or maybe Windows.

Instead I got dumped into Monterey. This is far preferable to a black screen, but I'm still curious why CMD-ALT-P-R didn't clear the OpenCore boot parameters from NVRAM.

To sum up, that leaves me with the following questions:

1) Why doesn't CMD-ALT-P-R purge the OpenCore boot parameters from NVRAM?
2) Why did "Reboot from Mac OS X" fail?

Your startup disk is probably set to Monterey rather than Mojave. You can change that if you want to in the Startup Disk system preferance pane.

 

[joevt]

To clone my Monterey, I used Migration Assistant. Disk Utilities.app wouldn't do it with the Recovery option.

Did you boot Windows from OpenCore so that the NVRAM boot variables would be protected? If you had a GPU with boot screen, you could boot Mojave using the Apple Startup Manager (hold option key at boot) to bypass OpenCore and find out what the Windows Boot Camp control panel did to your NVRAM (or better yet, boot RefindPlus, enter the EFI Shell and use dmpstore to dump all nvram variables).

Another way to dump all nvram variables is to dump the ROM and use UEFITool to examine the NVRAM area. This method should bypass OpenCore's NVRAM protections so you can be sure that it's accurate? I would use UEFIExtract to dump the contents to files so a diff can be used.

If CMD-ALT-P-R did clear the boot parameters, then the only way Monterey would boot is if the Apple Startup Manager booted OpenCore as the default. I don't know what the default boot order is but I would guess from this result that a bootx64.efi in an EFI partition can take precedence over a blessed efi file in an HFS+ or APFS volume (I assume your Mac Pro has apfs driver in firmware?).