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

[octoviaa]

Been around the houses a bit on this tonight. I've found that it's very easy to wind up in a position where Windows boots itself in EFI mode with no indication that it's doing so; no blue Windows logo or spinner shown, just suddenly landing on the login screen. By that point the damage is done. I booted to my Mojave fallback to find the dreaded certificates appearing.
View attachment 894668
That's no bueno. A reflashed ROM from backup and all is well again, but it's too easy to fall foul of this.

So, to overcome the issue of major Windows upgrades failing (potentially due to the multiple drives, which is what I was setting out to test) and reduce the likelihood of ROM corruption, might it be possible to install OC to the EFI partition of the Windows disk? I've tried, but the EFI partition contains Microsoft's gubbins and replacing BOOTx64.efi and adding the OC directory (and setting HideSelf to false) only results in repeatedly landing back at the picker when choosing 'BOOTCAMP Windows'.

How about you copied the BOOTx64.efi to other folder then use blessOverride for the BOOTx64.efi which has been moved to different folder?

 

[roobarb!]

How about you copied the BOOTx64.efi to other folder then use blessOverride for the BOOTx64.efi which has been moved to different folder?

Ahh.

Currently you can either put OpenCore's BOOTx64.efi to some other place and bless it (unsure how well it works). Or remove Windows' BOOTx64.efi and add BlessOverride with \EFI\Microsoft\Boot\bootmgfw.efi (you will also have to disable HideSelf). The latter is covered in the configuration manual "12.1 Windows support".

Ahh!

Okay, this is what I need. Not near the machine right now, but I'll try this out tonight.

Making the rash assumption that Windows won't try to replace OC's BOOTx64.efi during an update, this could be a great solution. If it does, I could always rename it BOOTx64oc.efi and then see if it persists.

 

[h9826790]

Ahh.


Ahh!

Okay, this is what I need. Not near the machine right now, but I'll try this out tonight.

Making the rash assumption that Windows won't try to replace OC's BOOTx64.efi during an update, this could be a great solution. If it does, I could always rename it BOOTx64oc.efi and then see if it persists.

Better put the OC BOOTx64 to another location, but not the Windows BOOTx64.

As discuss before, it's possible to manually bless the OC BOOTx64 in another location. Even though don't know how well it work, but at least theoretically possible.

Also, Windows update should not replace that OC BOOTx64 in another path.

 

[roobarb!]

Better put the OC BOOTx64 to another location, but not the Windows BOOTx64.

Yeah, the trick being that I need it to be the only drive in the system when major Windows updates are running (so that they work) and I want to know I'll not be hit with a corrupt ROM due to those certificates. By other location, do you mean another location on the Windows drive, or a different physical drive?

Regardless, I'll have a play tonight.

It would be nice to know why the EFI install has issues with updates and the legacy technique doesn't.

 

[startergo]

Yeah, the trick being that I need it to be the only drive in the system when major Windows updates are running

That does not mean you can't use USB's. That does not count towards "multiple drives". So You can have OC on that USB.

 

[h9826790]

Yeah, the trick being that I need it to be the only drive in the system when major Windows updates are running (so that they work) and I want to know I'll not be hit with a corrupt ROM due to those certificates. By other location, do you mean another location on the Windows drive, or a different physical drive?

Regardless, I'll have a play tonight.

It would be nice to know why the EFI install has issues with updates and the legacy technique doesn't.

I mean another location in the EFI partition. e.g. make a folder OCBOOT, and put the BOOTx64 at there, and bless that path manually.

Anyway, if can't get rid of this "update via OC" issue.

I will prefer to

1) Backup the clean ROM (if you don't have that)
2) Do the Windows update without OC (let it write the cert, only one cert won't cause any issue anyway)
3) flash the clean ROM back in after Windows update

Not the ideal solution, but should work at very low risk.
[automerge]1581937759[/automerge]

That does not mean you can't use USB's. That does not count towards "multiple drives". So You can have OC on that USB.

I agree, but I think he doesn't have a bootable USB thumb drive on hand.

I have 4 USB thumb drives in my drawer, only the newest one can boot on cMP. The remaining 3 very old drives can't boot.

 

[roobarb!]

That does not mean you can't use USB's. That does not count towards "multiple drives". So You can have OC on that USB.

I've had limited success with the USB drives I have lying around, otherwise yes, I'd totally go for that.

I find that they often work on reboots, but startups from cold are hit and miss. That's why I ended up reflashing my ROM again yesterday. Windows was the only drive installed + USB drive didn't seem to kick in + machine booted Windows EFI without OC = corrupt ROM. I wasn't prepared to let it run the multiple reboots for an upgrade without the protection from OC.

 

[tsialex]

I mean another location in the EFI partition. e.g. make a folder OCBOOT, and put the BOOTx64 at there, and bless that path manually.

Anyway, if can't get rid of this "update via OC" issue.

I will prefer to

1) Backup the clean ROM (if you don't have that)
2) Do the Windows update without OC (let it write the cert, only one cert won't cause any issue anyway)
3) flash the clean ROM back in after Windows update

Not the ideal solution, but should work at very low risk.

You are starting with a premise that he have a clean BootROM, most people already have problematic BootROMs, some with 25 or more MemoryConfig entries, all sort of other entries and with serious fragmentation after 10 years. Without a clean NVRAM from the start, nothing is low risk.

 

[roobarb!]

I mean another location in the EFI partition. e.g. make a folder OCBOOT, and put the BOOTx64 at there, and bless that path manually.

Great, I shall try.

I have 4 USB thumb drives in my drawer, only the newest one can boot on cMP. The remaining 3 very old drive can't boot.

What manufacturer is the one that works? My newest are tiny little SanDisk Ultra Fit models (two new, one a few years old) and no reliable luck there.

 

[h9826790]

Great, I shall try.

What manufacturer is the one that works? My newest are tiny little SanDisk Ultra Fit models (two new, one a few years old) and no reliable luck there.

Kingston DataTraveler 100 G3 32GB

 

[lowendlinux]

Is there any reason I can't take the working opencore drive and boot it in my hackintosh?

 

[h9826790]

Is there any reason I can't take the working opencore drive and boot it in my hackintosh?

The required kext, driver, config should be quite different for 5,1 and a Hackintosh.

 

[roobarb!]

You are starting with a premise that he have a clean BootROM, most people already have problematic BootROMs, some with 25 or more MemoryConfig entries, all sort of other entries and with serious fragmentation after 10 years. Without a clean NVRAM from the start, nothing is low risk.

Luckily I do have a BootROM without any certs, which I am keeping safe! I don't know if it has other issues though, so if you wouldn't mind giving it a check over for problems @tsialex I'd appreciate it.

Trying again tonight using BOOTOC as the location for OC's BOOTx64.efi has led to more issues. I tested first with BOOTOC as the directory on my Mojave drive and it works fine, but copying BOOTOC and OC dirs to the Windows EFI partition did not work; it booted Windows preferentially from Microsoft's \EFI\Boot\bootx64.efi and the damage was done again.

Not had much time tonight, but I'm now going to get aggressive and replace Microsoft's \EFI\Boot\bootx64.efi entirely and try again.

Is there a good way to check whether we've booted via OC when in Windows, like issuing nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version in Terminal?

 

[roobarb!]

Not had much time tonight, but I'm now going to get aggressive and replace Microsoft's \EFI\Boot\bootx64.efi entirely and try again.

So, I replaced Microsoft's \EFI\Boot\bootx64.efi with OC's \EFI\BOOT\BOOTx64.efi and deliberately did not bless it before removing all other drives and rebooting. I just wanted to see what the machine would do left to its own devices. OC options HideSelf is false and BlessOverride is:

<key>BlessOverride</key>
        <array>
            <string>\EFI\Microsoft\Boot\bootmgfw.efi</string>
        </array>

Reboot and I see this:



That's much better. It takes about 37 seconds for the picker to appear after the chime, I guess while it looks around for sources to boot from. This is why the \EFI\BOOTOC folder is probably a no-go; it'll likely always find and boot from an \EFI\BOOT in preference when it doesn't know what to do, meaning BootROM corruption with certificates.

Going to test whether it survives a reboot. Taking nothing for granted with Windows.

UPDATE: Survives reboot. Now to go back to Mojave and check the BootROM.

UPDATE2: No BootROM corruption! Now to go back to Windows and try the 1909 to 2004 update.



UPDATE3: No update installed yet, back in Windows through OC; but with no other drives installed it did fail to boot the first time. OC was found and launched, but Windows just sat there with the blue logo showing and no spinner. Power off and back on and it booted through OC just fine, though I got a 'what were you doing when your system crashed' feedback screen.

Wish me luck:



UPDATE4: Initial boot into installer worked through OC, our \EFI\BOOT was not affected. This time.



