SayantanRC / URLs

A few important urls...
Other
30 stars 10 forks source link

An easiest way to add OpenCore to Grub #2

Open lucasgabmoreno opened 1 year ago

lucasgabmoreno commented 1 year ago

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 commented 1 year ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

I guess this can be closed?

miranda commented 5 months ago

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 commented 5 months ago

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.