MP 1,1-5,1 RefindPlus|OpenCore by MyBootMgr

[ironmanny1]

You can incorporate any OpenCore package you want as long as you understand how OpenCore works.
To start with though, it is not clear what "this" is. RefindPlus alone or RefindPlus and OpenCore? Share the ConfigFactory debug log.

I can see some red flags ... starting with this query which hints at the XY Problem. Martin's package is perfectly fine but there is no reason why anyone running MyBootMgr should be needing it.

If you want to use Martin's package, forget about MyBootMgr and go all in with Martin's package and if you want to use MyBootMgr, forget about Martin's package and go all in with MyBootMgr.

Again, you can add anything you want as per the instructions in Post 1 but it seems you might be looking at this in an attempt to solve some other issues brought about by not going all in as the next item suggests.


This suggests that rather than follow the instructions in Post 1 exactly as written, you have perhaps tried to create a hybrid by skipping some key bits such as leaving some third party OpenCore instances sitting around.

So, instead of having things defaulting back to your natively bootable Mac OS, it is going back to some random OpenCore instance you have left on some ESP (which would not be there if you had followed Post 1 as written).

Lucky you didn't get booted into UEFI Windows instead of OpenCore btw.


Yes. This is detailed in Post 1 but you should hide UEFI Windows in RefindPlus and use OpenCore for this.

Thank You Dayo, I saw this refindplus and thought wow, let's see what this is all about. Great work BTW, I like the fact that I can boot directly to my Mojave drive without OpenCore so I can flash my reconstructed bootrom.

When I have OpenCore running as my boot manager, Restarting my Mac and holding the option button on the keyboard doesn't always come up with the boot picker, and I eventually just pull out my SSD7102 raid card to natively boot Mojave.

I figured that I didn't follow the instructions to the T and thats is why I have the boot menu issue, but from what you are saying, either use Martin's package or MyBootMgr.

Thanks again for you help.

 

[Dayo]

Either use Martin's package or MyBootMgr.

Well, it is not a hard and fast rule but a recommendation. The guiding principle here is that users should be able to just follow Post 1 and generally never have to ask for help on anything no matter what their knowledge level is. Once users start trying to outguess the guide and skipping steps or putting their own steps in, things start getting likely to be problematic for some. The "I decided to go off piste vis-a-vis Post 1" aspect is never mentioned in problem reports.

As said though, you can add whatever you want to the setup created by MyBootMgr and if you are hellbent on adding Martin's, all you need to do is:

1. Run the ConfigFactory App in Dual Mode which will create a staging folder at /Users/Shared/MyBootMgr/EFI
2. Copy the "OC" folder from his setup and paste it into the staging folder
3. Rename the new /Users/Shared/MyBootMgr/EFI/OC folder to /Users/Shared/MyBootMgr/EFI/OC_MLO
   1. Make sure the LauncherOption key in the OpenCore config file is set to Disabled
4. Open the RefindPlus config file /Users/Shared/MyBootMgr/EFI/BOOT/config.conf in a text editor
   1. Copy one of the menuentry stanzas at the bottom and paste into /Users/Shared/MyBootMgr/EFI/BOOT/custom.conf
   2. Change the entry to menuentry "OpenCore (OC_MLO - Martin Lo Setup)"
   3. Change the loader line within that stanza to loader /EFI/OC_MLO/OpenCore.efi

Run the DeployConfig App etc and when you boot into RefindPlus, your additional Opencore setup will be there. You will obviously need to repeat the process on every update of MyBootMgr but you can automate this using the WrangleConfig Tool.

A few web searches should be enough to craft a script to do this and once done, you indicate you want to run your script when running the ConfigFactory App.

As said however, you shouldn't need to add Martin's setup and the real issue you have is leaving other OpenCore setups, Martin's or AN Other's, sitting around in other ESPs.

 

[Macschrauber]

to add a little helper to the previous post:

I made a bunch of ESP scripts. For example one to list all available ESPs with naming the drive, the interface, the bootloader flavour, the version (where possible).

So if one has multiple bootloaders lurking in the drives, they could be found with it.

Also you can rename the <EFI Boot> text shown in the boot picker to whatever describes this particular bootloader the best for you.

I recommend <Windows - dont boot!> for the Windows ESP as it should not be started from the boot picker because of the certificates it writes.

https://forums.macrumors.com/threads/manually-configured-opencore-on-the-mac-pro.2207814/post-32382081

 

[Dayo]

A bunch of ESP scripts.

Not to say these are not useful in their own right and in other relevant setups, but everything a user needs for creating and running a RefindPlus|OpenCore setup without issue is outlined in Post 1 of this thread and included in the MyBootMgr package.

All a user needs to do is to follow the guide verbatim:

In simple terms, if it is not written in Post 1, it is not recommended.

 

[Macschrauber]

yes, of course

I meant to find another ESP with a bootloader in.

 

[ironmanny1]

Thank You Dayo & Macschrauber. There are no other ESP with a bootloader and I followed the instructions provided by Dayo. The boot menu is works like a charm. So amazing how by reading these post I can see how talented and experience you guys are.

 

[Dayo]

Updated MyBootMgr to v095a
See change log in Post 1 for details

 

[garibaldo]

Updated MyBootMgr to v095a
See change log in Post 1 for details

I wish to add Windows and Linux HDDs to cMP after RefindPlus_OC_myBootMGR setup. How should I proceed? Should I pre install and just reconnect after setting, or install after all? Are Linux UEFI installs capable of damaging cMP as Windows?

 

[Dayo]

I wish to add Windows and Linux

As with most things related to MyBootMgr, answers can be found in Post 1.

For Windows:

For Linux:

Are Linux UEFI installs capable of damaging cMP as Windows?

Theoretically possible but unlikely. Regardless, I prefer Legacy/CSM instances of other operating systems on my cMP whenever possible myself. Apple were (u)EFI pioneers and cMP era Macs were the lab rats.

A cMP is not a UEFI 2.x device but an EFI 1.x device with some UEFI 2.x patches applied (fully or partially). An NVRAM, a UEFI 2.x item, was added to cMP but what was added does not meet UEFI 2.x specs and the very fact that the NVRAM on cMP can be damaged by trying to store "too much data" falls short of the specs where this should not be possible.

Hence, any "real" UEFI 2.x OS can *technically* damage the Proto-NVRAM on a cMP by overloading it with data. However, Linux does not appear to do anything that can damage cMP out of this shortcoming. This is especially considering that Linux distros try to support low end stuff.

For context though, some early Samsung laptops were bricked by UEFI Linux.
The same situation is possible on cMP due to how the NVRAM is designed to work.

How to destroy a brand-new Samsung laptop: Boot Linux on it

Motherboard DEATH alert. Suddenly Windows 8 doesn't look so bad

www.theregister.com

Samsung fixed their NVRAM handling and I believe changes were made to the Linux kernel as well. Incidentally, Apple fixed the NVRAM on Macs such that the 2013 Trashcan implementation is apparently a different beast altogether.

Note that Apple only started releasing units certified as UEFI 2.x around 2017. I suppose Mac OS versions released for which only such units are supported could be viewed as "real" UEFI 2.x. Consequently, recent Mac OS versions are probably more likely to brick a cMP than Linux is.

Assuming the presumed changes to Linux have not been rolled back, and will not, the main thing to watch for on UEFI Linux is that the loader, typically Grub, will invariably stage a boot coup during installation and you will need to take steps to recover from this. Grub will also stage such each time it is updated.

You will almost certainly need to recover from an installation boot coup but I believe it is possible to stop Grub updates and most that use other loaders, such as rEFInd, typically do this. You will need to ask for guidance on a Linux forum.

In any case, you will find guidance on dealing with boot coups in Post 1:

EDIT: Remembered and added stuff about "Motherboard Deaths" on early Samsung laptops

 

[garibaldo]

Dayo,
I will re-read the #1 Post, thank you very much...

 

[Bmju]

Assuming the presumed changes to Linux have not been rolled back, and will not, the main thing to watch for on UEFI Linux is that the loader, typically Grub, will invariably stage a boot coup during installation and you will need to take steps to recover from this. Grub will also stage such each time it is updated.

@garibaldo - OpenCore includes an optional driver called OpenLinuxBoot. This allows OpenCore to start UEFI Linux directly - not via Grub - and would probably count as the most recommended/supported way to boot Linux in an OpenCore install. That avoids boot coups. You do need to install Linux (including Grub) normally, initially, and recover back to OpenCore (with OpenLinuxBoot installed) after the initial boot coup. I am not sure to what degree, if any, this is in scope for this thread, however!

 

[garibaldo]

@garibaldo - OpenCore includes an optional driver called OpenLinuxBoot. This allows OpenCore to start UEFI Linux directly - not via Grub - and would probably count as the most recommended/supported way to boot Linux in an OpenCore install. That avoids boot coups. You do need to install Linux (including Grub) normally, initially, and recover back to OpenCore (with OpenLinuxBoot installed) after the initial boot coup. I am not sure to what degree, if any, this is in scope for this thread, however!

@Bmju, thank you very much, Iḿ reading about multiboot and OpenLinuxBoot @ Dortania's github... Seems promising....

 

[garibaldo]

@Bmju, thank you very much, Iḿ reading about multiboot and OpenLinuxBoot @ Dortania's github... Seems promising....

Or @Dayo, maybe you could write a guide, completing the post #1 on how to have other OSs running along OS X after intalling MyBootMgr...? Since it is the purpose of having a boot manager, right? @eicca maybe interested, too...

 

[Dayo]

While @eicca did seem to have had some issues that resulted from failing to read up on what is already documented and from proceeding on an outdated and inadequately configured setup, you will note that he has in fact got everything up and running. He just had some wasted time for the reasons stated before.

This is because there is no particular drama to installing and running an OS with the setup:

1. Take basic precautions
2. Find a disk
3. Install OS on disk

While the nuts and bolts of how to install an OS is out of scope for MyBootMgr, here is already a link to how to install Windows and suggestions for Linux were updated based on the findings on the other thread.

Actually, to get things back on topic here, I will suggest continuing on that other thread.

Thanks

 

[Dayo]

Updated MyBootMgr to v096
See change log in Post 1 for details

 

[xbomber2002]

Updated MyBootMgr to v096
See change log in Post 1 for details

Hi,
It’s me or something is going wrong with the download server…get a 2.5 MB dmg that refuse to open, seems a corrupted file.

 

[Dayo]

Is it me?

It isn't. The DMG is indeed corrupt and needs to be fixed. Thanks.

Will post when it has been fixed; which will be in about 8 to 10 hours.

 

[Dayo]

@xbomber2002 ... The package has been fixed.

 

[Dayo]

Updated MyBootMgr to v097
See change log in Post 1 for details

 

[JedNZ]

Thank you @Dayo . No build issues on my end with v097.

I also copied across the OC_EXT instance created with OCLP 1.3.0, and my cMP5,1 is working almost perfectly with macOS Sonoma 14.2.

I am having intermittent issues with Apple Watch unlock. Bluetooth is working after using the hack below to clear out the NVRAM Bluetooth data points

kinwin said:
I had similar bluetooth problems when I upgraded to Sonoma from Ventura on both a 2011 and 2010 iMac.
This is what I did to get bluetooth back.
Download Ben Baker's Hackintool.app. Use the app to edit NVRam directly. Look for the entries:
bluetoothExternalDongleFailed
bluetoothActiveControllerInfo
bluetoothInternalControllerinfo
Delete all the entries, and wait for the NVRam to refresh itself. At least one of the entries (bluetoothExternalDongleFailed) should come back with value of <00>. If not, repeat deleting the entries.
For me bluetooth worked again when I performed the above steps, bluetooth settings will show all previously paired devices, and auto connect to them just as before the update.

And then unpairing my Apple Watch with my iPhone, then pairing back again.

 

[Dayo]

No build issues on my end with v097.

I am having intermittent issues with Apple Watch

Thanks for the feedback.

I don't run OCLP generated instances and actually do not even use bluetooth to start with as I prefer hard connections as well as normal watches ... always have to contain the urge to reach over and slap people I am talking to when they keep glancing at their beeping watches every few seconds.

Anyway, I am aware that booting into different Mac OS generations can put BT out of kilter and have been toying with an idea of setting RefindPlus up to provide a config option to delete the BT nvRAM items when it detects a likelihood of booting into a different Mac OS generation. Still weighing up the pros and cons of this.

If it goes ahead, RefindPlus will disable the target nvRAM entries whenever booting into instances of Mac OS, OpenCore or Clover that do not match the previous boot via RefindPlus. For example, if a user had previously booted OC_AAA and is now booting OC_LEG or OC_EXT, it will clear those BT nvRAM entries before loading OpenCore. Consecutive boots into the same instance via RefindPlus will not trigger the step.

You might also be able to avoid this issue by using the emulated nvRAM option in OpenCore as this should effectively create sandboxed nvRAM instances so that when you boot Mojave for instance and return to Sonoma, the changes to nvRAM made by Mojave would not be seen by Sonoma and vice versa. In theory at least.

ConfigFactory can set this emulated nvRAM up as you must have seen but I am not sure whether it will handle Sonoma or anything newer than Catalina actually. Not paid much attention to this item for some time and it might need being done manually for newer Mac OS versions.

Eitherway, the OpenCore Emu nvRAM should be considered by all running unsupported Mac OS, particularly BigSur and newer, as it will eliminate almost all writes to the hardware nvRAM chip and therefore protect the chip from general wear and tear as well as from things like the huge Mac OS update/installation payloads that can brick a cMP.

 

[haralds]

I am using OCLP 1.3 and am pretty happy with it except for the fact of having to option-boot for Mojave, Windows 11, and (optionally, not required) DosDude patched Catalina. I currently have Monterey, Ventura, and Sonoma all running parallel configs that are identical. My CMPro has a flashed RX-580 and updated WiFi/BLE. AirDrop and Watch unlock work. Mojave and Catalina have plist patches and run with full SIP. Monterey OCLP runs without root patch.

All that is running well, and I am mainly maintaining all of these to be prepared for glitches with special concern for Logic Pro. Eventually I will axe Ventura, but Sonoma has not been without glitches. Alas, Monterey no longer supports the latest Logic Pro. Xcode is also been an issue, since I always need the latest for work. A Mac Studio and MacBook Pro are my main drivers, but the CMPro is a nice workhorse in my second office.

I am interested in RefindPlus/myBootMgr mainly for the loading elegance. I used to configure OC manually, but OCLP makes it so much easier.

Does RefindPlus support the custom themes for the original?
Is there a migration or combination process description?

I just started looking at MyBootMgr and have not done a full RTFM.

Thanks.

 

[Dayo]

All is running well

You need to consider whether you really want to change anything.

I have not done a full RTFM.

Once you do, if you still want to proceed, you should find that most of, if not all of, your queries are answered in POST 1. However, not everything is covered in absolute detail.

In any case, I get enough moans about POST 1 being complicated because I have tried to put as much background info a user may need to fly without having to check back ... as long as they do a "RTFM".

In summary though, MyBootMgr will create OpenCore instances that can boot "Vanilla" installations of Mac OS Tiger to Monterey. Instances installed via DosDude/OCLP without "Post-Install" patches applied are effectively "Vanilla".

