Hello, fellow Tinkerers! Although real life has intruded on my tinkering over the last few months, I've managed to squeeze in a small project or two. One of my background projects during this low key period has been testing OpenCore Legacy Patcher (OCLP) on a variety of unsupported MacBooks in my collection, specifically in multiboot arrangements with multiple installations of macOS and Linux. I thought I'd share a few tidbits I've acquired along the way through my tinkering and invite others to contribute as well.

Most recently I've been testing installations on a MacBook Pro Retina, 15-inch, Mid 2015 (MacBookPro11,5) with a 500-GB SSD. The below represents my outcomes with this MBP, and I intend on trying the same with some older Pros and Airs in my collection soon.

On my 2015 MBP, I am using a single APFS container with multiple versions of macOS, each installed in separate volumes within the single container. By the way, Mr. Macintosh just posted a YT video about multiboot and OCLP where he opted to install multiple macOS versions in separate APFS containers. I've been using the single APFS container approach for quite a while to make optimal use of shared free space among the volumes, and have seen no ill effects to date. However, if any of you APFS wizards out there know why separate containers versus a single container is the way to go, please comment below.

My preferred macOS philosophy is to keep an installation of the latest version supported natively as a failsafe, and install one or more later macOS versions via OCLP in separate volumes. Monterey is the latest version of macOS supported natively by the 2015 MBP, so I have it installed in a volume in the APFS container. I installed Ventura and Sonoma via OCLP in separate volumes in the same APFS container as Monterey. I configure OCLP to always show the OpenCore bootpicker, which shows all three installed versions of macOS at boot. Cool.

I wanted to add a Linux distro to the mix, because why not? My preferred distro is currently Linux Mint 21.2. I created a separate partition on the SSD and installed Linux Mint into it, which went smoothly.

My goal was to get Linux Mint to show in the OpenCore bootpicker along with the installed versions of macOS. Here is what I did. Please note that these steps require mounting the EFI partition and making edits to a config.plist file, which if done incorrectly can mess up booting for your Mac. Please don't do these steps unless you are comfortable with Terminal and unix commands and poking around the EFI partition.

Boot into macOS, mount EFI, and make a backup copy of the config.plist file under /Volumes/EFI/EFI/OC.

1. In Terminal, diskutil list - to identify where EFI is located, typically disk0s1
2. In Terminal, sudo diskutil mount disk0s1 - to mount EFI to /Volumes/EFI
3. Open a Finder window from the EFI mounted on your Desktop (you do have Finder configured to show mounted drives, right?) and navigate to config.plist - it should be under EFI/OC, or in your Terminal window surf to /Volumes/EFI/EFI/OC
4. Make a backup copy of config.plist before trying any of the methods below, just in case

Instructions for setting up multiboot via Dual Booting with Linux are located here: https://dortania.github.io/OpenCore-Multiboot/oc/linux.html. Here are the methods I tested. If you are going to switch methods, use a fresh copy of the config.plist file for each method to avoid mixing edits.

For Method A: OpenLinuxBoot -
This method uses OpenLinuxBoot.efi driver, which was added to OpenCore 0.7.3. OCLP 0.3.1 was based on OpenCore 0.7.4, so this and any subsequent version of OCLP should install this driver by default. OCLP 1.2.1 (the version I used) definitely installed the driver. However, this method needs an additional driver corresponding to the filesystem used for the Linux install to make the Linux kernels visible to the OpenCore bootpicker; the following steps are for installing an ext4 driver and checking a few other settings in config.plist.

1. Download ext4_x64.efi from here: https://github.com/acidanthera/OcBinaryData/tree/master/Drivers; if you used a different filesystem for your Linux install, find the corresponding driver and substitute it in the steps below (I only tested the ext4 driver, so your mileage may vary)
2. Copy ext4_x64.efi to the Drivers directory under /Volumes/EFI/EFI/OC; verify that OpenLinuxBoot.efi already exists in the Drivers directory. (It should.)
3. Edit config.plist in your favorite editor (I used TextEdit in macOS; you can use Xcode in macOS, or nano or pico or vim or whatever editor in Terminal if you like)
4. Verify that OpenLinuxBoot.efi exists as an entry in the Drivers section (it did in mine) and add an entry in the Drivers section for ext4_x64.efi (I copied a nearby entry in the Drivers section and edited it); make sure ext4_x64.efi is listed before OpenLinuxBoot.efi, or you might get boot problems (ask me how I know)
5. Verify RequestBootVarRouting, LauncherOption, and HideAuxiliary are enabled (they were in mine by default)
6. Exit and reboot - in theory, Linux Mint 21.2 (or your particular distribution) should appear in the OCLP bootpicker along with the various flavors of macOS installed previously

If the idea of adding a driver to your EFI from an external source is not palatable, or you run into problems with your particular filesystem driver, there is another option you can try. This one worked for me as well. Use a fresh config.plist file, not one with the Option A changes. (You did make a backup copy, right?)

For Method B: Chainloading an EFI Bootloader, Method 1: Using BlessOverride
This method requires that you know something about your Linux distribution's bootloader, at least enough to recognize what bootloader your distribution uses and where it lives. There are some hints below, but by no means is it a comprehensive list.

1. Edit config.plist in your favorite editor (I used TextEdit)
2. Find the BlessOverride entry under Misc - in my case it was set to \EFI\Microsoft\Boot\bootmgfw.efi, which I believe is the default configuration to dual boot Windows; I did not see this driver contained in the Drivers directory from installation of OCLP, so I figured I could alter this entry with no ill effects
3. Look for your Linux distribution's bootloader under EFI, and change the BlessOverride entry to match your bootloader; some common ones are
   1. \EFI\arch\grubx64.efi
   2. \EFI\ubuntu\grubx64.efi (this is what Linux Mint 21.2 uses)
   3. \EFI\systemd\systemd\systemd-bootx64.efi
4. Exit and reboot - an EFI entry representing your Linux install should appear in the OpenCore bootpicker along with the various flavors of macOS installed previously

There are other methods listed in the Dual Booting with Linux source which I didn't try. In the end, I chose Method A as my preferred method since it shows the actual Linux kernel by name instead of a generic EFI entry shown in Method B1.

Have any of you experimented with multiboot arrangements with different Linux distros or other OSes? What bootpickers and methods did you try, and what worked well or not well for you? I would love to see your experiences below!

I haven't played with rEFInd in many years... but OCLP was great in getting everything from 10.6.8 through Sonoma loaded on an iMac12,1. I haven't dared to try Windows or Linux on the same drive, I always prefer a secondary drive for isolation.

rikerjoe, Thanks for this post. You taught me how to solve a problem I had been working on for months in just a few minutes. I tried both of your solutions and both were easily done and worked just great! Last Christmas, I was a very new Linux user, and the first thing I wanted to do was have a Linux Mint partition on my MacBook Air 2017 running Sonoma through OCP. I tried on and off for several months with OCP pretty much preventing anything but a 1 or 2 time successful dual boot. Both took just minutes to try. Thanks again for this!!

>> mtriplett1 said:

rikerjoe, Thanks for this post. You taught me how to solve a problem I had been working on for months in just a few minutes. I tried both of your solutions and both were easily done and worked just great! Last Christmas, I was a very new Linux user, and the first thing I wanted to do was have a Linux Mint partition on my MacBook Air 2017 running Sonoma through OCP. I tried on and off for several months with OCP pretty much preventing anything but a 1 or 2 time successful dual boot. Both took just minutes to try. Thanks again for this!! Click to expand...

You're welcome, glad the solutions are working for you.

After a few months of testing with my 2015 MBP, I found Method A would lead to occasional boot problems that I think are associated with the drivers loaded with the boot picker. Method B just works, and it is what I'm currently using on it. I have a similar test underway on a 2013 MBA and so far so good with Method A.

keep me posted on how it goes for you. I may pass along my information to the developer of the OpenLinuxBoot driver in case it is a funny bug with the 2015 MBP and would like to know if other models have problems, too.

I finally decided on option B. Like you I wanted to see my distro name in the menu. Thanks again, and I'll keep you posted!

rikerjoe, thank you also from me. When I installed Linux Mint for the first time a few months ago, it set up the computer to boot into grub automatically. Later I rebooted to a macOS partition using the boot picker after which I could not figure out how to return to Linux until I found your very helpful instructions. Your "Method A" works well for me on a 2011 13" MBP and avoids the need to ever see grub so I have not tried "Method B".

I have had to come back to these instructions several times because something (probably an OpenCore Legacy Patcher update but maybe a macOS update) wipes out my changes and I have to make them again. I grew tired of performing the same steps manually over and over so I wrote a script to automate them; maybe it will also be useful to others:

>> ryandesign said:

rikerjoe, thank you also from me. When I installed Linux Mint for the first time a few months ago, it set up the computer to boot into grub automatically. Later I rebooted to a macOS partition using the boot picker after which I could not figure out how to return to Linux until I found your very helpful instructions. Your "Method A" works well for me on a 2011 13" MBP and avoids the need to ever see grub so I have not tried "Method B". I have had to come back to these instructions several times because something (probably an OpenCore Legacy Patcher update but maybe a macOS update) wipes out my changes and I have to make them again. I grew tired of performing the same steps manually over and over so I wrote a script to automate them; maybe it will also be useful to others: Adds ext4 driver to OpenCore Legacy Patcher so that a Linux partition can be selected. Adds ext4 driver to OpenCore Legacy Patcher so that a Linux partition can be selected. - add_oclp_ext4_driver.sh gist.github.com Click to expand...

Yes, OCLP updates remove the OC directory from the EFI and install a new one, meaning we have to reapply the mods to the config.plist file after every update, as you discovered. Thanks for the script!

>> ryandesign said:

rikerjoe, thank you also from me. When I installed Linux Mint for the first time a few months ago, it set up the computer to boot into grub automatically. Later I rebooted to a macOS partition using the boot picker after which I could not figure out how to return to Linux until I found your very helpful instructions. Your "Method A" works well for me on a 2011 13" MBP and avoids the need to ever see grub so I have not tried "Method B". I have had to come back to these instructions several times because something (probably an OpenCore Legacy Patcher update but maybe a macOS update) wipes out my changes and I have to make them again. I grew tired of performing the same steps manually over and over so I wrote a script to automate them; maybe it will also be useful to others: Adds ext4 driver to OpenCore Legacy Patcher so that a Linux partition can be selected. Adds ext4 driver to OpenCore Legacy Patcher so that a Linux partition can be selected. - add_oclp_ext4_driver.sh gist.github.com Click to expand...

That script is going into my files! Thanks to all!! Almost can't wait till the next update.

Ultimately I wish I could keep refind running, but OCLP prevents all of that. If I was running a current supported macbook, this would be no problem at all!

I know I can get a custom icon to appear on my Linux Mint partition in OCLP by creating the file /Volumes/EFI/EFI/ubuntu/.contentFlavour with the contents

Mint:Linux

but does anyone know where to get the actual Mint.icns and ExtMint.icns icons to put in /Volumes/EFI/EFI/OC/Resources/Image/Acidanthera/GoldenGate/ that match the style of the existing icons? Or how the existing icons were created--is there a template or script somewhere that I can use to create my own in a matching style?

>> ryandesign said:

I know I can get a custom icon to appear on my Linux Mint partition in OCLP by creating the file /Volumes/EFI/EFI/ubuntu/.contentFlavour with the contents Code: Mint:Linux but does anyone know where to get the actual Mint.icns and ExtMint.icns icons to put in /Volumes/EFI/EFI/OC/Resources/Image/Acidanthera/GoldenGate/ that match the style of the existing icons? Or how the existing icons were created--is there a template or script somewhere that I can use to create my own in a matching style? Click to expand...

