Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

E

Engender

macrumors member
Original poster
Oct 6, 2007
97
8
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?
 
Engender said:
So, does each drive need an EFI partition?
Click to expand...
No.
Engender said:
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.
Click to expand...
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.

Engender said:
I am contemplating either removing the EFI partition from each HDD or reformatting the HDD. But, will reformatting add another EFI?
Click to expand...
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.
 
  • Like
Reactions: Reefwalker and bmoraski
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.
 
Last edited:
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?
 
Engender said:
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?
Click to expand...
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.
 
Engender said:
Is that a terrible idea for some reason?
Click to expand...
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.
 
Last edited:
Dayo said:
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.
Click to expand...
Unless I just update all drives with OCLP every time I update my NVMe drive.
 
Engender said:
Unless I just update all drives with OCLP every time.
Click to expand...
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:
github.com

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

…rameter Introduced by 546aa5ba6415902ed05db02f8a5448c5e7ff67cf
github.com github.com
 
Dayo said:
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?
Click to expand...

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.
 
Does that mean that having sort-of random OCLP versions on different disks in the MP is a good strategy?
 
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.
 
Macschrauber said:
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.
Click to expand...
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!
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back