Corrupted partitions after Carbon Copy Cloner

[davidmorr]

This is a long story that seems reminiscent of the issues people had after installing Yosemite and other things associated with CoreStorage. This monster thread describes those problems: https://forums.macrumors.com/threads/caution-yosemite-may-screw-up-partitions.1741742/

I recently bought a Mac Mini Server late 2012. It originally came with Mountain Lion installed and that suited me. It had two disks, one of which had been replaced by an SSD.

So I set it up with Mountain Lion on the SSD and it was working well. Then I decided to clone it to the HDD using Carbon Copy Cloner. I also got it to make a recovery partition on the HDD. In Disk Utility, it looked fine.

I then booted it off one of the recovery disks to check. In Disk Utility, the two disks appeared in red but were otherwise normal.

http://imgur.com/a/iJcZC

Clicking on any of the red lines brought up the error message shown. Clicking Ignore just closes the window. Clicking Fix made Disk Utility start making a Logical Volume Group. After about 10 minutes, Disk Utility was a permanent spinning beachball, so I Force Quit it. (This may not have been a good idea I realised later, but it seemed to be getting nowhere.)

[Later on, I let it go and got the beachball again. I realised that it was still using about 1% CPU time, so may still be doing something.]

http://imgur.com/a/iVKZE

Disk Utility was obviously out of its depth so I did some research and found the thread above. Booted from a USB stick with 10.8, diskutil cs list showed this:

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 79CBA286-4F8D-46C0-B7DA-CE89D2B991DC
=========================================================
Name: Internal Drive
Status: Online
Size: 1127552614400 B (1.1 TB)
Free Space: 1119023226880 B (1.1 TB)
|
+-< Physical Volume 1DB738B0-42B2-4ED6-8272-0049C12B6E90
| ----------------------------------------------------
| Index: 0
| Disk: disk0s2
| Status: Online
| Size: 127691702272 B (127.7 GB)
|
+-< Physical Volume 4D8F8B93-1B24-4F3F-8BEF-5042CB68F7FB
----------------------------------------------------
Index: 1
Disk: disk1s2
Status: Online
Size: 999860912128 B (999.9 GB)

Following the advice in the thread, I did this for the LVG:

diskutil cs delete UUID

After a few seconds, the LVG was gone. diskutil cs list said there was no core storage.

However, the two disks were still red, and clicking on either of them brought up the error message again. So there was still something odd about them.

I put the Mini into target disk mode and connected it to a Snow Leopard iMac as I figured core storage was not around then. I erased the disks using Apple Partition Map to make sure it was all changed:

diskutil eraseDisk HFS+ xxxx APM /dev/disk0

They looked fine. Reboot the Mini off a USB stick and the disks are still red. Aaaarrrggghhh!

I would have thought that repartitioning a disk would just write everything fresh and ignore anything that was still there. Especially since the reformat used APM not GUID.

All I can think of is:

1. Despite reformatting the disks, something has survived that is causing this. Does the UUID get wiped?

2. Could the system on the USB stick be caching some information and not looking at the actual disk?

3. Some hardware problem? Strange coincidence that both disks failed at the same time.

4. Could CCC have copied the UUID to the second disk, so the system thinks they are the same disk?

I would be grateful for any ideas on how to tackle this.

 

[Weaselboy]

First a little explanation. Your Mini came with what is called a Fusion drive. The OS combines the SSD and hard drive to look like one virtual drive. The OS tries to move the most frequently accessed data to the SSD portion for faster access. It really works quit well and you should consider using that setup rather than using the drive separately.

That is why Disk Utility is giving you that message. It sees you broke the Fusion drive apart and it is trying to fix it. Had you left it alone afterward you would have seen what looked like one disk and you could have just installed ML and been on your way.

So boot back to your ML key and start Disk Util and let it finish fixing the Fusion drive. Then install ML to the new Fusion virtual drive. In your earlier shot there it look like you names the Fusion drive Internal Drive and that is fine.

 

[davidmorr]

As I said, it originally had two HDDs, and one was replaced with a SSD. It was never a fusion drive. That may be what it is trying to do now, but for several years it has been happy to have them as separate disks.

I left Disk Utility running all night and it made no progress at all. What did happen is that the memory it was using gradually increased, so it sounds like there is a memory leak. Perhaps I need to try this under Sierra although Disk Utility there is crippled.

 

[MacForScience]

Your computer thinks that it is supposed to have a fusion drive. If you don't want it to be a fusion drive that is fine. The error you have is just Apple trying to be helpful–or some such.

You simply need format each drive individually and do whatever you are going to do with them. Hopefully you have a good backup in place before you started all of this.

Cheers

 

[davidmorr]

Your computer thinks that it is supposed to have a fusion drive. If you don't want it to be a fusion drive that is fine. The error you have is just Apple trying to be helpful–or some such.

You simply need format each drive individually and do whatever you are going to do with them. Hopefully you have a good backup in place before you started all of this.

Cheers

It was a new machine, so no backup needed. It does not work just formatting each one separately. It still thinks they are a fusion drive, and refuses to allow Disk Utility to verify or repair them from a recovery disk. Curiously, from a full version of OS X, it is quite happy to verify them.

Since they are both in the same machine, I will just install OS X on both of them, and if I ever need to repair a disk, will boot from the other one.