I haven't tried it myself but there is this post on apple.stackexchange that might offer some insights.

Dortania guide

Try this info for converting a folder of icons to icns

and a source logo

Here is my quick try at creating it for you, convert and try to insert it.

Just reinstalled after updating to Sonoma 14.5. It went better than the first time. I ended up making a folder with all the docs and files needed so the next will be even quicker.

Thanks again!

>> rikerjoe said:

Hello, fellow Tinkerers! Although real life has intruded on my tinkering over the last few months, I've managed to squeeze in a small project or two. One of my background projects during this low key period has been testing OpenCore Legacy Patcher (OCLP) on a variety of unsupported MacBooks in my collection, specifically in multiboot arrangements with multiple installations of macOS and Linux. I thought I'd share a few tidbits I've acquired along the way through my tinkering and invite others to contribute as well. Most recently I've been testing installations on a MacBook Pro Retina, 15-inch, Mid 2015 (MacBookPro11,5) with a 500-GB SSD. The below represents my outcomes with this MBP, and I intend on trying the same with some older Pros and Airs in my collection soon. On my 2015 MBP, I am using a single APFS container with multiple versions of macOS, each installed in separate volumes within the single container. By the way, Mr. Macintosh just posted a YT video about multiboot and OCLP where he opted to install multiple macOS versions in separate APFS containers. I've been using the single APFS container approach for quite a while to make optimal use of shared free space among the volumes, and have seen no ill effects to date. However, if any of you APFS wizards out there know why separate containers versus a single container is the way to go, please comment below. My preferred macOS philosophy is to keep an installation of the latest version supported natively as a failsafe, and install one or more later macOS versions via OCLP in separate volumes. Monterey is the latest version of macOS supported natively by the 2015 MBP, so I have it installed in a volume in the APFS container. I installed Ventura and Sonoma via OCLP in separate volumes in the same APFS container as Monterey. I configure OCLP to always show the OpenCore bootpicker, which shows all three installed versions of macOS at boot. Cool. I wanted to add a Linux distro to the mix, because why not? My preferred distro is currently Linux Mint 21.2. I created a separate partition on the SSD and installed Linux Mint into it, which went smoothly. My goal was to get Linux Mint to show in the OpenCore bootpicker along with the installed versions of macOS. Here is what I did. Please note that these steps require mounting the EFI partition and making edits to a config.plist file, which if done incorrectly can mess up booting for your Mac. Please don't do these steps unless you are comfortable with Terminal and unix commands and poking around the EFI partition. Boot into macOS, mount EFI, and make a backup copy of the config.plist file under /Volumes/EFI/EFI/OC. In Terminal, diskutil list - to identify where EFI is located, typically disk0s1 In Terminal, sudo diskutil mount disk0s1 - to mount EFI to /Volumes/EFI Open a Finder window from the EFI mounted on your Desktop (you do have Finder configured to show mounted drives, right?) and navigate to config.plist - it should be under EFI/OC, or in your Terminal window surf to /Volumes/EFI/EFI/OC Make a backup copy of config.plist before trying any of the methods below, just in case Instructions for setting up multiboot via Dual Booting with Linux are located here: https://dortania.github.io/OpenCore-Multiboot/oc/linux.html . Here are the methods I tested. If you are going to switch methods, use a fresh copy of the config.plist file for each method to avoid mixing edits. For Method A: OpenLinuxBoot - This method uses OpenLinuxBoot.efi driver, which was added to OpenCore 0.7.3. OCLP 0.3.1 was based on OpenCore 0.7.4, so this and any subsequent version of OCLP should install this driver by default. OCLP 1.2.1 (the version I used) definitely installed the driver. However, this method needs an additional driver corresponding to the filesystem used for the Linux install to make the Linux kernels visible to the OpenCore bootpicker; the following steps are for installing an ext4 driver and checking a few other settings in config.plist. Download ext4_x64.efi from here: https://github.com/acidanthera/OcBinaryData/tree/master/Drivers ; if you used a different filesystem for your Linux install, find the corresponding driver and substitute it in the steps below (I only tested the ext4 driver, so your mileage may vary) Copy ext4_x64.efi to the Drivers directory under /Volumes/EFI/EFI/OC; verify that OpenLinuxBoot.efi already exists in the Drivers directory. (It should.) Edit config.plist in your favorite editor (I used TextEdit in macOS; you can use Xcode in macOS, or nano or pico or vim or whatever editor in Terminal if you like) Verify that OpenLinuxBoot.efi exists as an entry in the Drivers section (it did in mine) and add an entry in the Drivers section for ext4_x64.efi (I copied a nearby entry in the Drivers section and edited it); make sure ext4_x64.efi is listed before OpenLinuxBoot.efi, or you might get boot problems (ask me how I know) Verify RequestBootVarRouting, LauncherOption, and HideAuxiliary are enabled (they were in mine by default) Exit and reboot - in theory, Linux Mint 21.2 (or your particular distribution) should appear in the OCLP bootpicker along with the various flavors of macOS installed previously If the idea of adding a driver to your EFI from an external source is not palatable, or you run into problems with your particular filesystem driver, there is another option you can try. This one worked for me as well. Use a fresh config.plist file, not one with the Option A changes. (You did make a backup copy, right?) For Method B: Chainloading an EFI Bootloader, Method 1: Using BlessOverride This method requires that you know something about your Linux distribution's bootloader, at least enough to recognize what bootloader your distribution uses and where it lives. There are some hints below, but by no means is it a comprehensive list. Edit config.plist in your favorite editor (I used TextEdit) Find the BlessOverride entry under Misc - in my case it was set to \EFI\Microsoft\Boot\bootmgfw.efi, which I believe is the default configuration to dual boot Windows; I did not see this driver contained in the Drivers directory from installation of OCLP, so I figured I could alter this entry with no ill effects Look for your Linux distribution's bootloader under EFI, and change the BlessOverride entry to match your bootloader; some common ones are \EFI\arch\grubx64.efi \EFI\ubuntu\grubx64.efi (this is what Linux Mint 21.2 uses) \EFI\systemd\systemd\systemd-bootx64.efi Exit and reboot - an EFI entry representing your Linux install should appear in the OpenCore bootpicker along with the various flavors of macOS installed previously There are other methods listed in the Dual Booting with Linux source which I didn't try. In the end, I chose Method A as my preferred method since it shows the actual Linux kernel by name instead of a generic EFI entry shown in Method B1. Have any of you experimented with multiboot arrangements with different Linux distros or other OSes? What bootpickers and methods did you try, and what worked well or not well for you? I would love to see your experiences below! Click to expand...

