Recently my Macbook's hard disk started to get badblocks and I promptly managed to make a disk clone with ddrescue into an external drive through an Ubuntu live session. I successfully cloned everything without much issues.

When I plug this external drive using Ubuntu I can access all partitions. But unfortunately when I try to access this drive on macOS itself the Apple_CoreStorage partition doesn't mount.

Here's my diskutil list output:

paulofreitas@Paulos-MacBook-Pro:~$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            499.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +498.9 GB   disk1
                                 Logical Volume on disk0s2

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 TB     disk2
   1:                  Apple_HFS Storage                 2.0 TB     disk2s1

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:          Apple_CoreStorage                         499.2 GB   disk3s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk3s3
   4:                  Apple_HFS Time Machine            1.5 TB     disk3s4

The external hard drive is the /dev/disk3. The first 3 partitions are an exact copy of /dev/disk0 at the time I did the clone. The last partition Time Machine was later created with the free disk space that was left.

I can't mount /dev/disk3s2 inside macOS although I can do that when using Ubuntu. Am I missing something? What should I do to mount this partition?


From what I've understood the problem happens because both /dev/disk0s2 + /dev/disk3s2 and /dev/disk0s3 + /dev/disk3s3 shares the same disk label. My /Volumes/Macintosh HD lists the Macbook filesystem itself, ie. it's the /dev/disk1 (from /dev/disk0s2).

Actually this happens because both disk GPT GUID and partitions GPT GUIDs share the same UUIDs. I still haven't found a way or tool to change those partitions GUIDs safely (where I can mount them without compromising their data).

  • 1
    The problem here is not a disk label but the identical volume and lvg/pv/lvf/lv UUIDs. – klanomath Sep 5 '17 at 3:03
  • @klanomath Hmm, that makes a lot sense. Do you know if it's safe to use sgdisk -G (from Ubuntu) to fix this? I never used sgdisk and I don't know if it's safe to use without compromising partition data. This would probably fix the problem. :) – Paulo Freitas Sep 5 '17 at 4:58
  • 1
    AFAIK sgdisk can't handle CoreStorage containers and all its various UUIDs. – klanomath Sep 5 '17 at 5:02

I have tested your set-up in a virtual machine with the same result - the second CoreStorage volume won't be mounted. Cloning a CoreStorage container to another disk with dd doesn't change the UUIDs of the CoreStorage items. So it's indeed a problem of the duplicate UUIDs of the Logical Volume Group/Physical Volume/Logical Volume Family/Logical Volume of disk0s2 and disk3s2.

The good news is: there is a man entry for a tool which can change the UUIDs of all CoreStorage metadata objects: man csunique.

Check the disk identifier of the duplicate with diskutil list. In your example that's disk3s2.

Then the command in your case would be:

csunique -v -n /dev/rdisk3s2 #dry-run
csunique -v /dev/rdisk3s2

The bad news is: I can't find the tool/script. It's neither in the path nor can I find a file with this name elsewhere on the disk. I checked this in 10.9/10.10/10.11/Recovery HD by searching the whole disk even inside packages with FileBuddy. A Google search wasn't successful.

Work in progress

You may change the various UUIDs manually by editing the raw disk content with a tool like HexEdit or wxHexEditor of course. AFAIR the pvUUID and the lvgUUID are located at the first block of disk3s2. The pvUUID/lvgUUID has several additional occurrences in the metadata area of the Logical Volume Group of disk3s2. Don't use arbitrary (ie self-made) UUIDs but try to generate them with uuidgen or online with a UUID generator. Some bits of the UUID have a special meaning and determine UUID version or the hash algorithm.


The diskutil cs list output of the original disk:

diskutil cs list
CoreStorage logical volume groups (1 found)
+-- Logical Volume Group C451C0F6-32F9-43AB-8E59-42D21AEFF650
    Name:         SystemCS
    Status:       Online
    Size:         67859718144 B (67.9 GB)
    Free Space:   18948096 B (18.9 MB)
    +-< Physical Volume E46EF8F2-6399-45C1-B213-8628A518466D
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     67859718144 B (67.9 GB)
    +-> Logical Volume Family AAD268A6-FC66-43FC-A24E-11A1F23CA5DD
        Encryption Status:       Unlocked
        Encryption Type:         None
        Conversion Status:       NoConversion
        Conversion Direction:    -none-
        Has Encrypted Extents:   No
        Fully Secure:            No
        Passphrase Required:     No
        +-> Logical Volume 50B61719-7CB4-40D9-8AFC-F5CD37C1A66C
            Disk:                  disk3
            Status:                Online
            Size (Total):          67488448512 B (67.5 GB)
            Conversion Progress:   -none-
            Revertible:            Yes (no decryption required)
            LV Name:               SystemCS
            Volume Name:           SystemCS
            Content Hint:          Apple_HFS

The pvUUID (light violet) and lvgUUID (light yellow) appear in hex in the first block and the last block of the partition:

1st block:

enter image description here

last block:

enter image description here

and as text each four times in the last 32760 blocks (512 byte physical block size) of the partition in plist-like items.

enter image description here

  • The man page says it appeared in Lion, it is indeed nowhere else to be found? Recovery HD doesn't have it either. What kind of matrix glitching is this? – LangLangC Sep 13 '17 at 14:04
  • I contacted Apple Support and surprisingly they also don't know what happened to the csunique tool... The senior advisor that I chat told me him was able to see this tool within Mac OS X 10.8.5. Him latter proposed me a workaround to create a bootable USB stick installation and mount the cloned hard drive from there - seems reasonable at the moment. I'll further make another copy of this backup and try editing the raw disk as you suggested later. Thank you so much! – Paulo Freitas Sep 14 '17 at 4:05
  • 1
    @PauloFreitas I'm checking 10.8.5 right now: it's not available there (only the manual csunique.8 in an installed Xcode bundle). Modifying the UUIDs manually is error prone. Maybe I'll have the time later today and find all UUIDs and their block numbers and post them in my answer. BTW Until now I haven't found the Logical Volume Family UUID anywhere on the partition. – klanomath Sep 14 '17 at 4:17

Since the partitions were created with Linux, and accessible in Linux, why not use Linux to change the miscreant UUID?

How to Change the UUID of a Linux Partition (adapt to your needs and values)

Duplicated UUID’s can be a big problem on your machine. But luckily it is easy to change the UUID of a Linux partition and can be done in roughly 1-2 minutes!

The UUID of a Linux partition is the Universally Unique IDentifier of that partition. I would say with a fair bit of confidence that in this and most scenarios, the Linux partition UUID has more of a local machine scope.

This ID is used in a few places to identify the partition. The most notable being your /etc/fstab file, which manages the mounting of partitions at boot time. Here is a little snippet from mine…

1 # <file system>  <mount point>  <type>  <options>           <dump> <pass>
2 proc            /proc           proc    nodev,noexec,nosuid 0       0
3 # / was on /dev/sdc3 during installation
4 UUID=9467f4de-4231-401f-bcaa-fee718d49e85 /               ext4    errors=remount-ro 0       1
5 # swap was on /dev/sdb1 during installation
6 UUID=aabe7e48-2d11-421f-8609-7ea9d75e7f9b none            swap    sw              0       0


Why would you need to change a partition UUID?

The main reason being a clash of ID’s. Technically the likelihood of creating 2 identical UUID’s is very rare (read more on the Random UUID probability of duplicates). But there may be cases where you clone a partition using DD or Clonezilla and the clone resides on the same machine – different physical hard drive or partition.

Cloning using both the tools mentioned above will create an exact copy of the partition all the way down to the UUID – and now you have 2 partitions with the same UUID. From the example of my /etc/fstab above, the UUID is no longer unique and it will mount the first partition it finds with that UUID.

How do I change the UUID?

This isn’t hard at all.

  • First find the device path.

You can find the device path using the following command:

sudo blkid

Your output will look something like this:

sudo blkid
/dev/sdb1: UUID="aabe7e48-2d11-421f-8609-7ea9d75e7f9b" TYPE="swap" 
/dev/sdc1: UUID="9467f4de-4231-401f-bcaa-fee718d49e85" TYPE="ext4" 
/dev/sdc3: UUID="93a54a4a-e0f5-4152-ae59-2245e8d16ee4" TYPE="ext4"
/dev/sde5: UUID="9467f4de-4231-401f-bcaa-fee718d49e85" TYPE="ext4" 
/dev/sde6: LABEL="var" UUID="30433f28-1b79-4b4d-9985-fef5b1c886b5" TYPE="ext4"

Here you can see that /dev/sdc1 and /dev/sde5 have the same UUID. The path of the partition I want to change is /dev/sde5

  • Secondly, generate a UUID

This is simple, the following command will output a UUID like below:

  • Finally apply the new UUID to the partition

This is also another command, tune2fs, which will apply our new UUID to our device path:

sudo tune2fs /dev/sde5 -U f0acce91-a416-474c-8a8c-43f3ed3768f9

Done, now you can update your grub to include the correct UUID’s to reduce any risk of your system confusing the partitions.

  • This won't work because the tool can't modify the CoreStorage UUIDs (which aren't related to partition or volume UUIDs which can be another problem for the OP). – klanomath Sep 13 '17 at 14:26
  • Hm, but "using Ubuntu I can access all partitions" still leaves the option to use Linux and extract all data from the partition to one with unique UUID? – LangLangC Sep 13 '17 at 15:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .