Contribute
Register

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

Status
Not open for further replies.
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.
That is exactly correct. The EFI/BOOT/bootx64.efi file is the default boot file and it's often over written by other operating systems during installation and updates/upgrades. That's why you don't want to rely on it when multi-booting. Starting OpenCore from Grub will avoid that issue. Everything else in the EFI partition should be in separate folders and hence no conflicts.
I tested it just now and it's working... very cool.
Good. As long as Grub remains working then you can load OpenCore with no need for extra steps.
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.
All the more reason to be sure you have a recent backup of your system. This applies even when not changing the configuration. Be prepared for recovery if things go downhill. Also, always have a rescue drive on hand with your working OpenCore configuration.
 
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
What's to be scared of ;) Once you've done a layout nothing will rearrange it unless you tell it to. But the ESP (EFI) part is contested territory.

You prolly don't want to mark multiple as ESP as this creates edge cases.

To repeat, Win and Linux generally know how to coexist, esp Linux tolerating Windows. OC is outlier.

You should not expect to be able to mix and match files from different bootloaders and you should not expect different loaders to play well together. So while multiple boot environments can live together, you need to assess there are no file naming conflicts.

To add to suspicions, what if different drive layout tools regard GPT in different ways? Prolly best not to think like this haha

And order of install matters. You might find a "chain" that works don't assume that it will stay that way, unless you know the intent of the loader is to support it. But how do you know that?! I am sure Ubuntu Unity doesn't respect OC. In my build, it overwrites BOOTx64.efi on NVMe EFI part even when Ubuntu was specifically installed on SATA. Is this a big deal? It is when I want to boot! Suddenly there is only GRUB and I have to recover the OC from another source. If I know the secret and am prepared, it takes a minute to fix. If I don't, I am dead in the water all your data are lost. How do you know?

I'm glad you are looking into this and happy that OC is helping Mac users to demystify EFI config

In your case, you are savvy enough to arrange a layout, but maybe you also want to be reassured that it's a safe arrangement. Who except you can answer your question? I'm not trying to disparage you. But you could use these tools to build a loader that runs in circles.

This thinking is what lead me to NOT try to build dependencies between the different OSes loaders and just rely on BIOS picker. When things go wrong I want to limit how far I have to search for cause and repair.

I'm mildly interested in why you want to triple boot from one drive and I have no doubt this can be made to work. But then what? If you just want things that way that's good enough. And there's nothing that needs reassurance.
 
@jpz4085 Thanks for the clarifications!

@c-o-pr
I don't understand your concern about naming conflicts in multiple boot environments. As long as the bootloaders for each OS are each in their own directory in the EFI partition like:

/EFI/Windows
/EFI/Manjaro
/EFI/OC

Then any files in those directories will have a unique path?

Regarding macOS needing to be first on the drive. I found this to be not true. On my set up I had Windows/Manjaro first, then I "restored" macOS to a free partition after the Manjaro home partition using Disk Utility from macOS recovery running off an Opencore USB installer. I asked a question about this on apple.stackexchange.com and got very helpful advice. Turns out macOS Disk Utility uses the EFI partition in some way. It was deleting my first-on-the-drive Windows EFI partition when it was only 100MiB in size. When I increased it to 500MiB then things like restoring macOS to a partition AFTER Windows and erasing/formatting partitions from Disk Utility worked fine. I also don't see how having an APFS container and volume should have any negative effect on adjacent EXT4 and NTFS partitions? It is just another filesystem contained within a partition on the drive as far as the partition table is concerned. At least that's what my thinking is.

I know what you mean about just using the BIOS picker to boot OSs and that way there are no dependencies. I used to always start Opencore that way. But I have documented all this for myself so I know what I am doing finally. I googled lots and didn't see anyone using Grub to start macOS hackintosh. It makes more sense to use Grub to multiboot OSs compared with Opencore given that it injects Kexts and smbios and so on into any OS it boots which surely no one wants. I think most tinkerers using laptops would appreciate being able to keep everything in one place instead of needing multiple drives... yet all the guides on this forum are focusing on using separate drives all the time like using only one drive is taboo. Novices will think that means it's not possible to multiboot from one drive when it is easily done.

I wanted to set up this triple boot from one drive because I recently got a second laptop, a Thinkpad T480 and it only has space for one drive. OK it has a 2280 NVME and also has a 2242 NVME form factor that is PCIe 3.0 x2 and B+M Keyed. Turns out there are limited options to buy such a drive and some question about their suitability to run a hackintosh from anyway. So I'm putting a 1TB Sata SSD in there with an adapter cable and plan on having all three OSs in that second laptop also.

Cheers,

Flex
 
@jpz4085 Thanks for the clarifications!

@c-o-pr
I don't understand your concern about naming conflicts in multiple boot environments. As long as the bootloaders for each OS are each in their own directory in the EFI partition like:

/EFI/Windows
/EFI/Manjaro
/EFI/OC
I have no problem with this.

Mac uses EFI as staging area for some functions like firmware updates, but I've never seen a conflict.

In modern GPT layouts, put parts any way you want. But keep in mind that there are histories for layouts where that wasn't true, but GPT was around then. This history is why GPT has a fake MBR area, which it IDs in a special way to keep legacy layout tools from blasting it.
To repeat Ubuntu installer has a naming conflict with OC and it replaces a loader file (Bootx64.efi). Note the name suggests a history if x86 (32-bit) vs x64, which has naming.

I'm sure my previous comments can be read in various ways. The subject is too complex to catalog. What I wanted to convey is that what constitutes a viable layout depends on what OS (history) you look at it from, and the corresponding starting point of loading.

Re APFS being just another filesystem type, I didn't want to imply otherwise.

As you have found Apple installer will mess with your layout re EFI min size. Windows installer will probably mess with your layout too. Ubuntu installer is kind-hearted enough to give you "Do something else" option to arrange a suitable layout without messing up existing Win or Mac, but then it goes ahead and stomps on NVMe ESP:/EFI/BOOT/BOOTx64.efi anyway, even if you tell it to install on another drive!

As to other Linux I can't say, but there are so many who has cataloged them all?

The history of this thread is your asking good questions about what happens with OC, whether your layout can work, surprise that Disk Utility munges your EFI, etc, with others pitching by telling to just follow the straight and narrow re OC. It seems you're more comfortable now. My attempt to help was only to expand the dialog a little re straight-and-narrow while advising you that there's no overseer of boot policy except you, and that history informs how various OS take liberties. AFAIK, OC should not be regarded as one loader to rule them all, but maybe they're working on it? IDK

Cheers
 
Status
Not open for further replies.
Back
Top