Hi, I am trying to find the right spot in config.plist to add both files and I am a kind of lost. I am using Text Edit on macOS Sequoia and trying to get Ubuntu to show up in OpenCore. The previous steps to step four I got rightly done, however I can't locate where the information of drives are located on config.plist file. Please gimme a hand on it. I appreciate.

>> Igor Morais said:

Hi, I am trying to find the right spot in config.plist to add both files and I am a kind of lost. I am using Text Edit on macOS Sequoia and trying to get Ubuntu to show up in OpenCore. The previous steps to step four I got rightly done, however I can't locate where the information of drives are located on config.plist file. Please gimme a hand on it. I appreciate. Click to expand...

Method A

>> Igor Morais said:

Method A Click to expand...

Try Method B first to see if it works for you. This is a side-by-side comparison of the before on the left and after on the right of the config.plist file, showing replacement of the BlessOverride parameter with the Ubuntu bootloader information, assuming use of GRUB as the bootloader.

Hi all,

thanks for this post and the shell script, it helped me getting my MacBook Pro 2011 running OCLP 2.2 with OSX Sequoia 15.2 and Linux Trixie.

I had some issues to solve:

1. the ext4_x64.efi from https://github.com/acidanthera/OcBinaryData/tree/master/Drivers did not work. I use an updated one from the rEFInd repo which works fine. I updated the shell script to download that one automatically, see here.

2. When booting Linux it destroyed the OSX boot environment. I couldn't figure out exactly what happened. The files on the EFI partition under /EFI/OC and /EFI/System seemed to be untouched. Maybe I overlooked a dot-file. I commented out the /boot/efi line in /etc/fstab under Linux which seemed to solve the problem. Maybe I might run into troubles when the kernel gets updated and the grub.conf becomes outdated.
Just adding "exit 1" in /etc/default/grub didn't help.

Does anyone have a hint why Linux destroys the OSX Boot environment? Could it be an issue with EFI variables?

Michael

>> nospam2000 said:

Hi all, thanks for this post and the shell script, it helped me getting my MacBook Pro 2011 running OCLP 2.2 with OSX Sequoia 15.2 and Linux Trixie. I had some issues to solve: 1. the ext4_x64.efi from https://github.com/acidanthera/OcBinaryData/tree/master/Drivers did not work. I use an updated one from the rEFInd repo which works fine. I updated the shell script to download that one automatically, see here . 2. When booting Linux it destroyed the OSX boot environment. I couldn't figure out exactly what happened. The files on the EFI partition under /EFI/OC and /EFI/System seemed to be untouched. Maybe I overlooked a dot-file. I commented out the /boot/efi line in /etc/fstab under Linux which seemed to solve the problem. Maybe I might run into troubles when the kernel gets updated and the grub.conf becomes outdated. Just adding "exit 1" in /etc/default/grub didn't help. Does anyone have a hint why Linux destroys the OSX Boot environment? Could it be an issue with EFI variables? Michael Click to expand...

For what it is worth, I don't see a similar destruction problem with Linux Mint 22. Also, thanks for the link to the rEFInd version of the ext4_x64.efi driver. I am finding that the problems I had with the driver sourced from the original location have gone away and I'm having no issues with Method A using the newer driver. Thanks!

I also finally stepped up to trying the script as opposed to performing the config.plist mod manually. However, I'm seeing an issue with curl that I wanted to mention in case anyone else is seeing the same. I'm running the script in Terminal under Sequoia 15.2.

curl is throwing an error and causing the script to abort. The error says "curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST-CONNECT:tlsv1 alert protocol version" which seems to indicate a problem with the SSL or TLS connection between my MacBook Pro and the server I'm trying to access via curl. I'm scratching my head on this one since I'm running curl 8.7.1 embedded within Sequoia 15.2. As a workaround, I resorted to downloading a copy of the driver manually and adjusting the script to copy the local copy to the EFI partition. Do any of the rest of you see a similar error with the flavor of macOS you are using to run the script?

>> rikerjoe said:

curl is throwing an error and causing the script to abort. Click to expand...

looks like an outdated version of LibreSSL.

What is the output of the following commands:

which curl curl -V otool -L $(which curl)

I have the MacOS curl (Sonoma 14.7.2)

# /usr/bin/curl -V curl 8.7.1 (x86_64-apple-darwin23.0) libcurl/8.7.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.61.0 Release-Date: 2024-03-27 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL threadsafe UnixSockets # otool -L /usr/bin/curl /usr/bin/curl: /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)

and the MacPorts version

# /opt/local/bin/curl -V curl 8.11.1 (x86_64-apple-darwin23.6.0) libcurl/8.11.1 OpenSSL/3.4.0 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 nghttp2/1.64.0 Release-Date: 2024-12-11 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets zstd # otool -L /opt/local/bin/curl /opt/local/bin/curl: /opt/local/lib/libcurl.4.dylib (compatibility version 13.0.0, current version 13.0.0) /opt/local/lib/libnghttp2.14.dylib (compatibility version 43.0.0, current version 43.3.0) /opt/local/lib/libidn2.0.dylib (compatibility version 5.0.0, current version 5.0.0) /opt/local/lib/libpsl.5.dylib (compatibility version 9.0.0, current version 9.5.0) /opt/local/libexec/openssl3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/local/libexec/openssl3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/local/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.6) /opt/local/lib/libbrotlidec.1.dylib (compatibility version 1.0.0, current version 1.1.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1300.100.9) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2419.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2)

