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
diskutil cs list returned this:
No CoreStorage logical volume groups found
Oh, dear. So, the next step was to check with
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!
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.
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!