Birds Like Wires

Feed the Birds

Failed Core Storage Conversion

We have a Mac mini connected to an external storage box via FireWire. In a reasonably sensible manner, someone pointed Time Machine at one of the volumes on the DAS, thinking they should back the machine up to this location. They also thought also it would be best to encrypt the backup; very laudable.

However, this triggered a conversion process into an Apple Core Storage volume, which did not complete successfully. Luckily, OS X stopped trying and remounted the volume as HFS+. All appeared to be well, but after a reboot things were much less cheerful.

On restarting the machine, the volume was missing. Checking with diskutil list returned this layout:

/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *17.6 TB    disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Backup                  2.0 TB     disk1s2
   3:          Apple_CoreStorage                         15.6 TB    disk1s3
   4:                 Apple_Boot Boot OS X               134.2 MB   disk1s4

But diskutil cs list returned this:

No CoreStorage logical volume groups found

Oh, dear. So, the next step was to check with fsck_cs /dev/disk1s3:

   Executing fsck_cs (version 471.10.6)
** Checking volume
** disk1s3: Scan for Volume Headers
   Invalid Volume Header @ 0: unsupported format
   Invalid Volume Header @ 15591707852288: unsupported format
** disk1s3 did not complete formatting as a CoreStorage volume

Well, there’s the cause. I suppose this is rather a good thing, as the volume was not empty and Time Machine gave no warning that formatting was in it’s plan. So what about the data? Turns out that a simple mount -t hfs /dev/disk1s3 /tmpmntpoint attached the volume successfully and all of the data was still there. Phew!

Fix It

One trick might be to force the thing to mount from an /etc/fstab file. While that would work, it doesn’t repair the dodgy volume header information and because some of the higher levels of OS X haven’t been involved in the mount, you won’t have it appearing in the Finder. Or even Disk Utility. Definitely counts as a kludge, that one.

To try and fix things, I started with a filesystem check and repair:

sudo umount -f /dev/disk1s3
sudo fsck_hfs -fy /dev/disk1s3

Then some Googling turned up an undocumented feature of the asr command: adjust. Usage is pretty straightforward, so with the volume still unmounted, I used this:

sudo asr adjust --target /dev/disk1s3 --settype "Apple_HFS"
   Fsck /dev/disk1s3 ....10....20....30....40....50....60....70....80....90....100
Adjust completed successfully

This took around 15 minutes, but seeing as the volume is presented as 15.6TB, I think I can let it off on that. Afterwards, sudo diskutil list looked like this:

/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *17.6 TB    disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Backup                  2.0 TB     disk1s2
   3:                  Apple_HFS                         15.6 TB    disk1s3
   4:                 Apple_Boot Boot OS X               134.2 MB   disk1s4

The simple mount command still worked and showed all of the data, so I rebooted and was given this:

/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *17.6 TB    disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Backup                  2.0 TB     disk1s2
   3:                  Apple_HFS Drobo                   15.6 TB    disk1s3
   4:                 Apple_Boot Boot OS X               134.2 MB   disk1s4

Hooray! The volume looks fine and mounts properly again.

Coffee Break

To be honest, what I really should have done is copy everything off the volume when I first managed to get it working on the temporary mount, then start diddling with its partition. However, there was just shy of 9TB of data on there – all backed up, but remotely, so recovery would have taken weeks. Also, I don’t know about you, but I don’t have a spare 10TB drive lying around. One day I probably will, but not today.

If I hadn’t had that remote backup I would probably have approached this much more cautiously, so please bear that in mind if you wind up in a similar situation. Good luck!

← Recent Articles