I had been plagued with my CCC cloned NVMe drive not displaying the correct name in the OpenCore picklist, and have even written about it here in the OpenCore thread. But I have finally found a workflow that works at least for me to correct this annoyance.
Just to back up a moment first though to describe how the issue first began. My main Mojave boot drive was a SSD in a PCIe SATA III PCIe adapter - volume name SSDBoot. I cloned this to a NVMe M.2 blade, and although I renamed the NVMe volume to NVMeBoot and it shows correctly in Finder, it stubbornly displays in the OpenCore picklist as SSDBoot. So this caused me issues because the picklist would show two presentations of SSDBoot, and on occasions (after triple NVRam reset, moving drives around etc) it was difficult to distinguish between the two which one was the NVMeBoot drive.
Luckily I have received some great guidance from @MacNB2 which has enabled me to put this guide together.
The below guide works for macOS versions prior to Big Sur. I haven't discovered how to do the same thing with Big Sur or above (if it's even a problem), so if anyone does encounter the same problem with more modern macOS's then please add to this thread. @MacNB2 wrote: "With Big Sur, you will find Preboot folder in /System/Volumes".
1. Disable SIP.
Check first to see if SIP is already disabled by entering this command into Terminal:
2. Identifying the Preboot partition on the drive whose name you want to correct:
Open Terminal. Enter
3. Mount the Preboot partition:
In Terminal, enter
4. Make invisible files visible:
If you can't already see invisible files, make them visible by pressing key combination Cmd+Shift+. (period).
5. Locating the .contentDetails file that you're going to fix:
In a Finder window (in column view), click on your computer name in the sidebar. Next, click on the drive whose name you want to fix (e.g. in my example it's NVMeBoot), and then click on the Volumes folder (which is normally invisible) - the path should look like this: [computer name] > [drive whose name you want to fix] > Volumes > [drive whose name you want to fix]. You'll now see a Preboot volume listed along with all the other mounted volumes on your computer. Click on Preboot and you'll see a folder inside that's named a bunch of number and letters (e.g.
6. Fixing the name of your boot drive inside the .contentDetails file:
In Terminal, type:
In the Finder, drag the
(Note: replace
Press Enter.
Unless you get an error message, this will now contain the correct name. To check if this worked, open the
If this does not work, consider the following workaround, which was the only way I could get it to work on my two cMPs.
After step 1 above, Enable Root user:
Open Directory Utility (located at System/Library/CoreServices/Applications). Unlock the padlock, and under the Edit menu click on Enable Root User - give it a password.
Log into the Root user account you just enabled and continue from Step 2, but remove sudo from each of the commands above because it's not necessary when you are logged in as root.
It has been suggested that deleting the .contentDetails file might result in the system regenerating it correctly, thus fixing the problem. I haven't tested this yet.
I don't pretend to be an authority on these matters, and there may well be easier, safer ways of achieving the same outcome, but I haven't found one yet. I'm certainly keen to find out more on this topic so please share any links here.
Just to back up a moment first though to describe how the issue first began. My main Mojave boot drive was a SSD in a PCIe SATA III PCIe adapter - volume name SSDBoot. I cloned this to a NVMe M.2 blade, and although I renamed the NVMe volume to NVMeBoot and it shows correctly in Finder, it stubbornly displays in the OpenCore picklist as SSDBoot. So this caused me issues because the picklist would show two presentations of SSDBoot, and on occasions (after triple NVRam reset, moving drives around etc) it was difficult to distinguish between the two which one was the NVMeBoot drive.
Luckily I have received some great guidance from @MacNB2 which has enabled me to put this guide together.
The below guide works for macOS versions prior to Big Sur. I haven't discovered how to do the same thing with Big Sur or above (if it's even a problem), so if anyone does encounter the same problem with more modern macOS's then please add to this thread. @MacNB2 wrote: "With Big Sur, you will find Preboot folder in /System/Volumes".
1. Disable SIP.
Check first to see if SIP is already disabled by entering this command into Terminal:
csrutil status. If SIP is enabled, you'll need to reboot into Recovery, then select Terminal from the Tools menu and enter the command csrutil disable and reboot (or do it via RefindPlus or OpenCore if you have it configured to allow for changing SIP status).2. Identifying the Preboot partition on the drive whose name you want to correct:
Open Terminal. Enter
diskutil list and locate the drive whose name you want to fix. Each drive has a unique identifier - e.g. disk3, and each of the partitions on that drive will have their own unique identifier appended with a s and a digit - e.g. if my NVMe drive is identified as disk3, then NVMeBoot is shown with disk3s1, Preboot is shown with disk3s2, and VM is shown with disk3s3 etc, depending on what partitions are on the drive.3. Mount the Preboot partition:
In Terminal, enter
sudo diskutil mount /dev/[your Preboot identifier] and press Enter. Using the example of disk3s3 above, it will look like this: sudo diskutil mount /dev/disk3s3. Note: the Preboot partition will not be visible on the Desktop in Finder when it mounts.4. Make invisible files visible:
If you can't already see invisible files, make them visible by pressing key combination Cmd+Shift+. (period).
5. Locating the .contentDetails file that you're going to fix:
In a Finder window (in column view), click on your computer name in the sidebar. Next, click on the drive whose name you want to fix (e.g. in my example it's NVMeBoot), and then click on the Volumes folder (which is normally invisible) - the path should look like this: [computer name] > [drive whose name you want to fix] > Volumes > [drive whose name you want to fix]. You'll now see a Preboot volume listed along with all the other mounted volumes on your computer. Click on Preboot and you'll see a folder inside that's named a bunch of number and letters (e.g.
58746521-G8J1-67GH-765F-438574692345) - this is the UUID of the drive - a unique identifier. Inside it, navigate as follows: System > Library > CoreServices, and inside the latter you'll find invisible file .contentDetails.6. Fixing the name of your boot drive inside the .contentDetails file:
In Terminal, type:
sudo echo [the name you want your boot drive to display in OpenCore picklist, surrounded by quote marks] > - but don't press Enter just yet. What you've just typed should look something like this: sudo echo "NVMeBoot" > In the Finder, drag the
.contentDetails file you located in step 5 into the Terminal window. It will append the command you wrote above to include the path of the .contentDetails file, and should look something like this:sudo echo "NVMeBoot" > /Volumes/Preboot/58746521-G8J1-67GH-765F-438574692345/System/Library/CoreServices/.contentDetails(Note: replace
NVMeBoot with the name you want your drive to display in the OpenCore picklist).Press Enter.
Unless you get an error message, this will now contain the correct name. To check if this worked, open the
.contentDetails file in TextEdit - it should only contain the text name of your drive (e.g. in my case NVMeBoot).If this does not work, consider the following workaround, which was the only way I could get it to work on my two cMPs.
After step 1 above, Enable Root user:
Open Directory Utility (located at System/Library/CoreServices/Applications). Unlock the padlock, and under the Edit menu click on Enable Root User - give it a password.
Log into the Root user account you just enabled and continue from Step 2, but remove sudo from each of the commands above because it's not necessary when you are logged in as root.
It has been suggested that deleting the .contentDetails file might result in the system regenerating it correctly, thus fixing the problem. I haven't tested this yet.
I don't pretend to be an authority on these matters, and there may well be easier, safer ways of achieving the same outcome, but I haven't found one yet. I'm certainly keen to find out more on this topic so please share any links here.
Last edited:
