How to: Boot Camp without a Boot Screen

[startergo]

As far as I know, from installing windows in CSM/Legacy mode, AHCI is disabled and IDE is instead used which halves the speeds of the already slow Sata II ports unless you convert your Windows installation to EFI by using mbr2gpt or installing Windows in EFI mode.

That's the drawback of running Windows in legacy mode on the cMP

That is what I thought too. Hence I was avoiding Legacy boot.
[doublepost=1540055111][/doublepost]

Ah OK. I vaguely remember this now. I think there's a method to force AHCI mode though, which is discussed in this thread. Anyone wanting to try it should read through the whole thread as it appears it breaks Sleep mode and there are some other tips posted by others (none of which I have tried).

I'm leaning back towards just using EFI mode, and binwalking my bootrom periodically to see if any multiple certificates show up.

See this:

Ok I have just booted to both WIN10 EFI disks and back to HS and here is the binwalked dump:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1181430 0x1206F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1189221 0x122565 XML document, version: "1.0"
1246966 0x1306F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1254757 0x132565 XML document, version: "1.0"
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume
I guess Windows creates 2 x509 cert and 2 XML for both EFI OS's

 

[bookemdano]

That is what I thought too. Hence I was avoiding Legacy boot.
[doublepost=1540055111][/doublepost]

See this:

Edit: Just realized that is your post. Editing my response below accordingly:

I have been following that thread. Did you ever install the 0087 bootrom? Tsialex has speculated that the problem seems to occur with people who did install 0087. And let's be clear. Having two certificates in there does not necessarily mean your bootrom is ruined. Tsialex is just speculating that it could present problems down the line, but it's not been definitively proven yet. A lot of this stuff is still extremely opaque, so I don't think any conclusions can be drawn at this point.

Edit: You also had two different Win10 EFI installs. Seems possible that each install is maintaining its own trusted certificate in NVRAM.

 

[startergo]

Edit: Just realized that is your post. Editing my response below accordingly:

I have been following that thread. Did you ever install the 0087 bootrom? Tsialex has speculated that the problem seems to occur with people who did install 0087. And let's be clear. Having two certificates in there does not necessarily mean your bootrom is ruined. Tsialex is just speculating that it could present problems down the line, but it's not been definitively proven yet. A lot of this stuff is still extremely opaque, so I don't think any conclusions can be drawn at this point.

Edit: You also had two different Win10 EFI installs. Seems possible that each install is maintaining its own trusted certificate in NVRAM.

I jumped from 84 straight to 138. After that Alex reconstructed my ROM and sent me the intermediate files. I reconstructed the 139 (with the intermediate files) and flashed to 139. Then I flashed to 140 the Apple way.

 

[bookemdano]

I jumped from 84 straight to 138. After that Alex reconstructed my ROM and sent me the intermediate files. I reconstructed the 139 (with the intermediate files) and flashed to 139. Then I flashed to 140 the Apple way.

And you ended up with two certificates after Tsialex reconstructed your boot rom?

Are both of your Win10 installs the exact same edition and build #?

This is an interesting case, because Apple wanted all cMP users to be at 10.13.6 to install Mojave, but it's unclear if that's because it wanted them to be on boot rom MP51.0089.B00. They had to have known that due to their arcane firmware updating procedure, that many or even most users would have installed 10.13.0 and then used the Mac App Store upgrade mechanism to get to successive updates, meaning they'd still be on MP51.0084.B00 even though they were on 10.13.6 like startergo.

 

[startergo]

And you ended up with two certificates after Tsialex reconstructed your boot rom?

Are both of your Win10 installs the exact same edition and build #?

Actually, if you look at posts #1978 and #1984 you will see what is going on although I am not sure how to interpret it. I am not sure how was my original ROM I sent to @tsialex maybe he can clear that out.
Both windows are win 10 enterprise 1803

 

[tsialex]

Actually, if you look at posts #1978 and #1984 you will see what is going on although I am not sure how to interpret it. I am not sure how was my original ROM I sent to @tsialex maybe he can clear that out.
Both windows are win 10 enterprise 1803

You sent your BootROM dump from a 3rd party service at the time and I didn't save it into my iCloud folder. I'll have to look into my TM backup later when I'm back home.

 

