Leopard Partial Disk Recovery
I have a client with a 17" MacBookPro "MBP", and he one day begin experiencing a login/bootup problem. Another client in the same network hit one of those annoying OpenDirectory login expirations which locked him entirely out of his laptop. (APPLE FAIL). It was the same day, the same network, and similar symptoms (to the end user at least). So, I passed the 17" MBP one off to my counterpart, and I dealt with reseting the AuthenticationAuthority of the latter.
The 17" MBP suddenly booted - ONCE. After that, it was never meant to be. Upon careful investigation we discovered the following alarming facts
The drive was slowly disintegrating and produced all sorts of weird problems.
The User(tm) had not been getting good backups for Some Weeks(c).
The backups, did not include the users home directory. (WAT?)
The Users home directory. It's encrypted.
Enough suspense. We now have a Perfect Storm of exciting problems. This user is THE key person in all things related to product design and development in a company. Only the Good Lord knows how much important data there is in the 41GB of encrypted volume.
My first problem was the problem with "Mac". HFS+ is not grok'd by anything except commercial disk utilities and Mac OS X. Mac OS X, being clever, auto-mounts everything on startup. We had to have a dirty shutdown of the filesystem, and the farking journal is in an area of the disk which has gone bad. I need to mount the filesystem, read-only, no recovery, no journal.
I know that it's at least still got basic constructs. The boot process starts working and Single User Mode will almost start. Modules are clearly getting loaded, etc, etc, etc.
I grab my 15" MBP, and set to work on figuring out how to disable the automount behavior. I tried a few mac peeps whom I know. No one knows anything. I tried service centers. They know even less than my people. At length, I discovered and disabled the following services, with this handy script:
#!/bin/bash launchctl unload /System/Library/LaunchDaemons/com.apple.metadata.mds.plist launchctl unload /System/Library/LaunchDaemons/com.apple.autofsd.plist launchctl unload /System/Library/LaunchDaemons/com.apple.automountd.plist launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist
...metadata.mds.plist -- Spotlight Indexing engine.
...autofsd.plist -- Who cares, it's 'auto' and 'fs' in the same line.
...automountd.plist -- Who cares, it's 'auto' and 'mount' in the same line.
...diskarbitrationd.plist -- This is the king pin. Stop it, and Disk Utility fails, and everything auto-* stops.
Cataloging Disk Devices
I booted up, plugged in my recovery disk, saw that it was available in Finder and at /Volumes/LonghornData and I knew I was ready to proceed.
I wanted a simple, verifiable way to check which disks where what on my system. So, I checked /dev for any 'disk' entries, and saved them into a TextEdit session. For some strange reason, my laptop, and my main recovery-volume presents this way:
Tulkas:log root# ls -l /dev/disk? brw-r----- 1 root operator 14, 0 May 11 21:32 /dev/disk0 brw-r----- 1 root operator 14, 3 May 11 21:50 /dev/disk3
After connecting the 17"MBP, I found a new device - /dev/disk4 - and it has two slices, as expected:
brw-r----- 1 root operator 14, 5 May 12 09:03 /dev/disk4 brw-r----- 1 root operator 14, 7 May 12 09:03 /dev/disk4s1 brw-r----- 1 root operator 14, 14 May 12 09:03 /dev/disk4s2
Armed with enough information to proceed, I moved on.
I placed the 17"MBP in Target Disk Mode and connected up to my laptop. The files were located on the volume in /Users/.*username*. So, I mounted the disk as such:
Tulkas:Volumes root# ls -l /dev/disk? brw-r----- 1 root operator 14, 0 May 11 21:32 /dev/disk0 brw-r----- 1 root operator 14, 3 May 11 21:50 /dev/disk3 brw-r----- 1 root operator 14, 5 May 12 09:32 /dev/disk4 Tulkas:Volumes root# mkdir /Volumes/D1/ Tulkas:Volumes root# mount_hfs -o rdonly -j /dev/disk4s2 /Volumes/D1/ Tulkas:Volumes root# cd /Volumes/D1/Users/.myuser/myuser.sparsebundle/bands
After that, it was a step-by-step use of the above procedures, with "umount -f D1" after I/O Stalls which saved me. The drive made it through recovery of all 41GB of data files. As far as I can tell, it looked to be 100% success. At the time of writing, I haven't verified the encrypted data, but, that is of lesser importance (for a blog article) than such gems as DiskArbitrator and stopping auto-mount/recovery of filesystems.