Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

ren777

macrumors newbie
Original poster
Sep 20, 2023
9
0
I recently bought a CMP 5,1 2012 dual CPU model.

I learnt that trying to use USB installation can botch the bootROM. I managed to do a rom dump and make a backup of my firmware.

I haven't yet managed to successfully install windows 7 through bootcamp, I couldn't get bootcamp to recognise the DVD I burnt. But now I'm contemplating if I should even try. I've even heard that windows updates can sometimes corrupt the bootROM. Because my windows copy is a very early version of windows without service packs, I have a lot more updates post installation. Could this be detrimental to the mac pro? Is there a way to keep windows from creeping its way into the bootROM in the long run?

I know opencore can act as a keepsafe for the mac firmware but I have no need to use opencore, since what I'm doing is natively supported. I don't want to break a perfectly working unit. Can someone help clear up my concern?
 
As long as you avoid USB, EFI / UEFI boots and GPT disks with Windows or Windows Installers you are safe.

Especially check the bootrom after you booted an unknown flavor of Windows.

You can flash your backup romfile back in case you catch certificates.

You know the tool in my signature will check and backup the bootrom.

Edit: if you have the very old and outdated MP51.0087.B00 firmware you should upgrade it as soon as you can. This firmware will get bricked if it booted UEFI Windows.
 
Last edited:
  • Like
Reactions: bmoraski
I'm not so techie, I don't understand what EFI/UEFI boots mean in practice. Isn't windows UEFI only?

I did do a ROM backup after I naively tried USB installer. Fortunately the installer didn't boot, so it seems OK? What do you think?

Firmware MP51.0089.B00
(U)efi version: 1.10

CRC32 checksums: ok
Old bootblock of MP51.007F.B03
Base_21 hardware descriptor
BootOrder: 1:Boot0080
Boot0080: |Apple_APFS|disk1s2 (SATA Bay 1:CT500BX500SSD1)|\3654FF7F-7E7E-30D6-BCE9-56160822069F\System\Library\CoreServices\boot.efi
Boot0080 is MacOs 10.13.6, label: macOS
BootFFFF: |Apple_APFS|disk1s2 (SATA Bay 1:CT500BX500SSD1)|\3654FF7F-7E7E-30D6-BCE9-56160822069F\System\Library\CoreServices\boot.efi
BootFFFF is MacOs 10.13.6, label: macOS
5 boots since last garbage collection, MTC counter: 1 - 6
6 (1 active) Memory Configs g (ok)
6 (1 active) Memory Configs h (ok)
6 (1 active) Memory Configs i (ok)
1 (1 active) Memory Configs j (ok)
1 (1 active) IASInstallPhaseList / xml (ok)
0 Microsoft certificates (ok)
1 (1 active) BluetoothActiveControllerInfos (ok)
1 (1 active) BluetoothInternalControllerInfos (ok)
2 (0 active) Boot PathProperties0000 (ok)
2 (1 active) NVRAM PathProperties0000 (ok)
VSS2 is empty (ok after recent full nvram reset or after flashing a rebuilt firmware)
22716 bytes free space of 65464
VSS1 (Formatted) (Healthy), found 52 variables (24 valid, 28 deleted)
VSS2 (Formatted) (Healthy)
 
You got no Bootvar with a Windows bootloader, nor a certificate.

The second store is empty, this is ok if you recently reset the nvram (before 5 boots).

GPT Windows disks, DVDs and all USB thumb drives with a Windows installer contain an ESP (Efi System Partition) with an Uefi bootloader what immediately sign the bootrom with certificates. Even if once booted without installing Windows.

If you run my little script: Mount ESP from list and show bootloader (its in the dumper package) you will see those as an active Windows ESP. Active means that the bootx64.efi bootloader is in the ESP and could be started. Most of us pull or rename it to not accidently get it started. OpenCore does not need it to start Windows.

But thats not 100% safe (make it inactive) as Windows updates renew it.



@startergo posted a picture of the boot picker with an ESP of a Windows DVD. Windows disks also shows as EFI boot.


I am in the process of writing a little script to rename ESPs to show another name. I renamed my Windows ESP to [Win dont start].
 
Yes I had to do NVRAM reset after I couldn't boot to macOS after the failed USB install attempt.

Bootcamp doesn't seem to format partition in GPT or am I wrong? The bootcamp partition ( in my case a separate drive) is in MBR not GPT. Does that mean ESP won't be done by Windows 7 installer?

If bootcamp keeps the windows partition as MBR will windows boot or even install in the first place?
 
Yes I had to do NVRAM reset after I couldn't boot to macOS after the failed USB install attempt.

Bootcamp doesn't seem to format partition in GPT or am I wrong? The bootcamp partition ( in my case a separate drive) is in MBR not GPT. Does that mean ESP won't be done by Windows 7 installer?

If bootcamp keeps the windows partition as MBR will windows boot or even install in the first place?
Bootcamps assistant formats the drive according to the firmware. The data contained in the firmware are read by Bootcamp assistant which in turn formats it accordingly. Apple designed it with respect to your hardware. Installing Windows with Bootcamp assistant will always be safe. For cMP Apple uses hybrid MBR partition which is a combination of both GPT and MBR. Apple flips a bit in the partition table in the ESP data structure and a regular GPT disk appears as an MBR disk for the Windows installer. Windows don't see the ESP partition and treats the disk as an MBR disk.
 
A hybrid MBR will allow ESP? If I open command during windows installation and format the partition to MBR through the installer, will it screw up the install process? Like in the attachment?
 

Attachments

  • Screenshot 2023-09-24 at 6.33.24 PM.png
    Screenshot 2023-09-24 at 6.33.24 PM.png
    617.9 KB · Views: 75
A hybrid MBR will allow ESP? If I open command during windows installation and format the partition to MBR through the installer, will it screw up the install process? Like in the attachment?
Yet it will. If there are no other partitions or data on the DISK it does not matter. But if you have another partition, for instance HFS+ partition on the drive, you will be lucky if it is not gone. The need for a hybrid partition comes from the fact that macOS for modern macOS's can be installed only on a GPT or hybrid MBR partitions.
 
If I'm not mistaken, windows will have ESP on GPT or MBR, but won't show up on boot picker when using MBR?

I only intend to do legacyBIOS boot (install windows 7 through DVD), and I don't mind a partition limit of 2TB on MBR, so will it be safer this way for the bootROM using MBR?

I'm using a RTM ( released to manufacturer ) version of windows, which is as bare bone copy even without service packs. It even checks out using md5 checksum of the iso.

Problem is I have to use WSUS update tool, i'm looking at about 200+ slipstream updates (potentially 6hr of updates). Windows updates aren't cumulative like on macOS. Will it bother the bootROM and write windows certs upon updates?
 
If I'm not mistaken, windows will have ESP on GPT or MBR, but won't show up on boot picker when using MBR?
The ESP (EFI) partition is only applicable to drives formatted as GPT or hybrid MBR drives (Windows will not see the ESP in hybrid MBR partition style). Regular MBR drive created by the DISKPART utility do not contain ESP (EFI) partitions. Windows can boot in 2 modes:
UEFI and Legacy Bios mode. Certificates are written to the NVRAM ONLY when you boot Windows in UEFI mode i.e. only if the drive is formatted with a GPT partition style.
In UEFI type firmware, the data that's stored in the NVRAM is structured in terms of "EFI variables" and the firmware does allow the OS to access them – but still, only through the functions provided by firmware, not directly at block level. (It's a lot like how the OS allows your regular apps to use the HDD/SSD but only through file management functions – it does permission checks, etc.)

The list of operating systems in UEFI is stored as "EFI variables" in the motherboard's NVRAM – when the OS is installed, it calls the firmware function to create a variable named Boot0002 or similar, with specified data.

Secure Boot settings are mostly the same. There is a variable named db that lists the certificates allowed to sign operating systems (the MS UEFI CA certificate is stored in db), and the only thing special about it is that the firmware requires the new value itself to be digitally signed.