Michael

I figured out my problem with curl throwing an error message. It's a firewall configuration issue at my end.

>> nospam2000 said:

Hi all, thanks for this post and the shell script, it helped me getting my MacBook Pro 2011 running OCLP 2.2 with OSX Sequoia 15.2 and Linux Trixie. I had some issues to solve: 1. the ext4_x64.efi from https://github.com/acidanthera/OcBinaryData/tree/master/Drivers did not work. I use an updated one from the rEFInd repo which works fine. I updated the shell script to download that one automatically, see here . 2. When booting Linux it destroyed the OSX boot environment. I couldn't figure out exactly what happened. The files on the EFI partition under /EFI/OC and /EFI/System seemed to be untouched. Maybe I overlooked a dot-file. I commented out the /boot/efi line in /etc/fstab under Linux which seemed to solve the problem. Maybe I might run into troubles when the kernel gets updated and the grub.conf becomes outdated. Just adding "exit 1" in /etc/default/grub didn't help. Does anyone have a hint why Linux destroys the OSX Boot environment? Could it be an issue with EFI variables? Michael Click to expand...

I had somewhat of the same issue you had in your second point!
I got Sequoia running on my 2013 MBPr with the latest OCLP 2.4.1.
Now I wanted to parallel-boot Linux MINT.
What I did was partition the drive 50/50, install Linux MINT on the 2nd half but with "other" method, writing the boot loader onto that separate linux partition.
Then I see both OS in OCLP bootpicker. I can also still start macOS... until I start and shutdown Linux once => Then I get three entries in bootpicker: "EFI", "Linux", "macOS" but macOS only leads to an Apple symbol with no further progress.

I was able to fix it by booting from OCLP USB stick and reinstalling OCLP onto the internal drive, also tried the "Method A" with the additional OpenLinuxBoot.efi and the driver for ex4, then I always only get two boot entries - but the misery repeated when I then booted into Linux. After that when trying to boot macOS, I only get the apple but no progress bar.

Interestingly I can always still boot and recover the situation with the OCLP USB stick, so it seems to be some EFI partition related issue rather than NVRAM, maybe?

Did you ever find a solution? Maybe with Method B or something?

EDIT: Maybe I might try to install Linux Mint completely without bootloader by starting the installtion with "ubiquity -b" in the terminal. Hm...
EDIT2: Nope, didn't fix the issue. Still same behavior: First, after configuring OpenCore, both OS show up in boot picker, macOS boots fine.
But after starting MINT once and shutting it back down, I get an additional "EFI" entry in OpenCore and macOS won't boot anymore.
Can still easily fix this by booting OCLP from USB into the macOS on the internal SSD and rebuilding OCLP, but... that's just a hotfix. :D

EDIT3:
Update: No luck. Tried several things:
- Installing mint via "ubiquity -b" ergo without boot loader => no luck

- In Linux "sudo systemctl disable systemd-boot-check-no-act.service" => failed.. does not exist, since I got no boot loader

- In Linux "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor nvram_modify_on_write=0"" was a suggestion, together with "sudo apt purge os-prober -y" and "sudo update-grub" => All yielded the same result.

- In macOS "sudo bless --mount /Volumes/EFI --setBoot --file /Volumes/EFI/EFI/OC/OpenCore.efi" gave me an error: "could not set boot device property: 0xe00002e2"

- Also tried in Linux "sudo apt remove efibootmgr -y", and blacklisting efi changes via "echo "blacklist efivarfs" | sudo tee /etc/modprobe.d/blacklist-nvram.conf" and "sudo update-initramfs -u"

Now Gemini suggest to place an additional boot loader IN FRONT of OCLP... I don't know... that doesn't seem right. :(