I'm very glad to be able to compose this post right now.

You see, I just spent all evening thinking that I'd end up visiting the Apple Store and that the only way I'd be using my Mac again would be with a new (or newly-formatted) disk. But I outsmarted (this time) the gremlins, and fixed whatever was broken without having to reformat.

Here are the details that I believe may be relevant:

First of all, I use FileVault2 whole-disk encryption. As well, I have taken some steps to increase the effectiveness of wde on my Mac. One consequence of this setup is that every time my Mac goes to "sleep" I have to supply my password to "wake" it up. This is accomplished via a GUI pre-boot login screen. Then, once the disk decryption key is in place, the Mac finishes starting up (or waking from hibernate) and I supply my password again to get to my desktop. I've been operating this way for many months now, and it's worked great. Until now.

At 7:15 this morning, my Mac woke up and started making the beeping noise that it makes when it's doing a firmware update after rebooting, as part of a Software Update from Apple. 7:15 was the time that I had set Awaken.app to alarm (and I have the AwakenHelper.app installed to set the Mac to power-on). Note that Awaken.app almost never gets the chance to play its wake-up sound, because although the AwakenHelper powers up the Mac at the right time of day, it has no way to complete the pre-boot authentication check, and so it never gets to the point of running user-mode code. I normally just wake up to the sound of the Mac powering on (the noise that the optical drive makes on power-up wakes me up). But the noise I heard at 7:15 was not that sound, it was the firmware alarm sound I've heard before when a Software Update includes a firmware payload. Anyway, I did not try to diagnose the problem at that time, but upon noticing that it was not the expected alarm sound, I simply mashed the power button long enough for it to shut up.

Fast-forward to when I get home from work around 4:30 PM. Having a community emergency-preparedness fair at my church in the evening, I didn't have a lot of time to spend figuring out what was wrong with it, but nevertheless ascertained that the laptop would not boot.

After the preparedness fair was over, I booted the Mac into the Recovery partition, tried a few troubleshooting steps recommended by Apple in this situation, and nothing worked. Indeed, when I attempted to startup in single-user mode, the startup sequence hung waiting for the root device. At this point, Apple appears to have recommended that I give up and reinstall the OS.

I don't always give up that easily.

Since I suspected that the problem had to do with the whole-disk encryption, I booted back into the Recovery partition, and started the Disk Utility, unlocking the boot volume, and running filesystem checks against it. The checks showed absolutely no problem at all with the volume. At this point, I'm convinced that the problem is related to whatever data is normally used by the firmware to accomplish the pre-boot authentication to unlock the encrypted volume. I hypothesized that if I could decrypt the volume using the normal Apple tools, then those tools would set things right with the firmware pre boot sequence.

That hypothesis appears to be supported by the fact that as soon as the volume was finished decrypting, I was able to reboot, login, and begin composing this blog post.

Of course, anyone who has persevered to read this far, is wondering how I managed to decrypt the volume, since the System Preferences.app is not available in the Recovery partition. The answer is, use the Terminal.app in the Recovery partition's Utilities menu, and at the command line, run diskutil coreStorage list, and note the UUID of the Logical Volume whose Volume Name matches the name of your Startup Disk. Next, run the command: diskutil coreStorage revert <THAT UUID>. The program will prompt you for the encryption passphrase, which you should be able to use the login password for an account that could normally unlock the volume. Then, wait wait wait while the volume is decrypted. You can monitor the progress by running diskutil coreStorage list and noting the difference between Size (Total) and Size (Converted) of that same volume. When those numbers are equal, issue the command shutdown -r now, and if you're as lucky as I was, you'll be able to login to your decrypted boot volume. Of course, if you were paranoid enough to be using FileVault in this way, you'll probably want to re-reverse the encryption.


I'll come back here and comment on this post to let you know how that step turns out for me ;)

GoogleBotz eating AppEngine quotas

Lolz. I checked the admin site of my pet AppEngine project awhile ago, to discover that I was at 50% of quota on frontend instance hours for the 24-hour period ending in another 4 hours.

Since the app is far from finished, and I haven't published about it, I was wondering who on Earth was using it... and why so much. As it turns out, the GoogleBot was indexing the pdf file that I had uploaded... repeatedly. I don't know if there is something wrong with how I've linked to the indicated file, or whether it's simply too big for the bot to digest, or what, but I've finally found the motivation to update my robots.txt file!