Every drive? That's very unusual, especially if these drives are just data drives or contain macOS. You should investigate what is on those EFI volumes. Note that OpenCore should only be installed to one drive.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Every drive? That's very unusual, especially if these drives are just data drives or contain macOS. You should investigate what is on those EFI volumes. Note that OpenCore should only be installed to one drive.
If a drive has an ESP (EFI System Partition), then that partition will be displayed in the boot picker if the OC_SCAN_ALLOW_FS_ESP bit in ScanPolicy it set to 1 in the config.plist.
From the OpenCore manual:
- 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.
- 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported. Known device types are prefixed with OC_SCAN_ALLOW_DEVICE_.
- 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.
- 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.
- 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.
- 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.
- 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_EXT, allows scanning of EXT (Linux Root) file system.
- 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.
- 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.
- 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.
- 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.
- 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.
- 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.
- 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.
- 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.
- 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus
(e.g. VIRTIO).
HideAuxiliary can't hide ESP's.
An entry is considered auxiliary when at least one of the following applies:
• Entry is macOS recovery.
• Entry is macOS Time Machine.
• Entry is explicitly marked as Auxiliary. • Entry is system (e.g. Reset NVRAM).
Ok. I blitzed the EFI and started again stock. This time it worked for me but the temp volume was called Macintosh HD rather than MacOS Install or the volume ID. It stood out as not having a recovery volume. The update didn't show any minutes remaining while processing, just a slow moving progress bar, and took a couple of reboots but it finally worked. Thanks.
Many thanks for answering. I have now managed to correct it. It now shows the volumes and Recovery for each disk
OpenCore on the Mac Pro
For disk labeling OC provides its own program called disklabel: Copy and paste that to your Bootx64.efi folder: cd to the folder in terminal and run: g5@G5s-Mac-Pro-2 BOOT % /Volumes/EFI/EFI/BOOT/disklabel Usage: disklabel -d .disk_label image.ppm! disklabel -e "Label" .disk_label...
forums.macrumors.com
Nice! Though, for the benefit of others coming across this discussion, it would be great if you could explain how you managed to correct the issue.
One way is to create a text file called ".contentDetails" containing the name of the disk you wish and place it the folder /System/Library/CoreServices.
One way to do that is through a terminal command:
Code:
sudo echo "My Boot Disk" > /System/Library/CoreServices/.contentDetailsJust replace "My Boot Disk" with whatever you wish.
SIP will need to be disabled to place the .contentDetails file into /System/Library/CoreServices.
Then, in OpenCore config, you need to check the value of PickerAttributes settings.
The OC_ATTR_USE_DISK_LABEL_FILE bit of PickerAttributes needs to be set.
See the OC manual.
Here's an extract :
6. PickerAttributes
Type: plist integer
Failsafe: 0
Description: Sets specific attributes for the OpenCore picker.
Different OpenCore pickers may be configured through the attribute mask containing OpenCore-reserved (BIT0~BIT15) and OEM-specific (BIT16~BIT31) values.
Current OpenCore values include:
• 0x0001 — OC_ATTR_USE_VOLUME_ICON, provides custom icons for boot entries:
OpenCore will attempt loading a volume icon by searching as follows, and will fallback to the default icon on failure:
– .VolumeIcon.icnsfileatPrebootvolumeinper-volumedirectory(/System/Volumes/Preboot/{GUID}/ when mounted at
the default location within macOS) for APFS (if present).
– .VolumeIcon.icns file at the Preboot volume root (/System/Volumes/Preboot/, when mounted at the default location
within macOS) for APFS (otherwise).
– .VolumeIcon.icns file at the volume root for other filesystems.
Note 1: The Apple picker partially supports placing a volume icon file at the operating system’s Data volume root,
/System/Volumes/Data/, when mounted at the default location within macOS. This approach is flawed: the file is
neither accessible to OpenCanopy nor to the Apple picker when FileVault 2, which is meant to be the default choice, is
enabled. Therefore, OpenCanopy does not attempt supporting Apple’s approach. A volume icon file may be placed at
the root of the Preboot volume for compatibility with both OpenCanopy and the Apple picker, or use the Preboot per-
volume location as above with OpenCanopy as a preferred alternative to Apple’s approach.
Note 2: Be aware that using a volume icon on any drive overrides the normal OpenCore picker behaviour for that drive
of selecting the appropriate icon depending on whether the drive is internal or external.
• 0x0002 — OC_ATTR_USE_DISK_LABEL_FILE, provides custom prerendered titles for boot entries from .disk_label
(.disk_label_2x) file next to the bootloader for all filesystems. Prerendered labels can be generated via the disklabel
utility or the bless command. When disabled or missing, label text in (.contentDetails or .disk_label.contentDetails) will
be rendered if present instead, otherwise the entry name itself will be rendered.
In the section of OC conflig.plist shows:
<key>ConsoleAttributes</key>
<integer>0</integer>
<key>HibernateMode</key>
<string>None</string>
<key>HideAuxiliary</key>
<false/>
<key>LauncherOption</key>
<string>Disabled</string>
<key>LauncherPath</key>
<string>Default</string>
<key>PickerAttributes</key>
<integer>17</integer>
<key>PickerAudioAssist</key>
<false/>
<key>PickerMode</key>
<string>External</string>
<key>PickerVariant</key>
<string>Auto</string>
<key>PollAppleHotKeys</key>
<false/>
<key>ShowPicker</key>
<true/>
<key>TakeoffDelay</key>
<integer>0</integer>
<key>Timeout</key>
<integer>10</integer>
<key>ConsoleAttributes</key>
<integer>0</integer>
<key>HibernateMode</key>
<string>None</string>
<key>HideAuxiliary</key>
<false/>
<key>LauncherOption</key>
<string>Disabled</string>
<key>LauncherPath</key>
<string>Default</string>
<key>PickerAttributes</key>
<integer>17</integer>
<key>PickerAudioAssist</key>
<false/>
<key>PickerMode</key>
<string>External</string>
<key>PickerVariant</key>
<string>Auto</string>
<key>PollAppleHotKeys</key>
<false/>
<key>ShowPicker</key>
<true/>
<key>TakeoffDelay</key>
<integer>0</integer>
<key>Timeout</key>
<integer>10</integer>
I’ve got an issue where I cloned my SSD to a M.2 using CCC, and then renamed the M.2 so I could differentiate between the two. However, in the OC picklist the M.2 still displays same name as the SSD which makes it confusing as to which one is which. I have renamed the M.2 in Finder and in Disk Utility but the OC picklist doesn’t update accordingly. I’ve done deep NVRAM reset, normal NVRAM reset, rebuilt MyBootMgr (I haven’t made any bespoke changes to the standard OC setup) and blessed the M.2 boot drive but the picklist keeps displaying the M.2’s volume name as the SSD’s name it was CCC’d from. Any ideas?
Thank you Mac, you refer to a manual so I wasn’t sure what number to change it to
And that has been my previous experience as well hence why it has me miffed. I’ve restarted a couple of dozen times in the last month since I moved to the M.2, and unusually for me I’ve shut it down a lot rather than leaving it run for weeks on end. Hmmm…
I wasn’t sure if this applies to my scenario or not. If you’re positive and confirm it is the solution I should use then I’ll give it a try.
When you clone using CCC, it copies the names correctly to ALL the APFS volumes in the Group.
It does it correctly. I have never found macOS volume rename reliable.
What happens is that it does not update the .contentDetails file with the new name on the Preboot Volume for the Group.
OpenCore's Boot Picker will look for .disk_label, or .disk_label.contentDetails, or .disk_label_2x or .contentDetails and display the name in the pick list.
Since macOS (has a bug in mine opinion) that does not update those files, you see the old disk name.
So you have to manually edit the .contentDetails that has the wrong name and change it.
On the Preboot volume, that file will resides in /volumes/preboot/<UUID>/System/Library/Coreservices folder
where <UUID> is the volume UUID. You will find two volumes with UUID as their folder name.
For example, here's my Catalina disk (named CL-SSD) Group Volume:
Code:
macnb@iMac ~ % diskutil list disk3s2
/dev/disk3 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +595.1 GB disk3
Physical Store disk1s3
1: APFS Volume Free-SSD 20.2 GB disk3s1
2: APFS Volume CL-SSD - Data 200.0 GB disk3s2
3: APFS Volume Preboot 90.3 MB disk3s3
4: APFS Volume Recovery 529.0 MB disk3s4
5: APFS Volume CL-SSD 11.3 GB disk3s5
6: APFS Volume VM 1.1 GB disk3s6
macnb@iMac ~ %
-------------------------
macnb@iMac ~ % diskutil mount disk3s3
Volume Preboot on disk3s3 mounted
-------------------------
macnb@iMac ~ % ls -iahl /volumes/preboot
total 0
2 drwxr-xr-x@ 5 root wheel 160B 11 Sep 02:11 .
196361 drwxr-xr-x 11 root wheel 352B 3 Oct 19:08 ..
16 d-wx--x--t 3 root wheel 96B 10 Sep 21:34 .Trashes
118 drwxr-xr-x 6 root wheel 192B 11 Sep 02:14 583D2156-09A8-4056-ACAB-445062253CDD
658 drwxr-xr-x 5 root wheel 160B 11 Sep 02:11 6F253856-3ADE-411C-8E2A-7E92BD213FB7
macnb@iMac ~ %
-------------------------In the above example there are two UUID folders - one for the Group Volume and one for Data Volume.
Here's content of the .contentsDetails files in each volume:
Code:
macnb@iMac ~ % more /volumes/preboot/583*/System/Library/Coreservices/.contentDetails
CL-SSD
macnb@iMac ~ % more /volumes/preboot/6F2*/System/Library/Coreservices/.contentDetails
CL-SSD - Data
macnb@iMac ~ %Check the .contentDetails files in each of those folders (under System/Library/Coreservices) and change which ever one is incorrect.
No. By definition UUID's are unique so the folders are unique.
If you are asking "are the contents of each .contentsDetails files are the same ?" then the answer is no.
See my example above.
In my case, one file contains "CL-SSD" and the other has "CL-SSD - Data"
Last edited:
Good evening to all the OpenCore specialists
and first of all a huge thanks for the hard work! It is unbelievable what you offer us noobs in the world of the cheesegrate Mac Pros.
I have the following problem and I tried to find a solution in this thread, but I wasn't lucky.
I have a Mac Pro 4,1 which is updated to 5,1 with the best CPUs, RAMs as well as a Vega FE.
I put OC (0.7.3v2) on it, now it is running on Big Sur.
Now I tried to create a Windows SSD (seperate drive, no partition, Samsung 850 EVO) which went well the first try. But then I managed to crush the startup sequence, so I tried to start from square one.
But: The installation on the SSD won't start. I can see the four blue squares, but it will not start the installation process.
So I started again. I formatted the SSD with the Mac, deleted the EFI partition, tried again. Didn't work.
Then I formatted the SSD on my Windows PC, created a completely new Installer USB. Didn't work.
Now I made a full reset of everything, the index.plist, the SSD, the USB, reinstalled OC. Doesn't work.
I even let the four blue squares screen on all day to see, if it needed the time. No change.
I think, it is something really ridiculously tiny I oversee, but I don't see it.
Maybe anyone of you has had this experience before and knows a solution, I would be so happy. Tomorrow I'll try a different SSD, maybe that is, where the issue is coming from.
Thanks
kmax
and first of all a huge thanks for the hard work! It is unbelievable what you offer us noobs in the world of the cheesegrate Mac Pros.
I have the following problem and I tried to find a solution in this thread, but I wasn't lucky.
I have a Mac Pro 4,1 which is updated to 5,1 with the best CPUs, RAMs as well as a Vega FE.
I put OC (0.7.3v2) on it, now it is running on Big Sur.
Now I tried to create a Windows SSD (seperate drive, no partition, Samsung 850 EVO) which went well the first try. But then I managed to crush the startup sequence, so I tried to start from square one.
But: The installation on the SSD won't start. I can see the four blue squares, but it will not start the installation process.
So I started again. I formatted the SSD with the Mac, deleted the EFI partition, tried again. Didn't work.
Then I formatted the SSD on my Windows PC, created a completely new Installer USB. Didn't work.
Now I made a full reset of everything, the index.plist, the SSD, the USB, reinstalled OC. Doesn't work.
I even let the four blue squares screen on all day to see, if it needed the time. No change.
I think, it is something really ridiculously tiny I oversee, but I don't see it.
Maybe anyone of you has had this experience before and knows a solution, I would be so happy. Tomorrow I'll try a different SSD, maybe that is, where the issue is coming from.
Thanks
kmax
Thank you so much for sharing this information, however I'm a bit confused how to go about fixing my problem. Are you instructions only meant for Catalina and above, as I'm struggling to make sense of what I'm meant to do in Mojave.
My original SSD boot (that I cloned to the M2) is called SSDOS. My NVMe cloned drive is called SSDM2. I'm using Mojave.
SSDM2/System/Library/CoreServices/ shows invisible files
.disk_label and .disk_label 2x and .disk_label.contentDetails. When I open .contentDetails in Text Edit it already correctly contains "SSDM2", so I assume I don't need to do anything. Both .disk_label and .disk_label 2x contain indeterminate gobbledegook. Can you provide some more guidance please.