There is a process for incorporating OCLP patched Ventura/Newer described in POST 1. DosDude/OCLP Patched Monterey/Older instances can be handled but this is discouraged for most users. I do run DosDude Catalina myself though and having this is a good idea on MP31 in particular or if using a recent (2020ish) GPU in general.

I am using OCLP 1.3 and am pretty happy with it except for the fact of having to option-boot for Mojave, Windows 11, and (optionally, not required) DosDude patched Catalina. I currently have Monterey, Ventura, and Sonoma all running parallel configs that are identical. My CMPro has a flashed RX-580 and updated WiFi/BLE. AirDrop and Watch unlock work. Mojave and Catalina have plist patches and run with full SIP. Monterey OCLP runs without root patch.

In your case, with the RefindPlus|OpenCore set up by MyBootMgr after you select certain expected options in MyBootMgr's ConfigFactory app, RefindPlus will always load on boot and you will be able to go to Windows, Mac OS or OpenCore. Linux will be detected and presented if installed later.

Will suggest running MyBootMgr from your DosDude Catalina so that DosDude Catalina is the Mac OS option displayed in RefindPlus by default. Possible to add the Mojave instance but will leave that as homework as best to stick to one Mac OS instance via RefindPlus and use OpenCore for the others.

I expect you will have four OpenCore instances:

• For BigSur/Monterey - Runs
• For Catalina/Older - Runs (Do not use for DosDude Catalina; should always be run from RefindPlus)
• For Monterey/Older - Installs/Updates (VMM)
• For Ventura/Newer - Runs/Installs/Updates (OCLP)

The first three work OOB but you will need to overwrite the fourth one with your OCLP instance as documented in POST 1.

The modifications you have applied for older OpenCore will most likely be automatically added by the ConfigFactory app as it probes your hardware and sets OpenCore up accordingly as much as possible. If there is something missing, you can script MyBootMgr's WrangleConfig tool to apply your arbitrary changes every time you run the ConfigFactory app. You can also set this up to automate the OCLP sync.

Note that each OpenCore instance created will show all available Mac OS instances as options but you must only boot what each OpenCore instance is set up to boot. It is possible to hide stuff that cannot be booted on the OpenCore instances such that only what is bootable is shown. Had wanted to automate setting this up but faced certain headwinds that frustrated this and have put this on ice for now. You will have to do this manually if you want to hide such. Refer to the OpenCore manual.

Does RefindPlus support the custom themes for the original?

If you mean rEFInd by "original", then yes, this is documented in POST 1.

On the OpenCore side, note that OpenCanopy is not configured by ConfigFactory and there are no plans to change this. Whatever is set in OCLP configured instances will work but MyBootMgr configured instances do not include this and you will need to add such yourself if you want it. This addition, as with any desired arbitrary changes to ConfigFactory output, can also be automated with MyBootMgr's WrangleConfig tool as required. You just need to add the code and run the tool.

---

IMPORTANT
Do not indicate that you intend to boot your DosDude Catalina via OpenCore when running the ConfigFactory app. That is, as it should always be run via RefindPlus, you essentially do not have a DosDude patched Mac OS instance for consideration when setting OpenCore up.

All said and done, you absolutely need to "RTFM" in POST 1 if you do decide to proceed!!

 

[LookToWindward]

Hi All,

I've just found this thread. I've been playing with OC for a while now and have successfully installed OC/Monterey on my 3,1. What benefit would using MyBootMgr and RefindPlus have over the basic OC installation.

As I understand it, you can't have to OC/MacOSes installed at the same time, would this allow this?

I'm going to give this a try on a new Mac and drives etc.

Cheers
Dave

 

[LookToWindward]

The thing I having trouble with understanding is where does MyBootMgr/RefindPlus actually reside, on which volume. For instance I have the following:

Native/El Capitan - Installed on SATA/HDD1
OC/Monterey - Installed on SATA/HDD2

Would MyBootMgr/RefindPlus allow me to have a OC/Sonoma installed on SATA/HDD3?