UPDATE5: First reboot of the upgrade and OC is still present, but no spinner on the boot screen again. Hard power off and power on, OC boots Windows and briefly “attempting to recover installation” is shown. Machine auto-reboots. OC kicks in, Windows boot logo... no spinner again.



Hard power off and back on, OC still okay, Windows spinner starts, then:



Auto-reboots. OC kicks in, Windows is booted, logo appears, no spinner again. I’m seeing a pattern here. Every other reboot during an installation and Windows is failing to start up properly. Remember, there’s only the one SSD installed to one SATA bay. It‘s in Bay 4 - I wonder if this behaviour would change if it were in Bay 1. Something to test another time now I know my BootROM is safe.

Another hard power off, OC kicks in, Windows spinner appears.



Recovery back to 1909 is successful. Two last things to try before quitting - check a standard reboot for spinner activity and then double-check my BootROM integrity.

UPDATE6: No issues at all rebooting. OC still present, spinner appears, back in Windows.

UPDATE7: With the Mojave drive back in the blessed OC is found immediately and sees both Mojave and the Windows drive. Boots just fine and BootROM is intact, no corruption.

So, something wonky is going on with reboots during updates which appear to be nothing to do with other drives, as there were no others present during that attempt. But the good news is that in the 1909 to 2004 update at least there's no attempt (so far as we got) to meddle with the \EFI\BOOT contents.

If anyone knows if there will be any useful logs hiding in Windows which I can post, please let me know where I might find them and I shall do so tomorrow.

 

[papadj3]

Total Newbie-Need Help!
I am using OC version 0.5.5 working well but I would like to add BootPicker (Optional) how do I get to my config.plist so I can add/edit steps?? Also, have been reading everything in this thread regarding Windows 10 Bootcamp and DO NOT Understand Any of it!! I have Windows10 Legacy Boot SSD thanks to tsialex instructions but am afraid to try and use it and/or try and change it to UEFI since the certificates issue is talked about constantly!! (Wish I understood-trying all the time-) Any help would be greatly appreciated!! (Hope I even asked the questions correctly) So Great all you experts keep our cMP's running!!!
[automerge]1581998648[/automerge]
By the way I have a Nvidia GTX 680 that has Apple Bootscreen- should I even add the OC Bootpicker??

 

[killaninja58]

Hi guys! Again a total newbie here!

I understand that in OC we now don't have to worry about the UEFI install of windows forcing Certs into the nvram.... My question is how the F@*! do I get it to install?! I've got a windows install usb created but OC doesn't see it. I've tried numerous different things to try and get it working with no avail!

Any help would be greatly appreciated! Using a 5,1 cMP mid 2012 with a flashed 1080ti

**Edit**
I forgot to mention that I do already have windows installed onto a ssd in drive bay 3. But I would like to get the UEFI install to work so that I can haveWindows installed on mym.2 sad along with Mac OS High Sierra

 

[h9826790]

Hi guys! Again a total newbie here!

I understand that in OC we now don't have to worry about the UEFI install of windows forcing Certs into the nvram.... My question is how the F@*! do I get it to install?! I've got a windows install usb created but OC doesn't see it. I've tried numerous different things to try and get it working with no avail!

Any help would be greatly appreciated! Using a 5,1 cMP mid 2012 with a flashed 1080ti

**Edit**
I forgot to mention that I do already have windows installed onto a ssd in drive bay 3. But I would like to get the UEFI install to work so that I can haveWindows installed on mym.2 sad along with Mac OS High Sierra

Only the latest OpenCore 0.5.6 offer that process protection. The current 0.5.5 official release don’t. Be careful.

If that USB installer doesn’t show up,try another USB thumb drive.

If you insert the USB installer after boot to the boot picker, press Esc to reload.

 

[roobarb!]

I understand that in OC we now don't have to worry about the UEFI install of windows forcing Certs into the nvram....

Not when OC has booted Windows, it protects everything just fine with the ProtectSecureBoot config option, but those occasions when OC hasn't booted Windows you're in trouble; check my post above trying to replace the bootloader.

If you install Windows in UEFI mode and don't modify the bootloader on that drive it's completely possible for your Mac Pro to hunt for, find and boot the Microsoft bootloader. By the time you've landed at the login screen without OC's protection, it'll be writing certificates and screwing up your BootROM.

At the very least, before you do anything else, use ROMTool (password: rom) to back up your BootROM from macOS. Then load it into TextEdit and search for 'Secure' to see if any certificates have already been written in.

 

[roobarb!]

So, something wonky is going on with reboots during updates which appear to be nothing to do with other drives, as there were no others present during that attempt.

Okay, RTFM is always good advice. I see there is an AdviseWindows property under Generic which makes it sound like a miracle this thing booted at all. I've updated my config.plist and will try it again tonight.

 

[startergo]

I am getting error upgrading to 1909 even with a single drive. Even without OC.
Maybe the biggest issue is that it is on NVME.

 

[killaninja58]

@roobarb! thats what I understand but at the same time with advisewindows set to true to help protect the nvram apparently it is possible from everything that I have read? In all ho edgy I’m not really all that fussed for Windows updates and I’m rather happy to sit on either 1803/1909... In all honesty I don’t mind. But, logically, if my brain is functioning correctly today lol, if I have OC installed onto one of my internal drives (2 x 4tb in raid, 1 x 10tb backup of that raid and then 256gb 860 evo ssd, or even in a usb) then I should be able to boot into windows UEFI perfectly fine with the nvram protected?
Another question I have is if I do somehow manage to brick my cMP what route do I go to unbrick my machine? TIA!

 

[tsialex]

Luckily I do have a BootROM without any certs, which I am keeping safe! I don't know if it has other issues though, so if you wouldn't mind giving it a check over for problems @tsialex I'd appreciate it.

Trying again tonight using BOOTOC as the location for OC's BOOTx64.efi has led to more issues. I tested first with BOOTOC as the directory on my Mojave drive and it works fine, but copying BOOTOC and OC dirs to the Windows EFI partition did not work; it booted Windows preferentially from Microsoft's \EFI\Boot\bootx64.efi and the damage was done again.

Not had much time tonight, but I'm now going to get aggressive and replace Microsoft's \EFI\Boot\bootx64.efi entirely and try again.

Is there a good way to check whether we've booted via OC when in Windows, like issuing nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version in Terminal?

Sent you a PM with all the info you need to gather, get everything and I'll check for you.

 

[roobarb!]

@roobarb! thats what I understand but at the same time with advisewindows set to true to help protect the nvram apparently it is possible from everything that I have read?

It's ProtectSecureBoot that does it, but yes, it's totally possible to use OC to boot Windows, though the reliability of upgrades and the like is still to be confirmed.

In all ho edgy I’m not really all that fussed for Windows updates and I’m rather happy to sit on either 1803/1909... In all honesty I don’t mind.

You may be, but Microsoft won't; Windows Update will constantly try to apply major release updates, which will only lead to headaches down the road.

But, logically, if my brain is functioning correctly today lol, if I have OC installed onto one of my internal drives (2 x 4tb in raid, 1 x 10tb backup of that raid and then 256gb 860 evo ssd, or even in a usb) then I should be able to boot into windows UEFI perfectly fine with the nvram protected?

Yes, you're right. Copy OC into the EFI partition of one of those, bless it as described in post #1, make sure your config.plist has ProtectSecureBoot set to true and you're off. You just have to make sure Windows in UEFI mode is always, always booted by OC or you're in trouble.

Another question I have is if I do somehow manage to brick my cMP what route do I go to unbrick my machine? TIA!

I honestly have no idea. I don't even know if it's possible, that's why I'm being so careful. Your only chance may be to buy a 'Matt Card' from CMIzapper to override the BootROM, but as for recovering the actual chip soldered to your logic board I would assume you'd be needing some in-system programming hardware.

I'd be interested to know myself, but I don't intend to find out the hard way.

 

[h9826790]

I am getting error upgrading to 1909 even with a single drive. Even without OC.
Maybe the biggest issue is that it is on NVME.

Possible, "external" drive issue.

 

[roobarb!]

Here we go again, this time with the AdviseWindows property set to true.



UPDATE: Gah.



Okay, so the update runs to 29%, auto-reboots the machine, no spinner, hard reset, spinner, “attempting to recover”, auto-reboot, no spinner, hard reset, spinner, “undoing changes made to your computer”, auto-reboot, spinner (fine that time), we’re back to the login screen.

Only drive present on Bay 4 internal SATA and OC remained active throughout.

I'm going to have another look through the documentation, but other than moving the drive to Bay 1, which I don't really believe will make any difference, I'm all out of ideas on this one. It would be a monumental PIA to have to reinstall Windows from scratch with each major update; or potentially have it continually attempt to apply an update which always fails.

Why, Windows? Why?