Contribute
Register

Multi booting on one drive - adding macOS deletes the Windows EFI partition

Status
Not open for further replies.
Joined
Nov 28, 2021
Messages
7
Motherboard
Dell Inspiron 7520 4P57C
CPU
i7-3612QM
Graphics
Intel HD 4000 Integrated
I start out with a 1TB Sata SSD and the first partition on the drive is a Windows EFI partition then Windows then Manjaro root and Manjaro home... these are dual booting fine with Grub2. I want to use Grub to chain load Opencore so all three OSs can be on the Grub menu and I don't get any kext etc injection from Opencore in to Windows and Manjaro.

Now if I use Disk Utility from a macOS Catalina USB installer and clone in a macOS installation that is working on another drive this causes the Windows EFI partition to get deleted. Why is this? Even if I first had created a second 200MiB EFI just for macOS on the drive in a partition just before where macOS will be cloned in to (and set its flags to boot, esp).

If I start with macOS on the drive first and then clone in the Windows/Manjaro partitions using Macrium no EFI partition is deleted and everything works... yes even with two EFI partitions on the drive and both are labelled: boot, esp.

So why does cloning macOS to a drive that already has Windows delete the Windows EFI partition and anyway do I need both EFI partitions or will Windows 10, Manjaro and Catalina/Opencore bootloaders co-exist just fine on the one EFI partition? Will Windows or other OS updates break things maybe?

Cheers,

Flex
 
So why does cloning macOS to a drive that already has Windows delete the Windows EFI partition
Probably the difference between the two methods/tools you're using and how they clone. Use whichever one you prefer to get the operating systems arranged to your liking. The Macrium option sounds the easiest since nothing's lost.
and anyway do I need both EFI partitions or will Windows 10, Manjaro and Catalina/Opencore bootloaders co-exist just fine on the one EFI partition?
No to the first and yes to the second. There need only be one EFI partition on a disk and it can contain multiple boot loaders.
Will Windows or other OS updates break things maybe?
Possibly. Since you're planning on using Grub that should remain active even through Linux/Windows updates. See how it goes.
 
When you write "clone" do you mean Disk Utility Restore?
 
Re Manjaro you will need to diff its EFI against OC. I would not expect to mix Windows EFI with OC, except that Windows has evolved to coexist with Linux as multiboot environments have been around for decades and Microsoft is Embracing Linux, which is always the first step in MSFT EEE plans (embrace, extend, extinguish)

For a cross-reference, Ubuntu Unity installer doesn't co-exist with OC EFI, it will overwrite OC BOOTx64.efi, sometimes even on drives unrelated to drive Ubuntu was installed upon. Also moving an Ubuntu installation to another drive or partition can have unexpected effects because Unity remembers previous in GRUB config.
 
First @jpz4085 was putting my mind at ease and now @c-o-pr is making me worry again!
Just kidding, actually I'm glad you asked me those questions @c-o-pr because that's exactly what I am wondering about right now.

I am making a multiboot system tonight. I used Macrium to clone the partitions from a working Win10/Manjaro dual boot to a new drive. During this process I re-sized the "Windows" EFI partition to 500MB as previously I've had alot of trouble with macOS actually deleting my EFI partition when I used Disk Utility to make any changes to the drives partition structure (e.g: erasing, restoring)

On yet another drive I have a working macOS Catalina install. With the Windows/Manjaro cloned drive in my laptop I connected the other macOS drive then booted into macOS recovery via an Opencore USB installer and from Disk Utility I "restored" the macOS from the macOS only drive into a blank partition on the clone drive AFTER the Manjaro home partition.

After this I want to copy the Opencore EFI partition files to the "Windows" EFI partition on the cloned disk.

So far I copied the /EFI/OC folder from the working macOS Catalina hackintosh installation over to the "Windows" EFI partition in /EFI/..

But there is also a /EFI/Boot folder in Opencore with a bootx64.efi file in it. Am I supposed to copy that over to the "Windows" EFI partition into its /EFI/Boot folder and overwrite the bootx64.efi file inside?

For now I chose not to do that.

I just read some of the Opencore docs where they say:

OpenCore Booting​

This section will be brief, as OpenCore boot issues are fairly rare and usually simple user error:

  • System powers on and searches for boot devices
  • System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/
  • BOOTx64.efi is loaded which then chain-loads OpenCore.efi from EFI/OC/
  • NVRAM Properties are applied
  • ...
  • ...
So I don't think I need to worry about copying over that Opencore EFI/BOOT/bootx64.efi to my multiboot EFI/BOOT/.. folder. The reason is because in my set up I am using Grub2 to chainload Opencore via EFI/Manjaro/grubx64.efi I don't plan to load Opencore any other way.

I do this by editing /etc/grub.d/40_custom in my Manjaro OS like this:

Bash:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.


# Add boot entry in Grub Menu for Opencore
menuentry "OpenCore (on /dev/sda1)" --class macosx{
search --file --no-floppy --fs-uuid --set=root 67E3-17ED
chainloader /EFI/OC/OpenCore.efi
}

I tested it just now and it's working... very cool.

So I guess I won't copy that Opencore EFI/BOOT/bootx64.efi into my "Windows" partition. Is there any reason why this might be a problem for me does anyone think so?

Cheers,

Flex
 
I do hardcore drive layout munging in Linux. But recent evolutions in Linux (Ubuntu) device abstractions are making this trickier.

Re cloning partition contents, that's a job for dd, or ddrescue which I prefer because it handles media errors gracefully and is restartable. Gparted is very useful.

Disk Utility should be assumed to not play well with anything. Even within Mac it's got lots of edge cases and is not documented. Diskutil command has man pages but all the discussion is below layout level. The Apple Developer docs may have layout clues, if you are strong-hearted.
 
Ok but above you said: "Re Manjaro you will need to diff its EFI against OC. I would not expect to mix Windows EFI with OC". Can you explain that a bit more? is it EFI/BOOT/bootx64.efi that might get over-written?

I don't understand all this very well (despite spending 100's of hours on it this year!) but it seems that in a Opencore EFI setup EFI/BOOT/bootx64.efi is used to chainload Opencore but what is the purpose of EFI/BOOT/bootx64.efi in a normal Windows EFI? To load Windows? Either by the motherboard UEFI running it or maybe Grub running it?

If so then that's what I want. Let Grub take care of booting Windows and Manjaro too and chainload Opencore via grubx64.efi and not by running a ?funny version of EFI/BOOT/bootx64.efi that Opencore made and that might get over-written anyway?

Cheers,

Flex
 
I should stand down on details because I'm at the limits of my understanding, but I'll explain my point of view:

If you are going to merge EFIs, then naming conflicts are a concern, hence diff.

Bootloading is partly covered by the EFI spec so can be construed to follow conventions, but it can't be separated from the structures of the file systems, so it's always OS specific, and as loaders are required to run an OS so the OS makers have to supply, naturally they will look at the solution biased to their OS. Under UEFI they will have features in common. UEFI grows from history of PC BIOS, when Intel was advancing 64-bit Itanium (it lost to AMD x64) and wanted to create a new plateau of system config that included something like drivers. You can't build complex HW without getting involved in the SW that will use it so EFI took a bit bite with Intel designers getting all into OS's bizness without Intel staking a claim in any OS (sometimes they pretend to be into Linux but Microsoft has them by the ..., which was why they were stoked for Apple design win contrary to what you might expect Intel and Microsoft never liked each other). So EFI became bloated by Intel trying to handle OS level config, while the actual boot situation is really about what the actual OS wants to do.

For us this is a blessing that this plateau is rich enough to include OC and all its ways to inject patches, which to Apple and Microsoft is indistinguishable from malware, and which aren't needed under a linux!

But the fact is that Windows boot loading rules the roost, Linux was built from Windows PC so it inherits everything from it while having little influence on its design, and to Apple it's just a pitstop on bigger plans. Which is why MacOS doesn't even use the EFI part except as staging area for FW updates and diags.

Windows just camps onto Intel so it adds some garden variety support for boot options similar to GRUB, which has grown up under the assumption of a Windows multiboot capability.

When you say "chainload" that's a GRUB idiom. Windows never needed to chainload and Mac didn't even care because they write their own firmware! This idiom partly has to do with the crossing from BIOS MBR / FAT32 and Linux LVM, where what's called a stage 1.5 loader was needed because two sectors were not enough code to locate and kick off the kernel, especially when partition table was 3 entries plus extended and hard drives were going from GBs to TBs. This still shows up today in Windows not letting you MBR/FAT32 USB drives bigger than 16G even though the format can handle it because it compromises traditions of bootloading.

All the pieces of the puzzle combine to reveal a picture in which OC is a total outlier, so you need to fit it by careful study of the history.

I punt on this and do not try to mix and match Win Linux and mac OS on single drive. Win and Linux go on one and mac on another and I use the Asus BIOS boot menu, not GRUB or OC, to pick. Even so Ubuntu still stomps on my mac drive EFI during dist upgrade even though it's never been involved in with Ubuntu!

If I were going to centralize my bootpicker via EFI I would prefer OC because I'm a mac centric user. But the BIOS works fine for my purposes. Making late-model macOS coexist with Win and Linux on a single drive sounds hazardous because APFS is a bugaboo and neither Win nor Linux have any reason to play nice with Apple, so far anyways.

That's my story and I'm stickin' to it!
 
Thanks @c-o-pr. It's interesting to learn how others do this but from I'm hearing alot of scare stories, from others who just followed a guide someplace, not backed up with facts to illustrate risk that you cannot work around.. so far anyway.

When you say: "Even so Ubuntu still stomps on my mac drive EFI during dist upgrade even though it's never been involved in with Ubuntu." What did Ubuntu do exactly?

Cheers,

Flex
 
Thanks @c-o-pr. It's interesting to learn how others do this but from I'm hearing alot of scare stories, from others who just followed a guide someplace, not backed up with facts to illustrate risk that you cannot work around.. so far anyway.

When you say: "Even so Ubuntu still stomps on my mac drive EFI during dist upgrade even though it's never been involved in with Ubuntu." What did Ubuntu do exactly?

Cheers,

Flex

No matter where you tell it to install the boot loader files it will do it on the first drive it sees in the system. At least that is what it did for me in my triple boot system when macOS was the first drive in the system. I had told it to install the boot loader on the /dev/sda its SSD drive but it installed to the /dev/nvme0, I think it is, for the nvme drive that contains my macOS install.

For your situation you want to never use DiskUtility for the cloning/restore it does not play well with other operating systems as you have found. Something like Carbon Copy Cloner is best to be used it will not mess with anything on the EFI partitions when cloning. All these boot loaders can exist in the EFI partition in their own vendor directories, for Microsoft its is /EFI/Microsoft which contains its bootmgfw.efi I think it is named. This is copied to the /EFI/Boot/bootx64.efi the file an EFI computer looks for to boot with all other loaders copy their .efi to this same location to use theirs for booting. The OC uses the /EFI/OC/OpenCore.efi which is copied to the file in /EFI/Boot not sure on yours but with Ubuntu on my machine it use the /EFI/ubuntu/shimx64.efi copied to /EFI/Boot file to have Grub control the booting.

That file allows the possibility of secure booting if I want if not the grubx64.efi file can be used for an old normal booting method with no secure option possible. What you want to do is allow all thes to work together in the one partition. Do your windows/linux cloning letting is setup the dual boot as it is with the Grub in the /EFI/Boot/bootx64.efi place to control that. Then after the Carbon Copy Cloner use to get macOS on the disk simply copy over the working OC folder to the /EFI directory in the efi partition and add your entry to chainload to it in Grub then update-grub to have the change used on the next boot. Personally I just do not bother with all this foolishness and use my F12 key to choose the drive/OS to boot from. This can work for a single drive if you use the efibootmgr in linux to create the entries for all the OSs in its boot menu.

Code:
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

There you can see an example of it in use from my notes on that machine. Windows is not in there yet at that time. It came after I installed it next but the -v option shows your current settings for the boot menu. The second use shows how you add an entry in this case it was for the Memtest program as it was newly built machine and I was getting it setup to test the RAM for a day or so. The last the -o option shows how you change the default OS you will boot if the menu key is not used. That is about all I think, good luck with it.
 
Status
Not open for further replies.
Back
Top