Up to Something

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.

The Testing

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.

Disabling Services

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.

Practical recovery

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.

.. or how to share folders from Windows 2003 with Macs via AFP/MacFile/File Services for Machintosh

I don't know what I missed, but this is the one type of sharing that requires using Computer Management.

Right-Click My Computer, Click Manage. Click on Shared Folders. From there you can right-click white space and use New Share to create new shares. The third screen in the dialog allows you to pick Windows, Mac or both.

I have a Novatel EX720 Merlin EV-DO RevA PC-Express wireless card. It is actually a USB device that attaches via the PC slot. I use it with my MacBook Pro. When I purchased it, activation was unavailable from OS X. However, I was able to activate using Parallels. I booted Windows XP, clicked to attach the USB device and then installed the Connection Manager Software.

After install, everything worked great, it activated and things were good. The firmware update failed, it kept complaining about raw-device access errors. Later, while attempting to find a Windows Laptop with PC Express Support, I discovered an important fact about Dell PC owners: They don't know that they have a PC Express Slot, even when they do!

So, after numerous assurances from Dell-using friends and the abject SHOCK at the lack of said PC Express slot, I wrested my friends Dell Latitude away from him. In 30 seconds I learned what he didn't: it DOES have one. And people say that Mac Users are idiots. A short while (and significant chiding) later, I had the firmware updated and the card has worked well. Well, until today.

Today I plugged the card into my port and the Connection didn't come up. I tried again. Nothing. I used Quicksilver, loaded Console.app and watched the system.log.

Oct  9 21:08:40 Tulkas kernel[0]: USBF: 21191.524   [0x4d8fe00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in.  It will keep retrying.  (Port 1 of hub @ location: 0x5d000000)
Oct  9 21:08:47 Tulkas kernel[0]: USBF: 21198.964   [0x4d8fe00] The IOUSBFamily was not able to enumerate a device.

Oh... Discordia. After a short call w/ Sprint the operator preferred that I go borrow a Windows PC to troubleshoot. I told him that if he had a firm conviction that some firmware/driver/whatever hack would return this to functionality, I would do it. He finally just said, "Sir, it's really your choice". So I offered to try it, provided that he got the RMA rolling.

Congratz Sprint! Better customer service that I expected, and better service than most of my friends have ever had.