At boot time, the initial OS files are validated against certificates listed in 'db'; updates to 'db' must be signed with the certificate found in 'KEK', and updates to that are verified against 'PK'. (The firmware settings screen can bypass those checks and let you import any certificate – but the OS can't.)
hybrid MBR and regular MBR partition styles do not allow Windows to boot in UEFI mode therefore Windows will not create any certificates in the NVRAM section.
cf57ef08-6314-4b65-9cc9-ea5f59ee86e7.png

QIzyq.png
 
Last edited:
That's quite a wonderful explanation, kudos to you. Thanks for clearing up my doubts. I will attempt a new windows install tomorrow and see if it fairs.
 
Thank you to all that helped with my concern. Everything went smoothly (almost).

I had to waste two dvd's writing the iso file using Finder, because High Sierra removed the ability to burn through Diskutility. All I had to do was right click on the file and burn it that way. Worked like a charm.

After booting into Windows 7 installer (minding not to use the EFI Boot ) it progressed until it halted saying the partition is GPT and should be NTFS. I used command prompt to clean and then convert to MBR said partition and all went smoothly there after.

But this is where I confronted another issue...

The startup manager is finicky. I didn't work at first but I did a couple NVRAM resets and it worked just fine. But soon after couple more restarts ( setting up windows and installing programs ), it stops working again.

Doing NVRAM preset isn't hard but is obviously time consuming and cramping up my fingers. And it seems taxing on the machine. I know rEFInd is an option, but I want to keep things as stock as possible. I even checked my ROM after Windows install, it seems fine. I tried holding the alt key (I use a wireless keyboard and mouse combo, not apple accessory) from before power-up and also tried right after the chime, seems it's only responding to NVRAM resets.

Is there a way to make startup manager more stable? I'd like to keep third party options as last resort. Could the issue stem from me formatting the drive as MBR instead on apple's hybrid MBR be messing up something. Thank you in advance.
 
Alright I fixed it.

After a successful bootcamp installation everything worked fine except for the startup manager. It just wasn't stable and i had to do an NVRAM reset 4 to 5 power cycles later. The Mac simply loved to boot to the last used OS and holding down Option key doesn't work.

Although I'm seriously doubting the timing for when to exactly hold the key during startup, but it is just too narrow of a target. Basically i feel like NVRAM reset makes the boot up slightly slower by few seconds and that gives me enough time to hit up the startup manager. But the system boots up faster consecutively and that might be why i keep missing the timing. But this is just speculation, i don't know definitively.

But i found a better solution. Basically you can make the startup manager show up all the time during boot up. This is extremely useful when dual booting. No need to use rEFInd if all you want is to select boot drive. So heres how you do it.

Open terminal and use this command
sudo nvram manufacturing-enter-picker=true

Or if you can boot to recovery disk using cmd + R and open terminal there, use
nvram manufacturing-enter-picker=true

This is it, solved all my problems. Now you should get startup manager every time you boot up, but startup will be a tad bit slower than booting directly to the last used OS. But worth it if you don't get startup manager to behave properly.

Hope it helps.
 
This works but the downside is that you need to hit enter when a system installs or updates and reboots (multiple times).

Also this method gives you zero nvram protection for Uefi Windows.

If you can live with it and your GPU has a working bootscreen this is a solution. I would prefer a bootmanager like RefindPlus.

Gives bootscreen if the GPU is capable, auto boots after a given time, gives Uefi Windows nvram protection. Also, some more features like chainloading other bootmanagers like OpenCore.
 
That is true, have to select drive and enter every time along with a longer boot. That is a down side to this method. And there is an added risk for UEFI Windows. Thankfully my disk is MBR scheme and does not have EFI boot for Windows. So in that case it works for me, but others who have UEFI with GPT will stand the risk.

rEFInd is the better option for whom apple startup manager is a no go. Plus using themes you can have it look remarkably stock just like opencore boot manager.

So yes, people should look into the downsides of each before opting. rEFInd on the other hand is a nobrainer and probably the best option for most people.
 
I dont know if rEFInd has nvram protection as well.
It doesn't but I suppose this is moot given that the OP is apparently running Legacy Windows.

Reading through the thread, there is a stated preference of avoiding third party utilities and there doesn't seem to be a need for Linux. Therefore, as you noted earlier, setting things up to always go into Startup Manager will work. Just needs to remember to re-enable it after NVRAM resets; which should be few and far in between.
 
  • Like
Reactions: Macschrauber
As long as you avoid USB, EFI / UEFI boots and GPT disks with Windows or Windows Installers you are safe.

Especially check the bootrom after you booted an unknown flavor of Windows.

You can flash your backup romfile back in case you catch certificates.

You know the tool in my signature will check and backup the bootrom.

Edit: if you have the very old and outdated MP51.0087.B00 firmware you should upgrade it as soon as you can. This firmware will get bricked if it booted UEFI Windows.
Hi Macschrauber,

I'm new to this game. I recently bought a classic Mac Pro 5,1 2012, thinking I could use the 4x drive sleds to easily switch OSs (Win/Lin/Mac, whatever). In my ignorance, I promptly installed Win XP from an old MS installation CD to an old HDD salvaged from a laptop, wanting to run some old games. It was a bit of a performance tracking down all the drivers and activating it, but hey it all works! I can choose Win XP or High Sierra just by plugging in the appropriate drive sled. Great. Only now I gather that this may have been an unwise move regarding bootrom issues, so I have two questions.

1. Is it likely I have damaged the bootrom? I mean, Win XP? Really?
2. The machine is still on MP51.0089.B00. Would the planned upgrade to 144.0.0.0.0 fix it? That is, does the upgrade completely overwrite the firmware with a new version.

Many thanks in anticipation, Frank
 
Hi Macschrauber,

I'm new to this game. I recently bought a classic Mac Pro 5,1 2012, thinking I could use the 4x drive sleds to easily switch OSs (Win/Lin/Mac, whatever). In my ignorance, I promptly installed Win XP from an old MS installation CD to an old HDD salvaged from a laptop, wanting to run some old games. It was a bit of a performance tracking down all the drivers and activating it, but hey it all works! I can choose Win XP or High Sierra just by plugging in the appropriate drive sled. Great. Only now I gather that this may have been an unwise move regarding bootrom issues, so I have two questions.

1. Is it likely I have damaged the bootrom? I mean, Win XP? Really?
2. The machine is still on MP51.0089.B00. Would the planned upgrade to 144.0.0.0.0 fix it? That is, does the upgrade completely overwrite the firmware with a new version.

Many thanks in anticipation, Frank
XP is was never UEFI, so no certificates and no harm to the firmware.

Updating to 144.0.0.0.0 the Apple way, by installing Mojave, writes a new firmware, but keeps your Fsys stream with IDs and NVRAM content, also with certificates if one got any. Also it keeps the old bootblock with the Firmware MAC address and the Logic Board serial and build date.

If you want to get all fresh, you do (let do) a firmware reconstruction. This will give a completely empty and fresh NVRAM and an updated bootblock. Your machine's IDs get transfered to that fresh firmware.

First you should start with a firmware backup, if you use my tool, you will get a deep check of the current condition, too.
 
XP is was never UEFI, so no certificates and no harm to the firmware.

Updating to 144.0.0.0.0 the Apple way, by installing Mojave, writes a new firmware, but keeps your Fsys stream with IDs and NVRAM content, also with certificates if one got any. Also it keeps the old bootblock with the Firmware MAC address and the Logic Board serial and build date.

If you want to get all fresh, you do (let do) a firmware reconstruction. This will give a completely empty and fresh NVRAM and an updated bootblock. Your machine's IDs get transfered to that fresh firmware.

First you should start with a firmware backup, if you use my tool, you will get a deep check of the current condition, too.
That's good to know. Very reassuring. I have a lot to learn, but that's part of the fun of it! Many thanks.
 
A random thought just occurred to me.

I have very successfully used Matt Gadient's tool to make a modern 64 bit Linux bootable on a 2006 white iMac which is limited by a 32 bit EFI. Apparently it works by stripping the EFI booting bit from the .iso file so that after burning a DVD, booting drops back to the legacy BIOS mode. It works very well. Most satisfying to see Ubuntu Mate 22.04 (supported until 2032 with the FREE upgrade to Ubuntu Pro) running on an 18 year old computer.

I'm just wondering if the same trick would work with a modern-ish Windows .iso and if this would also force a BIOS booting mode and if this would avoid the nasty EFI-specific Windows habit of taking liberties with a CMP's bootrom?

Lots of ifs there. What do you think?
 
I even managed to install Windows 11 in bios mode with this tool:

 
And does that avoid the dreaded certificates?

That method sounds a fair bit more complicated than hacking the .iso - if that works.
 
And does that avoid the dreaded certificates?

That method sounds a fair bit more complicated than hacking the .iso - if that works.
Bios mode does not write certs.

very important: make a firmware backup, before you fiddle with Windows. In case you catch certs, you can revert.
 
Thanks again for the advice. I will take your warning to heart. Might be a while before I'm ready to dive in!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.