Contribute
Register

SOLVED Multibooting High Sierra and 2 Win 10 systems all on 3 seperate drives;

Status
Not open for further replies.
Joined
Nov 4, 2011
Messages
675
Motherboard
Gigabyte GA-Z170X-UD3 F23g
CPU
i7-6700K
Graphics
RX 580
Mac
  1. iMac
Hi all.
I have a situation/dream which I cannot find anything to read about.
I want to triple boot My Haswell High Sierra installation with 2 Windows 10 systems all on 3 separate drives.
The 2 Windows 10 installations can dual boot among themselves, using the standard Windows bootloader, whereas for High Sierra I use Clover version 4522 in single boot mode only.
Kindly note that the Win 10 installations are on GPT prepared drives, with each having an empty Fat32 formated 209 MB EFI partition.
For clarity I have attached a screenshot of the partition layout for this build.
I figured that one should be able to utilize the empty windows EFI partitions, place some code in there, then integrate that with Clover and voila a clean triple boot system would be the result, perhaps even bypassing the Windows bootloader.
Kindly note that my request is not about installing High Sierra or 2 times Windows 10. that has already been done.
I was thinking of using a variation of the following command, "bcdboot c:\Windows /s C: /f uefi", to generate the Windows boot files needed by Clover. The problem is that I have 2 Windows installations and I am unable to figure out how to handle that with this singular command construct.

I would really appreciate some assistance with this, hoping of cause that what I wish to end up with is actually doable.

Greetings
 

Attachments

  • Haswell High Sierra Partition layout.jpeg
    Haswell High Sierra Partition layout.jpeg
    268.9 KB · Views: 161
bcdboot c:\Windows /s C: /f uefi
You will be installing the UEFI boot files / bcd store to your C: drive with that command. You can assign one of the EFI partitions a drive letter e.g. S: then
Code:
bcdboot c:\Windows /s S: /f uefi
There is an /m option for merging the current loader in a given bcdstore with the OS specified in the command.
Optional. Merges the values from an existing boot entry into a new boot entry.

By default, this option merges only global objects. If you specify an OS Loader GUID, this option merges the loader object in the system template to produce a bootable entry.

You'd think that running bcdboot a second time with the /m option, while booted from your other Windows installation, having assigned the same EFI partition the letter
Code:
bcdboot c:\Windows /s S: /f uefi /m
would setup the 2 entries from a single Windows boot loader instance. I've not tried this.

Or you could assign the EFI partition on each Windows drive separately, installing the files twice. Specifying the /s option means the bcdstore should be independent of the NVRAM optional data - you should be able to create 3 simple entries in the firmware boot menu using e.g. linux efibootmgr and set the order as you please.

By default, BCDBoot creates a Windows Boot Manager entry in the NVRAM on the firmware to identify the boot files on the system partition. If the /s option is used, then this entry is not created.
https://docs.microsoft.com/en-us/wi...sktop/bcdboot-command-line-options-techref-di

If your thinking of booting each Windows installation separately via Clover, maybe the second way will be easier. Clover can see the 2 bootmgfw.efi loaders on the FAT partitions and show 2 Windows entries in the menu.
 
You will be installing the UEFI boot files / bcd store to your C: drive with that command. You can assign one of the EFI partitions a drive letter e.g. S: then
Code:
bcdboot c:\Windows /s S: /f uefi
There is an /m option for merging the current loader in a given bcdstore with the OS specified in the command.


You'd think that running bcdboot a second time with the /m option, while booted from your other Windows installation, having assigned the same EFI partition the letter
Code:
bcdboot c:\Windows /s S: /f uefi /m
would setup the 2 entries from a single Windows boot loader instance. I've not tried this.

Or you could assign the EFI partition on each Windows drive separately, installing the files twice. Specifying the /s option means the bcdstore should be independent of the NVRAM optional data - you should be able to create 3 simple entries in the firmware boot menu using e.g. linux efibootmgr and set the order as you please.


https://docs.microsoft.com/en-us/wi...sktop/bcdboot-command-line-options-techref-di

If your thinking of booting each Windows installation separately via Clover, maybe the second way will be easier. Clover can see the 2 bootmgfw.efi loaders on the FAT partitions and show 2 Windows entries in the menu.
Wow and thank you @vulgo that was really quick, thorough and exactly what I was looking for. I am going to start working on this after I had some good rest . It is past midnight here and I am too tired to tackle this now, although I am tempted. Continuing now carries the risk of me messing things up good and solid. :)

Incidentally I am still using your local.pmset.plist file in /Library/LaunchDaemons. I also rate that as a great jewel that you provided very long ago..

Will come back as soon as I have made progress, I would most likely need some more help along the way, glad you are around and willing to share your knowledge.

Cheers for now and keep well.
 
If you have both Windows partitions mounted you should be able to bcdboot twice without rebooting, replace c:\Windows with the drive letter windows has assigned to the other installation e.g.
Code:
bcdboot C:\Windows /s S: /f uefi
bcdboot F:\Windows /s S: /f uefi /m
Or
Code:
bcdboot C:\Windows /s S: /f uefi
bcdboot F:\Windows /s T: /f uefi
 
Last edited:
If you have both Windows partitions mounted you should be able to bcdboot twice without rebooting, replace c:\Windows with the drive letter windows has assigned to the other installation e.g.
Code:
bcdboot C:\Windows /s S: /f uefi
bcdboot F:\Windows /s S: /f uefi /m
Or
Code:
bcdboot C:\Windows /s S: /f uefi
bcdboot F:\Windows /s T: /f uefi
Hi @vulgo Apologies for having not been able to follow your suggestions up earlier however circumstances beyond my control dictated that I suddenly had to be away from base. Back to the subject matter.
I got triple booting working without using any of the bcdboot..... constructs as they seem not to work for me with the latest version of Windows on my machine.
After all the solution is rather much simpler than running that code. In order to be able to triple boot with macOS and 2 Windows installations each one on their own SSD or HDD my advice is as follows:

Disable/remove the ability to boot macOS
Concentrate on dual booting GPT/EFI Windows and get that working - not difficult at all.
Enable macOS to boot again and do so.
Once macOS has run up mount the 2 EFI partition belonging to Windows. In one of them you will find the BCD bootcode required to dual boot Windows. Place those files on your desktop and delete the contents of both the Windows EFI folders - in other words clean them out :)
The Windows BCD store - yes that is what the code on your desktop seems to be called, contains among other
a bootx64.efi file. Rename that file to bootx64-win.efi and then copy/paste that into the macOS EFI/BOOT folder where it will now reside alongside an existing BOOTX64.efi required by macOS. Next place the Microsoft folder, which should also be among the items that were copied to the desktop, inside your macOS EfI folder. Now you are basically done. Happy triple booting with macOS and the 2 Windows GPT/EFI installations.

For clarity consult the attached screenshots.

To be noted is that access to the Microsoft EFI folders from within Windows is rather cumbersome and can only be accomplished in a rather difficult and roundabout way, macOS fortunately comes to the rescue here.

The clover Boot menu should/can now be cleaned so that only items that one wants to show are visible.
A screenshot what I prefer to see when I boot has also been attached.

Another caveat is that this boot method is problematic when one tries to return from Windows to macOS. A solution seems to be to disable the internal Intel GPU which was originally configured with a connectorless framebuffer in order to enable hardware decoding. Upon return from Windows to macOS Windows seems to have changed something which can only be undone with a cold boot or diasbling the IGPU in bios, a shot in ones own foot so to say. I am still in search for a fix for this, maybe you can assist. In the meantime I have temporarily disabled the internal IGPU as I am not hardware decoding very often and when I do need the feature I just enable it temporarily in bios again.

Greetings on the dawn of the WC.
 

Attachments

  • macOS EFI BOOT folder.jpeg
    macOS EFI BOOT folder.jpeg
    41.3 KB · Views: 162
  • Placement of Microsoft folder.jpeg
    Placement of Microsoft folder.jpeg
    71.9 KB · Views: 162
  • Result.png
    Result.png
    696.6 KB · Views: 168
To be noted is that access to the Microsoft EFI folders from within Windows is rather cumbersome and can only be accomplished in a rather difficult and roundabout way, macOS fortunately comes to the rescue here.
It's the only way to configure them from Windows unfortunately. Your setup is now probably close to the Windows default - using the one EFI partition or defaulting to the booted-from one (apart from the extra ESPs that got created at whatever point)
Upon return from Windows to macOS Windows seems to have changed something which can only be undone with a cold boot or diasbling the IGPU in bios
If its Windows maybe disable the IGPU there so it doesn't try to use it.
 
It's the only way to configure them from Windows unfortunately. Your setup is now probably close to the Windows default - using the one EFI partition or defaulting to the booted-from one (apart from the extra ESPs that got created at whatever point)
If its Windows maybe disable the IGPU there so it doesn't try to use it.
Hi @vulgo You are correct with your suggestion to disable it in Windows just trying to figure out if there is a way to accomplish that. Disabling it in bios has global ramifications.
I don't believe extra ESP's were created as each Windows was installed on it's own HDD which thus created one ESP for each Windows installation, adding those 2 to the one created when macOS was installed leaves me with 3 ESP's in total of which only the macOS ESP contains boot code, the Windows ESP's are empty each of 200 MB size. They come in handy should one ever wish to boot Windows without macOS being present. One just needs to transfer the BCD code currently in the macOS ESP to one of the Widows's ESPs first, before that will work, or alternatively create new code with the bcdboot command, of which in the interim I have read all about, and now understand it's capabilities. There is a switch that has something to do with the handling of NVRAM when one creates new bcd boot, code will try that once I can get around to experiment again, presently the WC in Moskau is top of my agenda :)
Greets
 
Hi @vulgo You are correct with your suggestion to disable it in Windows just trying to figure out if there is a way to accomplish that. Disabling it in bios has global ramifications.
I don't believe extra ESP's were created as each Windows was installed on it's own HDD which thus created one ESP for each Windows installation, adding those 2 to the one created when macOS was installed leaves me with 3 ESP's in total of which only the macOS ESP contains boot code, the Windows ESP's are empty each of 200 MB size. They come in handy should one ever wish to boot Windows without macOS being present.
The Windows installer doesn't always create a new ESP. Most people seem to want each OS bootloader installed to the same disk as the root volume (or C: drive). I assumed that was what you were trying to do.
One just needs to transfer the BCD code currently in the macOS ESP to one of the Widows's ESPs first, before that will work, or alternatively create new code with the bcdboot command, of which in the interim I have read all about, and now understand it's capabilities. There is a switch that has something to do with the handling of NVRAM when one creates new bcd boot, code will try that once I can get around to experiment again, presently the WC in Moskau is top of my agenda :)
Greets
/s is supposed to store all data on disk and not in the 'Windows Boot Manager' NVRAM optional data - also regarding /s the docs mention expecting to be booted from the default/fallback path in /EFI/BOOT - though from Clover you should always be loading from the /Microsoft/Boot path. Once you have the expected behaviour for your particular setup/invocation of bcdboot (NVRAM options, file locations/overwrites) you can configure everything else, Clover etc. around it - the bcd process may be repeated during Windows updates and if the data, files etc. don't add up the automated process may fail. It's not really user configurable outside of the command line utils.
 
The Windows installer doesn't always create a new ESP. Most people seem to want each OS bootloader installed to the same disk as the root volume (or C: drive). I assumed that was what you were trying to do.
Yes that is what I prefer my setup to be so that each OS has it's own ESP to fallback on, should the need arise.
Have switched back to triple booting via the bios boot control menu, F12 in my case. Each Windows now has it's own BCD code. In the interim other problems have surfaced, such as when returning from any of the windows to macOS sound is missing and the NIC is sometimes not properly initialized. These symptoms seem to suggest that Windows is highjacking macOS's NVRAM, hence these undesirable side effects. This can only be fixed by cold booting back to macOS once done with Windows. Will investigate the /s switch to see whether that can solve the issue. With the 3 ESP's it is quite easy to switch to different boot modes.
Greets
 
These symptoms seem to suggest that Windows is highjacking macOS's NVRAM
BCD NVRAM data is stored in the firmware boot menu in the 'Windows Boot Manager' entry (if it is there) so /s switch shouldn't effect any other global variables. I believe the data points to a GUID in the on-disk store, there is also bootloader recovery information on disk. Hence everything should be generated by the tool or automatically by Windows - if you change things it may try to change them back, if it can't it may end up not booting until everything has been regenerated.

Your hardware problems might be related to firmware itself and settings, are all fast boot options and other Windows features turned off?
 
Status
Not open for further replies.
Back
Top