[bookemdano]

I have no doubt we can get to the bottom of this (or rather Tsialex can with all of our data points).

 

[tsialex]

I have no doubt we can get to the bottom of this (or rather Tsialex can with all of our data points).

I'm hopeful that we will get some answers, but this could take time.

To be on the safe side, I'll recommend only BootCamp/CSM Windows installs for now. Seems that 1809 brought back crashes with Mac Pros. We don't need another series of bricks.

 

[bookemdano]

Indeed. If you aren't willing to take some amount of risk it is safer to install for now in legacy mode and just deal with the slower IDE speeds (or use the hack posted earlier to get AHCI).

 

[startergo]

Rebooted to my second HS drive and did another dump:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UEFI PI firmware volume
16524 0x408C UEFI PI firmware volume
24972 0x618C CRC32 polynomial table, little endian
35787 0x8BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
49948 0xC31C UEFI PI firmware volume
524288 0x80000 UEFI PI firmware volume
540812 0x8408C UEFI PI firmware volume
549260 0x8618C CRC32 polynomial table, little endian
560075 0x88BCB mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
574236 0x8C31C UEFI PI firmware volume
1048576 0x100000 UEFI PI firmware volume
1114112 0x110000 UEFI PI firmware volume
1181430 0x1206F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1246966 0x1306F6 Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343511 0x148017 bzip2 compressed data, block size = 100k
1376256 0x150000 UEFI PI firmware volume

The XML files are missing

 

[tsialex]

The XML files are missing

The InstallPhaseList is a log to help Apple support track unsuccessful macOS installs. Seems reasonable that once the install is succeeded, the log is erased, since it's not needed. But is kept if unsuccessful.

Maybe we are finding things that could be unrelated. I'm thinking that SecureBoot and InstallPhaseList are independent and we are finding the InstallPhaseList because we are booting Recovery/USB installer to disable SIP.

I'm not worried with this two or three lines InstallPhaseList that we find after disabling SIP, but the bigger ones that shows unsuccessful installs and are kept between firmware upgrades, like the ones I found into @Macschrauber sequential BootROM dumps from MP41.0081.B07 to 140.0.0.0.0 this week

 

[PianoPro]

Awesome! Thanks for detailing all the steps. I wonder if there's an easier way to get Win10 installed in legacy mode than having to deal with installing Win7 first. I think EFI mode can be effectively removed from an installer by deleting the root EFI folder from the installer drive. Are we required to boot from a DVD to install in legacy mode or can a USB installer be used instead? If DVD is required then I suppose the ISO file can be edited to remove the EFI folder before it is burned.

If you download the iso file, convert it to a .cdr file using Disk Utility (standard practice), and burn to DVD it will boot into the legacy-BIOS mode automatically when you hold the C key while booting. In fact, the problem if you want UEFI mode using a video card without a boot screen is that it won't boot into UEFI mode unless you can use the boot screen. But you don't even need a boot screen to install Win10 in the legacy-BIOS mode.

