An easiest way to add OpenCore to Grub

[lucasgabmoreno]

I saw your guide (https://github.com/SayantanRC/URLs/blob/master/grub_to_opencore.md) and find an easiest way:

1. Don't create any folder and don't copy OpenCore.efi, just use it as it is
2. Edit /etc/grub.d/proxifiedScripts/custom and add this simple line:

menuentry "MacOS" --class macosx {
	search --file --no-floppy --set=root /EFI/OC/OpenCore.efi
	chainloader /EFI/OC/OpenCore.efi
}

3. Update grub

sudo update-grub

Tested on Linux Mint (Ubuntu derivative)
If you restart and boots into opencore instead of grub. Please reboot, enter your BIOS and change bootloaders order

[VGerris]

I have it like this :

menuentry "MacOS" {
	insmod chain
	insmod fat
	insmod part_gpt
	insmod search_fs_uuid
	search --fs-uuid --no-floppy --set=root 67E3-17ED 
	chainloader ($root)/EFI/OC/OpenCore.efi
}

added to /etc/grub.d/40_custom .
On Fedora 37, the command to update grub is :

sudo grub2-mkconfig -o /etc/grub2.cfg

I have issues currently when combining it with S3 patching attempts though, works on another.

[miranda]

I have it like this :

menuentry "MacOS" {
	insmod chain
	insmod fat
	insmod part_gpt
	insmod search_fs_uuid
	search --fs-uuid --no-floppy --set=root 67E3-17ED 
	chainloader ($root)/EFI/OC/OpenCore.efi
}

I put exactly this in my grub.d/40_custom but it doesn't work for me. I have tried dozens of variations of this and all I ever get is:

error: file /EFI/OC/OpenCore.efi not found

I don't know what else to try. If anyone knows how I can diagnose this, I would really appreciate it.

[miranda]

I figured out why it wasn't working for me. I can't believe how dumb this is, but MacOS Disk Utility creates the same UUID every time for all EFI partitions: 67E3-17ED. So the reason grub couldn't find OpenCore.efi was that using the UUID was useless, because I had 5 drives with EFI partitions all using the same UUID!!!

I solved the problem by deleting my EFI partition on the OC drive, and creating a new one in it's place with gparted on Linux... then copying OC back to the new EFI partition. Since it has a unique UUID now, grub is able to find it just fine.

[VGerris]

@miranda I wanted to respond but you beat me to it :). Indeed, that is what MacOS seems to do. I have a dual NVMe setup in my laptop and I also noticed that Linux seems to mount partitions double, so grub may also be run from the other EFI partition. Good tip to get around it, on the other hand at the same id and same content, one can gracefully fail perhaps?

I have the same snippet by adding it to /etc/grub.d/40_custom except for insmod fat, that does not seem to be needed.
Good to have it figured out!

[VGerris]

I guess this can be closed?

[miranda]

I wanted to post a followup to my solution... turns out it doesn't quite work.
Grub does find it, but I have found that my MacOS drive doesn't always boot properly, and will hang on a black screen before login. After waiting 3 mins, the desktop comes up, but no drives other than the boot drive are accessible anywhere. Also USB doesn't work at all except 1.1 peripherals like keyboard and mouse.

So, this is a bad solution. I have discovered that deleting and recreating my EFI partition seems to be incompatible with the way Apple's diskutil does it when creating an APFS volume. The size is off by 0.1mb and the first sector is 2048 instead of 40. This causes Disk Utility to be unable to run first aid on the drive, it says the EFI partition is too small. I'm still investigating why this is, and how to change the UUID of the EFI partition safely. I think this is complicated by the fact that apparently from what I read, fat32 partitions don't actually have a UUID... it is generated from a serial number.

So... I recommend against the method I posted. If anyone has an alternate solution for either changing the UUID or creating a new APFS volume with a EFI partition with unique ID, or creating an APFS volume with something other than Apple Disk Utility.... please reply here.

[miranda]

I was able to fix my EFI partiton size. The issue is Gparted for some reason creates new partitions starting at sector 2048, while MacOS expects them starting at sector 40. I deleted it again and then used fdisk to create the partition, which lets you start it at a much lower sector number. After that I formatted the partition with Gparted as FAT32, and copied the EFI folder with OC back into place. Disk Utility then says all is fine with the filesystem. However my intermittent booting did not change, so I'm not sure what happened. I'm leaning towards it being an unrelated problem that started around the same time by coincidence. Formatting the EFI partition with Gparted also gave it a new random UUID, so deleting the partition was never necessary. If anyone else wants to try this, you should just format it with Gparted... that way it will stay the same size and in the same place, but you get a unique UUID.