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 Bare Metal Windows on cMP
- Thread starter Dayo
- Start date
- Sort by reaction score
Try "sudo VirtualBox" in Terminal.
If it does not load, then it is not working and you need to look into reinstalling it.
Are there any versions of Windows 10 with which this outright doesn’t work? Because it doesn’t work. I did everything up to “shut down the VM during the countdown and then boot to the disk itself” and it’s just a black screen with a flashing cursor no matter how long I wait. I’m using the most recent downloadable version from Microsoft’s servers, which is apparently only a few numbers shy of the final release.
Booting back to OS X shows me what looks all the world like a proper Windows file tree directly on the drive itself. Aside from a user account, it all seems to be there, and is all the right size. Just doesn’t boot at all. Any ideas?
It takes a little over an hour and a half every time I do this, so I’d really like to not have to do it a fifth time.
Booting back to OS X shows me what looks all the world like a proper Windows file tree directly on the drive itself. Aside from a user account, it all seems to be there, and is all the right size. Just doesn’t boot at all. Any ideas?
It takes a little over an hour and a half every time I do this, so I’d really like to not have to do it a fifth time.
Last edited:
Installing Windows 10 in Legacy/BIOS mode in cMP with Boot Camp Assistant
Installing Windows 10 in Legacy/Bios mode in classic Mac Pro is easy. You will have to use a modified Bootcamp assistant, which I attached to this post or make your own using this guide. The installation has been tested on High Sierra partition with HFS+ partitioning scheme. The only limitation...
forums.macrumors.com
Windows Install - Browse Files at SourceForge.net
Installing Windows from macOS. Suitable for Hackintosh and Macintosh
sourceforge.net
All right, never mind. Same problem as all the other ways I’ve tried. Black screen, flashing cursor. No matter what version of Windows, no matter type of ISO, no matter what method. I’m done. Thanks anyway, everyone.
Installing Windows 10 in Legacy/BIOS mode in cMP with Boot Camp Assistant
Installing Windows 10 in Legacy/Bios mode in classic Mac Pro is easy. You will have to use a modified Bootcamp assistant, which I attached to this post or make your own using this guide. The installation has been tested on High Sierra partition with HFS+ partitioning scheme. The only limitation...
Windows Install - Browse Files at SourceForge.net
Installing Windows from macOS. Suitable for Hackintosh and Macintosh
This is a long known issue of some PC GPUs, if your GPU does not provide pre-boot configuration support, you'll need to wait until Windows Update automatically downloads the GPU drivers, could take half an hour or even more.
You'll need to be connected to the internet via Ethernet without any proxies and etc, btw.
It wouldn't here given that the installation has not been completed.
In any case, there must be a PreBoot screen given this statement:
"Everything" includes this requirement outlined right at the start:
... and towards the end:
Surely, there is no way anyone would ignore repeated instructions and when things do not work afterwards, conclude that something else must be the reason.
Correct. I won’t be called incompetent or illiterate again, so don’t bother. I tried multiple ISOs directly from Microsoft’s servers. I tried “totally legitimate” ISOs. I used the baseline hardware configuration with which my Mac Pro shipped. Same results every time. I know what I’m ****ing doing. It’s pretty simple to read and follow instructions when they’re all laid out. But when even regular websites barely even mention a black screen with a flashing cursor, there’s little to be done afterward. If it’s a Windows Update problem, those IPs are blocked on my network and so I’ll just wash my hands of the whole affair.
It's not a Windows Update issue, or one of which ISO you used, but one of whether you ensured that you have a Pre-Boot Config Screen available, as listed as the every first requirement here, before you started the process.
If you missed that this was specified as a requirement, you need to address this as the process cannot be completed without one.
This requirement equally applies to the other method you subsequently tried, given that Windows Updates, even if not blocked, cannot happen until the installation is completed in the first place and the installation cannot be completed without this requirement being met.
This is because of the need to reboot to complete the installation process and if you do not have a display after this reboot, you cannot complete the installation.
In summary, the Pre-Boot Screen AKA "BootScreen" is a requirement.
Can you definitely confirm whether you have this requirement covered or not?
If you do, you need to hold the OPTION key when booting and select the Windows option there to complete the installation. This is required regardless of which method you use.
If you don't, you need an alternative/equivalent screen to achieve the same end.
An option to get one such screen is linked here.
Good thing I’m immune to gaslighting, because otherwise I’d be questioning my sanity with this continually being said in the face of what I’ve tried. This good enough? Or do people not call this the pre-boot screen anymore? Every single time, every single method, every single ISO. Same result. Plugged into a GT 120 explicitly so that I’d be able to see the boot picker instead of having to do it blind.
First:
Immediately after:
Stays like that no matter how long I wait.
Well, you have only gotten round to confirming that you do have the preboot screen. A Yes/No response would have done.
With that out of the way, the useful thing is that you indirectly confirmed the GPU model and the only thing that pops to mind is that the GPU is perhaps not supported by newer Windows given it is an old UGA-based one. Have to say I do not know for certain, but that will be my first hunch from what you are seeing. I would have expected this to work regardless though ... at least for this part of the process.
You might want to try a GOP capable GPU if you have one but then, you would need one that gives the bootscreen or again, use an alternative screen.
Bottomline is that you do not have a graphical display for the last stage despite the GPU and without one, the installation cannot be completed.
EDIT: You might want to first look into how the GPU is connected and use a direct DVI connection if possible.
With that out of the way, the useful thing is that you indirectly confirmed the GPU model and the only thing that pops to mind is that the GPU is perhaps not supported by newer Windows given it is an old UGA-based one. Have to say I do not know for certain, but that will be my first hunch from what you are seeing. I would have expected this to work regardless though ... at least for this part of the process.
You might want to try a GOP capable GPU if you have one but then, you would need one that gives the bootscreen or again, use an alternative screen.
Bottomline is that you do not have a graphical display for the last stage despite the GPU and without one, the installation cannot be completed.
EDIT: You might want to first look into how the GPU is connected and use a direct DVI connection if possible.
Last edited:
Actually, on looking at this again, the issue seems unlikely to be GPU related since there is output in the form of the cursor. Seems more likely to be disk setup related.
What type of disk are you trying to install to and how/where is it connected to your Mac?
Also, is there anything else on the disk?
What type of disk are you trying to install to and how/where is it connected to your Mac?
Also, is there anything else on the disk?
Just for reference: Early 2009 Mac Pro 5,1 with 144.0.0.0.0.
Standard HDDs. Mac drive is in slot 1, spare data’s in slot 2, Windows in slot 3, and my Time Machine drive is slot 4. They’re all SATA II drives in the Mac Pro’s SATA II ports. Only one partition on the Windows drive, and I reformatted it manually as MBR+ExFAT before every attempt with Windows Install (even after the failed ones, where it seemingly wrote nothing to the drive but clearly did), and as MBR+FAT for the VirtualBox tutorial (this thread).
I also unmounted it where this thread’s tutorial told me to. At first I thought I wasn’t shutting down the virtual machine “fast enough” during the 10 second timer. But Windows Install has also failed, so I don’t know.
Should I check the drive's integrity with Disk Utility? I have no reason to think it has bad sectors or physical damage. I do know I had a working Windows install last November, left the computer off for about seven months, and then it refused to boot correctly after I repaired my northbridge heat sink (Safe Mode still worked for some reason).
Does Windows 10 22H2 balk at certain hardware configurations where previous versions of the OS don’t? I’m trying to cross odd cases off the list, but it’s hard to think of why this would be happening.
Use the script at https://gist.github.com/joevt/a99e3af71343d8242e0078ab4af39b6c to gather info about your disks and partitions. Zip the result and attach to a new post so we can examine it.
Do you have any PCI cards installed besides the GPU?
Well, HDDs explain the 1.5 hour partial installation. Totally forgot these still exist.
Brings back memories from back in the day: "There are two types of HDD ... those that have failed and those that are failing".
Now, there is an underlying issue where an existing previously working installation could no longer be booted and this has apparently extended to attempts to reinstall on the same HDD. A potential fix would be to nuke the disk before remounting and then formatting for whichever installation method you prefer.
If using the method here, you can spare yourself having to sit around waiting to force the VM shutdown by issuing the command below after the "CONFIGURE VIRTUAL MACHINE" step and before the "INITIATE INSTALLATION" step:
This setting will make the VM automatically power off on receiving a reboot signal.
Disconnect the Time Machine and Data disks as well as any external disks and any disks on PCI Slots.
If it still fails to take, run the @joevt script and take things to a new thread for further consideration as suggested.
EDIT: Check "ResetBehavior" status with
Brings back memories from back in the day: "There are two types of HDD ... those that have failed and those that are failing".
Now, there is an underlying issue where an existing previously working installation could no longer be booted and this has apparently extended to attempts to reinstall on the same HDD. A potential fix would be to nuke the disk before remounting and then formatting for whichever installation method you prefer.
Bash:
##
# Run "diskutil list" to verify "/dev/disk??" first --- IMPORTANT!
# Change "/dev/disk??" to match as needed
##
sudo gpt destroy /dev/disk??If using the method here, you can spare yourself having to sit around waiting to force the VM shutdown by issuing the command below after the "CONFIGURE VIRTUAL MACHINE" step and before the "INITIATE INSTALLATION" step:
Bash:
##
# Assumes you named the VM as "WIN10" in the configuration step
##
sudo VBoxManage setextradata "WIN10" "VBoxInternal/CPUM/ResetBehavior" "powerOff"This setting will make the VM automatically power off on receiving a reboot signal.
Disconnect the Time Machine and Data disks as well as any external disks and any disks on PCI Slots.
If it still fails to take, run the @joevt script and take things to a new thread for further consideration as suggested.
EDIT: Check "ResetBehavior" status with
sudo VBoxManage getextradata "WIN10" "VBoxInternal/CPUM/ResetBehavior". Should return "powerOff" if set.
Last edited:
You got it, boss. The HDD in question in the report is disk1. This file with my most recent (failed) Windows install (black screen, flashing cursor)–using Windows Install–still partitioned. I can run it again after clean wiping the disk with nothing on it if you need that, or I can run the VirtualBox tutorial and do it.
I’m running all of this off the GT120 that shipped with my Mac Pro, which I keep around for troubleshooting any OS so I can get a pre-boot screen and access to install discs or the recovery partition. I’ve left my GTX 980 installed for convenience’s sake, though nothing is connected to it (so no OS should be trying to output video to it). Other than that, no. Should I just pop the 980 and try again?
I’ve thought about that quite a bit, with the trial and error I’ve had to do. For example, after accidentally invoking Windows Install with SIP still on (it turns itself back on between reboots and I forget about that…), I’ve noticed that the application always errors out if I don’t do a clean disk wipe with Disk Utility before attempting to reinstall. I was guessing the same thing–the previous format “kept its data” even though the utility said it was wiping it on its own.
How does “sudo destroy” differ from using Disk Utility to reformat?
Does that signal get sent at the start of the 10 second countdown during Windows’ installation program, or only at the end? I know I’m asking about Microsoft knowledge now…
Will do; good idea. I hadn’t been doing that because these methods were “safer” than what I’m used to. Years ago, when I’d be installing various older Windows directly from a DVD, I would always pop all my other drives so that there’d be no way for Windows to say, “Hey, this looks like a good disk to use!” and delete something I didn’t want deleted. Worse, because I had identical models of drives back in the day, so they’d all report bare names with the same manufacturer and same size.
Thank you all for your continued help, and I’m sorry for earlier curtness. I don’t blame any of you, and I don’t blame the creators of the Windows Install utility or the VirtualBox tutorial. My go-to for decades has always been “It’s Microsoft’s fault,” and that has never really failed me in solving Windows problems… though in this case, I’m definitely doing an install that isn’t “standard,” and it’s just damned frustrating to have to download so many different “versions” and spend hours waiting for them to misbehave.
Unlikely to apply here…but I will note when I’ve seen an endless flashing cursor it may indicate a boot stage issue, e.g. expecting EFI but starting as CSM or vice versa.
I Have had it happen in Linux and windows multiple times until correct configuration is selected in BIOS on PCs, sometimes even relating to which type of option ROMs are being loaded, even if the right mode is selected. I’ve also seen it on windows where the EFI path is not quite right (especially on early EFI machines) when restoring a drive from a backup. Most PCs will show an error about the wrong mode, but some just flash the cursor indefinitely.
IIRC, Without editing disk labels, the Mac boot picker would only show “EFI boot” for EFI installs or “Windows” for CSM installs.
On the Mac, other than above selections, boot mode is related to how the disk is formatted and blessed.
Mac formatted, busy disks, or other EFI partitions on disks can block / redirect the EFI partition from correct installation from Windows installer.
This is one reason for the virtual machine methods, so the whole disk is available to the windows installer.
On a PC with improper boot files, to avoid having to reinstall you would restore the MS EFI boot files from Windows Recovery or use tools like EasyBCD to verify / create the boot paths.
Knowing exact disk geometry will help rule out legacy boot issues.
I Would also mention PRAM reset if the Mac is not easily switching EFI/CSM contexts
There are plenty more posts on using opencore or Dayo’s tools to protect Mac Pro Bootrom when running Windows.
I Have had it happen in Linux and windows multiple times until correct configuration is selected in BIOS on PCs, sometimes even relating to which type of option ROMs are being loaded, even if the right mode is selected. I’ve also seen it on windows where the EFI path is not quite right (especially on early EFI machines) when restoring a drive from a backup. Most PCs will show an error about the wrong mode, but some just flash the cursor indefinitely.
IIRC, Without editing disk labels, the Mac boot picker would only show “EFI boot” for EFI installs or “Windows” for CSM installs.
On the Mac, other than above selections, boot mode is related to how the disk is formatted and blessed.
Mac formatted, busy disks, or other EFI partitions on disks can block / redirect the EFI partition from correct installation from Windows installer.
This is one reason for the virtual machine methods, so the whole disk is available to the windows installer.
On a PC with improper boot files, to avoid having to reinstall you would restore the MS EFI boot files from Windows Recovery or use tools like EasyBCD to verify / create the boot paths.
Knowing exact disk geometry will help rule out legacy boot issues.
I Would also mention PRAM reset if the Mac is not easily switching EFI/CSM contexts
There are plenty more posts on using opencore or Dayo’s tools to protect Mac Pro Bootrom when running Windows.
Another unrelated note:
I’ve also seen in older PCs when trying to direct install Windows 11 that fail to complete setup, is that there is a new installer mechanism.
In the first stages of Windows setup there is a tiny link for the “previous version of setup” which installs the old way and avoids many problems.
I doubt the Windows 10 installer has changed. But I don’t know the future holds as Win10 moves out of support.
I’ve also seen in older PCs when trying to direct install Windows 11 that fail to complete setup, is that there is a new installer mechanism.
In the first stages of Windows setup there is a tiny link for the “previous version of setup” which installs the old way and avoids many problems.
I doubt the Windows 10 installer has changed. But I don’t know the future holds as Win10 moves out of support.
So you’re saying it might be possible to boot from a Windows install USB drive and run troubleshooting to restore them? But won’t those EFI files write incorrectly to the NVRAM/BootROM and cause the problem I’ve just reconstructed my BootROM to avoid?
Ah, I haven’t zapped that since doing the firmware update to 144. Maybe that could be something.
EDIT:
Oh, goodie. Guess what didn’t work and restarted on its own anyway while I wasn’t paying attention. **** my life.
Last edited:
In the current output, I don't see anything strange but there's some missing info that I'm looking for (to detect boot code in the MBR and VBR). Looks like there's a bug in the script. What version of macOS did you run it on? I might need to make a fix for your OS.
One graphics card might be better. Try running with just the GT120.
I suppose either card should work when booting Legacy? Except you can't choose the boot disk with the option key at startup with a GPU that doesn't have EFI support for your Mac. In that case, you would have to choose the startup disk with the Startup Disk preferences panel, or use the control key in the Startup Manager (hold option key at boot to get into the Startup Manager with a Mac supported GPU, select the Windows boot option with the arrow keys, then hold the control key and press return to boot it and make it the default, then shutdown, remove the Mac supported GPU and insert the Legacy Windows supported GPU).
Last edited:
10.13.6
I will tell you that whatever ancient method I used to update to High Sierra back in the day, I’ve never undone it. It’s not OpenCore, it’s whatever people used before that. And my previous Windows install was almost certainly EFI-based, but that hard drive has been completely wiped at least 30 times in the course of me trying to do this now.
Sure. Try VirtualBox, Windows Install, or both?
Can’t I just do it blind, like I’ve been doing for years? It uses a display shared with a Mac mini (I just switch inputs), so I have the display plugged into the good card all the time rather than needing to switch back and forth between cards. I hold Option, wait 15 seconds (how long, I’ve discovered, it takes the Mac Pro to pull up the menu), tap right arrow twice (for my old install; it’s showing up as just once now), and then hit Return. Screen’s black (off black, not on and black) the whole time I do this, but Windows always recognized itself and booted right up afterward.
I’ll stick with just the GT120 directly while Windows is (failing to) installing so I don’t have to mess around with anything fancy. Once I know I have a working Windows install, I’ll go back to my old muscle memory system of blind boot switching.
This was it. I removed my GTX 980 and did the VirtualBox install again. Booting to the raw drive flashed the cursor for two seconds before moving on to “Getting things ready…” It rebooted itself, I went back to Windows, and now I’m on the “Just a moment…” screen. So it’s still stuck, but this is no longer a tutorial problem or a me problem, it’s a Windows problem. And I know what to do with those! Blame Microsoft!
I’m happy I can at least pretend to boot Windows again, and I’m also happy to have contributed in two small, humiliating ways to the tutorial. I’d suggest adding “Make sure you have no PCIe cards installed other than the GPU you’re using to get a boot screen.” to the General Preparation section. And even though the Terminal command for forcing VirtualBox to power itself off didn’t work for me, it might work for someone else, so having it there is surely going to be useful.
OH, IT FINALLY MOVED ON. I CAN SET UP NOW.
Thank you again, everyone.
Having an unconnected GPU present was a potential misconfiguration ... Cannot really cover such.
Even if it does, a "Lowest Common Denominator" target is best ... Ditching this.
Did you nuke the disk at any point?
The @joevt script not detecting legacy bootcode might not have been a bug in the script as legacy bootcode being "bad" was what I thought might be the issue; hence asking you to nuke the disk so that everything is rebuilt.
I suspect the unconnected GPU was a red herring in your case ... If you did the nuke.
EDIT: Rerun the script for Joe to check whether legacy bootcode is now detected or not.
This will let him know whether there is a bug present in the script or not, to potentially save him debug time.
Last edited: