Jump to content

Multiple OSs on individual SSDs


sji260
 Share

17 posts in this topic

Recommended Posts

I have macOS 11.5.2 running under OC 0.7.2 on one SSD and Windows 10 Pro on a separate SSD; they live together without issue and I can access them as needed via the OC bootloader. However, if I try and install a Linux distro on a third SSD it breaks macOS, i.e. macOS will no longer boot from the OC bootloader. Additionally, upon restart, several of my HDDs disappear and can only be retrieved with with a Cmos reset. I assume this is an EFI/grub issue but don't have the expertise to fix it. Is anyone successfully running the three OSs? If yes I'd love to know how.

 

Stephen

Link to comment
Share on other sites

Make certain you disconnect the drives while you install Linux then that piece of garbage GRUB will not have the opportunity to clobber your other boot loaders. The installers lie to you and tell you it will install it to the drive you select for that, but if it is not the first drive seen by the system it will go ahead and install it there (on the first drive it sees) no matter what it is told to do. My spare machine has the three on it and I was rather disappointed when discovering this behaviour on installing the Linux. Alternatively you can backup the first drives EFI before installing the Linux then once done restore the /boot folder in that backup to the EFI partition then you get back your OC on that drive that will be there but the bootx64.efi I think it is named will be overwritten by the GRUB boot loader as is the case with all OS installs. That file is the default loader for a 64 bit system all OSs write to have the machine boot. Or you could use the efibootmanager to add entries to your NVRAM to enable all the drives you have in the machine, this works well and is what I did to do my triple booting.

 

Edit: The efibootmgr is a linux program sample output from my installing of the linux from my notes. It show the commands needed to list, change the order and add an entry, this was before I got the windows on there.

 


root@zeus-H370M:~# efibootmgr -v
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0004,0000,0005
    Boot0000* OpenCore    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\OC\OPENCORE.EFI)
    Boot0004* ubuntu    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\UBUNTU\SHIMX64.EFI)
    Boot0005* UEFI OS    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
    root@zeus-H370M:~# efibootmgr -c -d /dev/sda  -L "MemTest86" -l '\EFI\memtest86\BOOTX64.EFI'
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0001,0004,0000,0005
    Boot0000* OpenCore
    Boot0004* ubuntu
    Boot0005* UEFI OS
    Boot0001* MemTest86
    root@zeus-H370M:~# efibootmgr -v
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0001,0004,0000,0005
    Boot0000* OpenCore    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\OC\OPENCORE.EFI)
    Boot0001* MemTest86    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\memtest86\BOOTX64.EFI)
    Boot0004* ubuntu    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\UBUNTU\SHIMX64.EFI)
    Boot0005* UEFI OS    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
    root@zeus-H370M:~# efibootmgr -o 0004,0000,0005,0001
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0004,0000,0005,0001
    Boot0000* OpenCore
    Boot0001* MemTest86
    Boot0004* ubuntu
    Boot0005* UEFI OS


Edited by MacUser2525
additional information
Link to comment
Share on other sites

2 hours ago, sji260 said:

I have macOS 11.5.2 running under OC 0.7.2 on one SSD and Windows 10 Pro on a separate SSD; they live together without issue and I can access them as needed via the OC bootloader. However, if I try and install a Linux distro on a third SSD it breaks macOS, i.e. macOS will no longer boot from the OC bootloader. Additionally, upon restart, several of my HDDs disappear and can only be retrieved with with a Cmos reset. I assume this is an EFI/grub issue but don't have the expertise to fix it. Is anyone successfully running the three OSs? If yes I'd love to know how.

 

Stephen

There is no reason for a linux install to disrupt your bootloader configuration.  If you have an existing bootloader, there is no need to even install GRUB2 when installing linux.  GRUB2 works fine as a main bootloader and you can chainload Open Core, Clover, Linux, Android, and even Refind bootmanager.  With GRUB2 you don't have to be concerned with injecting unwanted parameters into the windows boot process.

 

There is also no need to have Mac OS, windows and linux on different SSDs.  They can all coexist on the same SSD.

 

GRUB2, Open Core, Clover and Refind can all exist on the same ESP.

 

See here for more information:

https://www.insanelymac.com/forum/topic/346639-updated-tips-and-observations-for-big-sur-and-monterey/

 

Link to comment
Share on other sites

4 hours ago, MacUser2525 said:

Make certain you disconnect the drives while you install Linux then that piece of garbage GRUB will not have the opportunity to clobber your other boot loaders. The installers lie to you and tell you it will install it to the drive you select for that, but if it is not the first drive seen by the system it will go ahead and install it there (on the first drive it sees) no matter what it is told to do. My spare machine has the three on it and I was rather disappointed when discovering this behaviour on installing the Linux. Alternatively you can backup the first drives EFI before installing the Linux then once done restore the /boot folder in that backup to the EFI partition then you get back your OC on that drive that will be there but the bootx64.efi I think it is named will be overwritten by the GRUB boot loader as is the case with all OS installs. That file is the default loader for a 64 bit system all OSs write to have the machine boot. Or you could use the efibootmanager to add entries to your NVRAM to enable all the drives you have in the machine, this works well and is what I did to do my triple booting.

 

Edit: The efibootmgr is a linux program sample output from my installing of the linux from my notes. It show the commands needed to list, change the order and add an entry, this was before I got the windows on there.

 

 


root@zeus-H370M:~# efibootmgr -v
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0004,0000,0005
    Boot0000* OpenCore    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\OC\OPENCORE.EFI)
    Boot0004* ubuntu    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\UBUNTU\SHIMX64.EFI)
    Boot0005* UEFI OS    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
    root@zeus-H370M:~# efibootmgr -c -d /dev/sda  -L "MemTest86" -l '\EFI\memtest86\BOOTX64.EFI'
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0001,0004,0000,0005
    Boot0000* OpenCore
    Boot0004* ubuntu
    Boot0005* UEFI OS
    Boot0001* MemTest86
    root@zeus-H370M:~# efibootmgr -v
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0001,0004,0000,0005
    Boot0000* OpenCore    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\OC\OPENCORE.EFI)
    Boot0001* MemTest86    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\memtest86\BOOTX64.EFI)
    Boot0004* ubuntu    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\UBUNTU\SHIMX64.EFI)
    Boot0005* UEFI OS    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
    root@zeus-H370M:~# efibootmgr -o 0004,0000,0005,0001
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0004,0000,0005,0001
    Boot0000* OpenCore
    Boot0001* MemTest86
    Boot0004* ubuntu
    Boot0005* UEFI OS


 

Thank you for the great information. This is exactly what I experience! The issue with disconnecting drives is that they are all SSDs installed on the motherboard, makes disconnecting them problematic. For background, I have: MSI MEG Z490 Godlike motherboard, XFX Radeon RX6900XT GPU, 64GB G.SKILL RAM, Intel Core i9 10900K CPU, M.2 Xpander-Z Gen4 S card, 5x 1TB SSDs, 3x 4TB HDDs, Corsair HX1200i PSU. This is my video editing, graphic arts setup. There are select programs in each OS, Windows, macOS and Linux, that are the best for what I do hence my desire to have each OS on my machine. For Windows, I used WinToUSB to install the OS on an external SSD, then took my machine apart to install that SSD in one of my MB's M.2 slots. That why Windows works. I tried the same method with Linux, but as soon as it boots into that SSD chaos ensues on my other drives. It's really frustrating.  

Link to comment
Share on other sites

1 hour ago, sji260 said:

Thank you for the great information. This is exactly what I experience! The issue with disconnecting drives is that they are all SSDs installed on the motherboard, makes disconnecting them problematic. For background, I have: MSI MEG Z490 Godlike motherboard, XFX Radeon RX6900XT GPU, 64GB G.SKILL RAM, Intel Core i9 10900K CPU, M.2 Xpander-Z Gen4 S card, 5x 1TB SSDs, 3x 4TB HDDs, Corsair HX1200i PSU. This is my video editing, graphic arts setup. There are select programs in each OS, Windows, macOS and Linux, that are the best for what I do hence my desire to have each OS on my machine. For Windows, I used WinToUSB to install the OS on an external SSD, then took my machine apart to install that SSD in one of my MB's M.2 slots. That why Windows works. I tried the same method with Linux, but as soon as it boots into that SSD chaos ensues on my other drives. It's really frustrating.  

Even booting from a live USB of Manjaro, but not installing anything; upon reboot into macOS, 2 of my HDDs and my TimeMachine backup disk have been unmounted! It takes a CMOS reset to get everything back!

Link to comment
Share on other sites

2 hours ago, sji260 said:

Thank you for the great information. This is exactly what I experience! The issue with disconnecting drives is that they are all SSDs installed on the motherboard, makes disconnecting them problematic. For background, I have: MSI MEG Z490 Godlike motherboard, XFX Radeon RX6900XT GPU, 64GB G.SKILL RAM, Intel Core i9 10900K CPU, M.2 Xpander-Z Gen4 S card, 5x 1TB SSDs, 3x 4TB HDDs, Corsair HX1200i PSU. This is my video editing, graphic arts setup. There are select programs in each OS, Windows, macOS and Linux, that are the best for what I do hence my desire to have each OS on my machine. For Windows, I used WinToUSB to install the OS on an external SSD, then took my machine apart to install that SSD in one of my MB's M.2 slots. That why Windows works. I tried the same method with Linux, but as soon as it boots into that SSD chaos ensues on my other drives. It's really frustrating.  

 

 

Two of mine are on nvm-e M.2 slots too, it is a pain to take them out but that is the only safe way to get it done. What you describe with the CMOS mess up should not be happening are you certain it is installing in EFI mode. Look in the firmware for a setting to disable the CSM compatibility.

Link to comment
Share on other sites

I am having the same problem and confirm that it helps to disconnect the drives while installing Linux. This is easy to accomplish in bios for drives that use the SATA controller, however operating systems in NVMe M.2 slots pose a problem because it basically requires one to strip down the system in order to isolate those drives, which during the initial installation of Linux, is nevertheless highly recommended. Whenever one updates Linux later and a kernel update is part to that one faces the same problem all over. Grub just grabs whatever it can get hold of and makes itself at home. The relatively frequent kernel updates make it sort of impractical to strip down the system whenever it becomes evident that updated kernel code is included in the Linux update/upgrade process. I wish there was an easier way to sidestep this problem, which one experiences with a standard linux installation configured as one of the multi  OpenCore/OpenCanopy boot options. 

 

Greetings Henties   

 

Link to comment
Share on other sites

8 hours ago, Henties said:

I am having the same problem and confirm that it helps to disconnect the drives while installing Linux. This is easy to accomplish in bios for drives that use the SATA controller, however operating systems in NVMe M.2 slots pose a problem because it basically requires one to strip down the system in order to isolate those drives, which during the initial installation of Linux, is nevertheless highly recommended. Whenever one updates Linux later and a kernel update is part to that one faces the same problem all over. Grub just grabs whatever it can get hold of and makes itself at home. The relatively frequent kernel updates make it sort of impractical to strip down the system whenever it becomes evident that updated kernel code is included in the Linux update/upgrade process. I wish there was an easier way to sidestep this problem, which one experiences with a standard linux installation configured as one of the multi  OpenCore/OpenCanopy boot options. 

 

Greetings Henties   

 

 

Should be good on the updates, like all systems out there the one thing GRUB does right is use the UUIDs for the drive partitions in its installed configuration files to use upon update. The problem is the initial install where it just does whatever the hell it wants to do regardless of the setting chosen for it. At least that has been my experience with it the Ubuntu in that machine that has indeed updated the kernel many times leading to a GRUB re-install with the other loaders left alone during this by using the mounted /boot/efi for the updating location. My install is on SSD the macOS and  Windows on the nvm-e drives which are seen as number one and two by the system.

 

Edit: and just to be sure I turned it on and checked the other drives boot loaders after the kernel update it installed last night, they are still both intact. Apparently updated me to 20.04.3 as well up from the .2 it showed in the console login to it yesterday now upped by a new .1.

 

Edited by MacUser2525
additional information
Link to comment
Share on other sites

4 hours ago, MacUser2525 said:

 

Should be good on the updates, like all systems out there the one thing GRUB does right is use the UUIDs for the drive partitions in its installed configuration files to use upon update. The problem is the initial install where it just does whatever the hell it wants to do regardless of the setting chosen for it. At least that has been my experience with it the Ubuntu in that machine that has indeed updated the kernel many times leading to a GRUB re-install with the other loaders left alone during this by using the mounted /boot/efi for the updating location. My install is on SSD the macOS and  Windows on the nvm-e drives which are seen as number one and two by the system.

 

Edit: and just to be sure I turned it on and checked the other drives boot loaders after the kernel update it installed last night, they are still both intact. Apparently updated me to 20.04.3 as well up from the .2 it showed in the console login to it yesterday now upped by a new .1.

 

 

4 hours ago, MacUser2525 said:

 

Should be good on the updates, like all systems out there the one thing GRUB does right is use the UUIDs for the drive partitions in its installed configuration files to use upon update. The problem is the initial install where it just does whatever the hell it wants to do regardless of the setting chosen for it. At least that has been my experience with it the Ubuntu in that machine that has indeed updated the kernel many times leading to a GRUB re-install with the other loaders left alone during this by using the mounted /boot/efi for the updating location. My install is on SSD the macOS and  Windows on the nvm-e drives which are seen as number one and two by the system.

 

Edit: and just to be sure I turned it on and checked the other drives boot loaders after the kernel update it installed last night, they are still both intact. Apparently updated me to 20.04.3 as well up from the .2 it showed in the console login to it yesterday now upped by a new .1.

 

GRUB replaces whatever is stored in esp/EFI/BOOT/BOOTX64.efi. That's why it destroys my macOS SSD. It even happens when booting from a live Linux USB. Unless GRUB can be completely disabled and use Opencore as the bootloader for all OSs I think I'm stuck. It's too bad the Linux community makes it so difficult to have multiple OSs on different storage devices. One of the many things they need to fix to gain wider desktop adoption, in my opinion.

Link to comment
Share on other sites

@sji260 I concur wholeheartedly because at the moment grub attempts to "rule the world" I have dabbled with linux's "efibootmgr" and actually got it working. The drawback using "efibootmgr" seems to me that it is dependent on variables set in NVRAM, the consequences of which I am in the process of investigating.

 

Greetings Henties

Link to comment
Share on other sites

4 hours ago, sji260 said:

 

GRUB replaces whatever is stored in esp/EFI/BOOT/BOOTX64.efi. That's why it destroys my macOS SSD. It even happens when booting from a live Linux USB. Unless GRUB can be completely disabled and use Opencore as the bootloader for all OSs I think I'm stuck. It's too bad the Linux community makes it so difficult to have multiple OSs on different storage devices. One of the many things they need to fix to gain wider desktop adoption, in my opinion.

 

I have already mentioned that file in my original post I do believe it was. When installed GRUB replaces the mounted /boot/efi file when it upgrades itself, for your booting problem it destroys nothing, you are having some kind of corruption of the firmware/BIOS in the machine. Which quite frankly I have never seen or heard of before really, not from a simple booting of a live distro. That is a self contained operation that uses only the files on the cd, dvd or usb stick. Now my experience with it is the damn thing clobbers the boot loader in the first drive in the system upon install like Windows does too, it is not only Linux that does this. OC since anyone installing had to do the install to the ESPs efi directory partition chosen, you only have yourself to blame for any clobbering done there if a mistake was made.

Link to comment
Share on other sites

2 hours ago, Henties said:

@sji260 I concur wholeheartedly because at the moment grub attempts to "rule the world" I have dabbled with linux's "efibootmgr" and actually got it working. The drawback using "efibootmgr" seems to me that it is dependent on variables set in NVRAM, the consequences of which I am in the process of investigating.

 

Greetings Henties

 

It certainly is dependant on the NVRAM that is the whole point of it being there to preserve your settings on reboot. Allowing you to set your preferred boot order among other things without having to use in my case, the F12 key, to get the boot menu to change the default for another OS on the system to boot from for that time. I am no fan of the piece of junk GRUB, it exhibits the same behaviour as Windows does. There is no justification for it, the setting is there on all installs I have seen for the place for the boot loader to be installed to and it does not respect and use it in any of them.

Link to comment
Share on other sites

On 8/24/2021 at 2:50 PM, MacUser2525 said:

 

It certainly is dependant on the NVRAM that is the whole point of it being there to preserve your settings on reboot. Allowing you to set your preferred boot order among other things without having to use in my case, the F12 key, to get the boot menu to change the default for another OS on the system to boot from for that time. I am no fan of the piece of junk GRUB, it exhibits the same behaviour as Windows does. There is no justification for it, the setting is there on all installs I have seen for the place for the boot loader to be installed to and it does not respect and use it in any of them.

I just completed an installation of Zorin OS 16 Pro, to an internal SSD. Unlike every other distro I've tried, this one didn't mess with my bootloader. Windows and macOS still appear in the Opencore bootloader and both work fine. I wonder what they've done differently.

Link to comment
Share on other sites

1 hour ago, sji260 said:

I just completed an installation of Zorin OS 16 Pro, to an internal SSD. Unlike every other distro I've tried, this one didn't mess with my bootloader. Windows and macOS still appear in the Opencore bootloader and both work fine. I wonder what they've done differently.

 

The correct thing for a change in an installer, respect the choice of where to install the boot loader. Shocking just about a first in my experience which is why I always disconnect the drives. Leaving a nvm-e connected  during the Ubuntu install reminded me why I do this the last time I installed a few months ago. I had thought the SSD would be the drive it would see as the first, silly me for thinking that.

Link to comment
Share on other sites

With OpenCore 0.6.6 and newer, we are now able to launch OpenCore directly from our firmwares without needing a launcher (Bootstrap.efi or BOOTx64.efi) as an intermediary. This allows us to add OpenCore to our motherboard's boot menu and prevent issues where either Windows or Linux try to overwrite the EFI/BOOT/BOOTx64.efi path, which can happen when installing or updating Windows and therefore breaking OpenCore's ability to boot.

https://dortania.github.io/OpenCore-Post-Install/multiboot/bootstrap.html

Link to comment
Share on other sites

Indeed from my spare machine notes.

 


root@zeus-H370M:~# efibootmgr -v
    BootCurrent: 0004
    Timeout: 2 seconds
    BootOrder: 0001,0004,0000,0005
    Boot0000* OpenCore    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\OC\OPENCORE.EFI)
    Boot0001* MemTest86    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\memtest86\BOOTX64.EFI)
    Boot0004* ubuntu    HD(1,GPT,9fad4e77-177d-4a3c-929a-3897e6bc1810,0x28,0x64000)/File(\EFI\UBUNTU\SHIMX64.EFI)
    Boot0005* UEFI OS    HD(1,GPT,f2d84cb4-e597-4ac4-a2b2-10f0351c8784,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

 

If ever needing to add to the menu then something like this will work adjusted to the entry you need.

 


root@zeus-H370M:~# efibootmgr -c -d /dev/sda  -L "MemTest86" -l '\EFI\memtest86\BOOTX64.EFI'

 

Link to comment
Share on other sites

I'm getting the following message when I try and boot into Zorin OS from my Opencore boot loader. Any suggestions how to fix? I can boot into Zorin by pressing the F11 key and choosing the ubuntu disk, so it's not the end of the world if I can't fix it.IMG_0451.thumb.jpeg.af9221cdbc3046c91a9a2cb950cba7e4.jpeg

IMG_0450.thumb.jpeg.bfede58bf41f36642acb00042e800858.jpeg

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...