MP 1,1-5,1 Do all drives need EFI partitions?

[Engender]

Hello,

I am running Monterey on my cMP 4,1>5,1 through OCLP. Yesterday, there was some buggy stuff happening on my Mac, so I did an NVRAM reset. Once I rebooted, I found that I no longer had the graphic OC boot picker that I was using prior to the reset. Instead, I had a text-only one and I could not boot into Monterey. Thus began three hours of trouble shooting.

I have four HDDs and one NVME drive. My NVMe drive is the boot drive.

Eventually, I took out all my HDDs, leaving only my NVMe and I was able to boot into Monterey. At that point, I added all my HDDs and made sure that I could reboot into Monterey, which I could.

My conclusion is that, after reseting NVRAM, the cMP was pulling the EFI boot information from one of the HDDs. I then verified that each HDD has an EFI partition.

I am contemplating either removing the EFI partition from each HDD or reformatting the HDD. But, will reformatting add another EFI?

So, does each drive need an EFI partition?

 

[h9826790]

So, does each drive need an EFI partition?

No.

My conclusion is that, after reseting NVRAM, the cMP was pulling the EFI boot information from one of the HDDs. I then verified that each HDD has an EFI partition.

This can happen especially if OpenCore is stored on NVMe. For SATA drive, with RequestBootVarRouting set to true. A cMP usually can still located the blessed OpenCore after NVRAM reset. This is the reason why I personally suggest people install OpenCore onto a SATA drive.

I am contemplating either removing the EFI partition from each HDD or reformatting the HDD. But, will reformatting add another EFI?

You can, but you may also simply put a copy of your existing OpenCore EFI folder into those EFI partitions. Therefore, after NVRAM reset, no matter which EFI the cMP reads, it will still able to local an OpenCore copy, and boot accordingly.

 

[Dayo]

Your issue was not the presence of other EFI System Partitions (ESP) by themselves, but having bootable files in those ESPs (Active ESP).

When you reset your NVRAM, the unit does not have specific information on what to load and therefore needs to search.

The NVMe ports have a lower priority in the search order meaning that your Mac will search others first and if an Active ESP is found before it has a chance to search the ESP on the NVMe disk, it will try to load the active file it found.

In your case, you had another OpenCore instance on another ESP that was found first and therefore, loaded. If you did not have anything bootable in any other ESP, the OpenCore instance on the NVMe drive would have ultimately been reached and loaded.

So it is not so much that NVMe disk ESPs are disabled after NVRAM resets but that such resets send that ESP towards the back of the boot search queue. After blessing the bootable file in the ESP on the NVMe disk, it will be moved to be first in the boot search queue. Blessing something basically means moving it to the first position in the search queue. This is recorded in the NVRAM for future boots until changed; such as by a reset.

SATA drives are probably better for Active ESPs since NVRAM resets leave them at, or close to, the front of the boot search queue.

You *generally* want to only have one (1) Active ESP on your unit. That is, it does not matter how many ESPs are present as long as only one of them is active (has a bootable file). You generally shouldn't remove ESPs from disks that would otherwise have them.

You can create a second Active ESP as a fallback option as suggested by Martin above but I think you might as well make this your single Active ESP if in a more "reliable" location. In any case, such should typically be a duplicate of your default one and you should make it visually different so that you immediately know something has changed the default whenever it is loaded.

 

[Engender]

Okay, so the plan is to load opencore onto a SATA drive, as well as my NVMe drive. But, how do I make the other ESPs on the remaining two drives inactive?

EDIT: Okay, now all three of my SATA drives have updated EFI partitions. Is that a terrible idea for some reason?

 

[h9826790]

Okay, so the plan is to load opencore onto a SATA drive, as well as my NVMe drive. But, how do I make the other ESPs on the remaining two drives inactive?

EDIT: Okay, now all three of my SATA drives have updated EFI partitions. Is that a terrible idea for some reason?

You can put three identical copies to all EFI partition. It won't be a problem. There is always just one working.

In this case, no matter which one is working, it's the same EFI folder.

And the idea is the use to bless one drive as the active EFI, then all other ESP will stay inactive automatically. In your setup now, you don't need to worry about this anymore.

 

[Dayo]

Is that a terrible idea for some reason?

If after some time, you update OpenCore and end up with a misconfigured or otherwise unbootable setup which you propagate to all your ESPs before realising, then yes, this could prove to be a terrible idea.

So, IMO, whether it is a terrible idea to have ESPs with bootable files on all disks depends on a few things but I believe it is a poor choice in all cases and that you should have one and only one such ESP on your Mac, that this should be on a disk on a SATA port and that the disk should not hold your natively bootable Mac OS version so that you can disconnect the disk and still get into Mac OS whenever needed. All other connected ESPs should be empty/non-bootable.

If you must have a fallback ESP, use the ESP of a pen drive and stick this in a drawer until you need it.

 

[Engender]

If after some time, you update OpenCore and end up with a misconfigured or otherwise unbootable setup which you propagate to all your ESPs before realising, then yes, this could prove to be a terrible idea.

So, IMO, whether it is a terrible idea to have ESPs with bootable files on all disks depends on a few things but I believe it is a poor choice in all cases and that you should have one and only one such ESP on your Mac, that this should be on a disk on a SATA port and that the disk should not hold your natively bootable Mac OS version so that you can disconnect the disk and still get into Mac OS whenever needed. All other connected ESPs should be empty/non-bootable.

If you must have a fallback ESP, use the ESP of a pen drive and stick this in a drawer until you need it.

Unless I just update all drives with OCLP every time I update my NVMe drive.

 

[Dayo]

Unless I just update all drives with OCLP every time.

I suppose that is fine once assumed that the OCLP, and OpenCore that it sets up, can never ever have bugs/issues.

I suppose this is a perfectly logical view to take despite this, for example, that recently went in for the next release:

OcBootManagementLib: Fix incorrect handling of optional DataLength pa… · acidanthera/OpenCorePkg@36b2cea

…rameter Introduced by 546aa5ba6415902ed05db02f8a5448c5e7ff67cf

github.com

 

[Macschrauber]

For identification of the ESP content I made a bunch of little helpers:

https://forums.macrumors.com/threads/manually-configured-opencore-on-the-mac-pro.2207814/page-520?post=32382081#post-32382081

It lists where are active ESPs are, with bootloader versions, where possible and mount one or all.

 

[Dayo]

It lists and allows mounting active ESPs.

Nice but how do you use it if you have put a broken setup on the ESPs of *ALL* disks and cannot boot your unit?

 

[Macschrauber]

Nice but how do you use it if you have put a broken setup on the ESPs of *ALL* disks and cannot boot your unit?

Thats a point why everyone should have a medium with a supported OS in the machine or at least available.

But without a BootScreen or working OpenCore / RefindPlus Boot CD it is impossible to select it after a NVRAM reset. So one is in the need to pull all disks but the one with the supported OS and hook at least one drive externally after booting the supported OS and correct the botched bootloader.

After all its no good idea to have all ESPs populated with the same bootloader.

 

[Engender]

Does that mean that having sort-of random OCLP versions on different disks in the MP is a good strategy?

 

[Macschrauber]

If you can select them (having a bootscreen or good knowledge what drive contains what bootloader) it is at least a better idea than updating all with the same bootloader verson.

The best strategy is and was:
Having a bootscreen and a native system what needs no bootloader to run. So you can botch whatever you want with your unsupported systems and bootloaders - and can boot natively and adjust what's ever needed.

 

[Engender]

If you can select them (having a bootscreen or good knowledge what drive contains what bootloader) it is at least a better idea than updating all with the same bootloader verson.

The best strategy is and was:
Having a bootscreen and a native system what needs no bootloader to run. So you can botch whatever you want with your unsupported systems and bootloaders - and can boot natively and adjust what's ever needed.

Interesting. I do have one unused drive bay. So, I could just install a SATA drive with a fresh copy of . . . wow, now I can't remember what the last supported OS for cMPS was . . . Sierra? Anyway, that's a plan!