(The only reason I can think of that the DVD won't boot is if you forget to convert to a .cdr and just try burn the iso to a DVD directly - that will never boot.)

Will Win10 v1809 work now with a UEFI boot? When 1809 was originally released it would not boot back into MacOS unless you did a PRAM reset even if you used one of the Bless 'nextonly' based scripts, or one of the other programs based on 'nextonly' to boot into Win10. And it would not boot back to MacOS using the Win10 Bootcamp control panel either. Those things all worked from v1803, but were broke originally in v1809 (along with a problem of losing files which affected Win10 users not on Macs). Microsoft removed v1809 for about 3 days and then reissued it to fix the "losing file" problem. It was then that I reinstalled Win10 in the legacy-BIOS mode, not because of the potential "BootROM damage" issue. So I don't know if the reissued v1809 now boots back into MacOS when installed in UEFI mode or not. It does work, and always has using legacy-BIOS booting mode.

 

[dvbcheck]

Hello PianoPro,

are you able to modify your script for starting Ubuntu as Startup-Disk (only for the next boot), please?
Which file-system for ubuntu 18.10 would you prefer (on a separate SSD)?

Have a nice weekend.

 

[tsialex]

If you download the iso file, convert it to a .cdr file using Disk Utility (standard practice), and burn to DVD it will boot into the legacy-BIOS mode automatically when you hold the C key while booting. In fact, the problem if you want UEFI mode using a video card without a boot screen is that it won't boot into UEFI mode unless you can use the boot screen. But you don't even need a boot screen to install Win10 in the legacy-BIOS mode.

(The only reason I can think of that the DVD won't boot is if you forget to convert to a .cdr and just try burn the iso to a DVD directly - that will never boot.)

Will Win10 v1809 work now with a UEFI boot? When 1809 was originally released it would not boot back into MacOS unless you did a PRAM reset even if you used one of the Bless 'nextonly' based scripts, or one of the other programs based on 'nextonly' to boot into Win10. And it would not boot back to MacOS using the Win10 Bootcamp control panel either. Those things all worked from v1803, but were broke originally in v1809 (along with a problem of losing files which affected Win10 users not on Macs). Microsoft removed v1809 for about 3 days and then reissued it to fix the "losing file" problem. It was then that I reinstalled Win10 in the legacy-BIOS mode, not because of the potential "BootROM damage" issue. So I don't know if the reissued v1809 now boots back into MacOS when installed in UEFI mode or not. It does work, and always has using legacy-BIOS booting mode.

If you use drutil, you can use the .iso file directly. I always use drutil to burn Windows install DVDs.

 

[PianoPro]

If you use drutil, you can use the .iso file directly. I always use drutil to burn Windows install DVDs.

OK. I was talking about not directly burning the iso from the finder or disk utility.

 

[tsialex]

I was talking about just holding the C key while booting from a DVD, not using the terminal to boot.

I was just suggesting a way to burn the ISO directly, sorry for the off-topic.

 

[PianoPro]

Hello PianoPro,

are you able to modify your script for starting Ubuntu as Startup-Disk (only for the next boot), please?
Which file-system for ubuntu 18.10 would you prefer (on a separate SSD)?

Sorry. I'm not familiar with using ubuntu.

 

[BillyBobBongo]

How did you download BootCamp 6? WHen I use Brigadier.exe it downloads BootCamp 031 from 2011??

/Per

Run it through terminal on the Mac...

brigadier -m iMacPro1,1

...then it downloads 'BootCamp-041-04418'

 

[startergo]

Run it through terminal on the Mac...

brigadier -m iMacPro1,1

...then it downloads 'BootCamp-041-04418'

How did you install it over the old one? It complained that there is another version installed

 

[bookemdano]

How did you install it over the old one? It complained that there is another version installed

What happens if you uninstall the old version and then install 6.1?

 

[PianoPro]

Is it really a good idea to use Bootcamp 6 files targeted at the iMac Pro? I thought I remembered specific hardware dependent files for the Mac Pro in Bootcamp 5. Been a while since I actually looked at them while loading so I may be wrong, but my Win10 seems to work fine with Bootcamp 5 drivers. Perhaps if you load Bootcamp 5 first its hardware specific files aren't overwritten and Bootcamp 6 hardware specific files are disabled?

Someone please enlighten me. I may be remembering this all wrong.

Also you can load individual Bootcamp drivers without loading them all if you know what you want. Are there specific drivers from Bootcamp 6 that we would want to load to support booting back into APFS volumes for instance?

 

[startergo]

What happens if you uninstall the old version and then install 6.1?

If I right click on the bootcamp services in appwiz.cpl nothing pops up. There is no uninstall/repair option

 

[bookemdano]

If I right click on the bootcamp services in appwiz.cpl nothing pops up. There is no uninstall/repair option

Ah this is sounding really familiar now. I recall facing this exact same problem or something similar a year or two ago when I last messed with Bootcamp on my cMP.

Bring up an admin command prompt (If you don't know how to do that, click start, type command then you should see an icon for command prompt. Right click it and choose "Run as administrator".

Then once it comes up, type in this command:

msiexec /x BootCamp.msi

That should uninstall it. Then proceed to install the iMac version.
[doublepost=1540074571][/doublepost]

Is it really a good idea to use Bootcamp 6 files targeted at the iMac Pro? I thought I remembered specific hardware dependent files for the Mac Pro in Bootcamp 5. Been a while since I actually looked at them while loading so I may be wrong, but my Win10 seems to work fine with Bootcamp 5 drivers. Perhaps if you load Bootcamp 5 first its hardware specific files aren't overwritten and Bootcamp 6 hardware specific files are disabled?

Someone please enlighten me. I may be remembering this all wrong.

Also you can load individual Bootcamp drivers without loading them all if you know what you want. Are there specific drivers from Bootcamp 6 that we would want to load to support booting back into APFS volumes for instance?

The nature of drivers is such that if they aren't actually compatible with your hardware Windows will not install them. So while there may be drivers you must install from the Win7 MP51 bootcamp package (I can't remember if there are), if you then subsequently install the iMac Pro bootcamp package it won't install drivers for anything that isn't applicable (same hardware IDs and newer).

Consider that the cMP's bootcamp driver package is targeted for Windows 7 and hasn't been updated in eons. A lot of the hardware in a cMP actually has newer drivers available. Some of it will come via Windows Update, but not everything. By installing a newer Bootcamp driver package you can get Win10-era drivers for several of the devices in your system.

Plus, for folks like me who have installed newer Airport cards to get 802.11ac and BT 4.0, a newer bootcamp driver package is the way to get Windows drivers for that.

But the aim of installing the newer package here isn't for the new set of drivers--it's for the new version of Boot Camp Control Panel, which apparently can now see APFS formatted drives and successfully bless them as the startup disk. That means not having to use any of these workarounds, no disabling of SIP, etc.

There is very little risk involved, but if you wanted to try it it never hurts to make a backup beforehand.

 

[startergo]

Ah this is sounding really familiar now. I recall facing this exact same problem or something similar a year or two ago when I last messed with Bootcamp on my cMP.

Bring up an admin command prompt (If you don't know how to do that, click start, type command then you should see an icon for command prompt. Right click it and choose "Run as administrator".

Then once it comes up, type in this command:

msiexec /x BootCamp.msi

That should uninstall it. Then proceed to install the iMac version.

Thanks that worked. But I had to find the right BootCamp.msi for the uninstall.

 

[PianoPro]

The nature of drivers is such that if they aren't actually compatible with your hardware Windows will not install them. So while there may be drivers you must install from the Win7 MP51 bootcamp package (I can't remember if there are), if you then subsequently install the iMac Pro bootcamp package it won't install drivers for anything that isn't applicable (same hardware IDs and newer).

Consider that the cMP's bootcamp driver package is targeted for Windows 7 and hasn't been updated in eons. A lot of the hardware in a cMP actually has newer drivers available. Some of it will come via Windows Update, but not everything. By installing a newer Bootcamp driver package you can get Win10-era drivers for several of the devices in your system.

Plus, for folks like me who have installed newer Airport cards to get 802.11ac and BT 4.0, a newer bootcamp driver package is the way to get Windows drivers for that.

But the aim of installing the newer package here isn't for the new set of drivers--it's for the new version of Boot Camp Control Panel, which apparently can now see APFS formatted drives and successfully bless them as the startup disk. That means not having to use any of these workarounds, no disabling of SIP, etc.

There is very little risk involved, but if you wanted to try it it never hurts to make a backup beforehand.

Thanks for the very good explanation. I was guessing the newer, incompatible drivers might be ignored. Good to know that's the case.

I think I'll try installing ver 6 then to get the newer Boot Camp Control Panel. It is a pain using the 'nextonly' blessing when Windows wants to install updates and reboot itself (which happens too often). I'll modify my script to boot into Windows so the user can choose to use 'nextonly' or not use it, just as I do for booting into other Mac OS's. The advantage of using the script is still to avoid having to type in a password to use the Startup Disk preference pane to boot into Windows.
[doublepost=1540077436][/doublepost]

Thanks for the very good explanation. I was guessing the newer, incompatible drivers might be ignored. Good to know that's the case.

But then do I really want to uninstall the ver 5 drivers? Will anything Mac Pro specific be missed in version 6 drivers since it was never released for the Mac Pro? If it won't install over the top of ver 5 perhaps it will install specific ver 6 drivers individually?