Encrypting a complete disk under ML

By chance I came across an article (don’t have a link anymore, sorry) that showed how to completely encrypt a disk under Mountain Lion if that disk isn’t the one that was booted from. I have a MacBook Pro with an SSD in the regular SATA mount and a 640GB hard disk mounted in place of the DVD drive (see here for the story on that).

For quite some time, I’d been using an encrypted DMG that would mount as a data drive for my more sensitive files, but that is quite a pain in the rear end. For one thing, you need to figure out how much space you need, because you have to pick a finite size for the DMG as you create it. So either it wastes (a lot of) disk space when not filled up or you end up having to create a bigger one and moving all your files from one to the other if it gets too small.

The advantages of a hard disk that is completely encrypted are obvious since Lion, which introduced FileVault for the primary disk. Getting secondary disks to be encrypted under ML is not an issue if you’re formatting them - FileVault 2 takes care of that with a click in the selection list:


I’ve done this with another drive I have and it worked like a charm. But what to do if you have a 640GB drive nearly 90% filled with stuff you don’t want to be moving someplace else so that you can re-format your drive?

Well, as it turns out, there is a way to do this from the command line using diskutil - see this article. As the article states, it really does take VERY LONG to do this on-the-fly encryption. At first, I was a bit uneasy, as nothing seemed to happen, but there is a way to check on progress and after a good 20 hours, my drive was encrypted.
You can check how things are progressing with diskutil cs list, which gives you a list of all devices, including the current disk chunk converted:

| +-> Logical Volume Family 5C25AA1F-0EBE-49A6-A644-BBDBF988E421
| ----------------------------------------------------------
| Encryption Status: Unlocked
| Encryption Type: AES-XTS
| Conversion Status: Converting
| Conversion Direction: forward
| Has Encrypted Extents: Yes
| Fully Secure: No
| Passphrase Required: Yes
| |
| +-> Logical Volume C52CBE5D-0065-467E-A180-6512A52CB46F
| ---------------------------------------------------
| Disk: disk3
| Status: Online
| Size (Total): 638939721728 B (638.9 GB)
| Size (Converted): 392502968320 B (392.5 GB)
| Revertible: Yes (unlock and decryption required)
| LV Name: Macintosh HD
| Volume Name: Macintosh HD
| Content Hint: Apple_HFS

The converted drive works like a charm, I didn’t notice any slow-down of my system afterwards.

The only caveat - at least I haven’t found a solution yet - is that if you have moved your user folder to this drive (which is the sensible thing to do if you have a small SSD that you boot from and a large HDD to keep data on), you will have to create an admin account that you can use to unlock the HDD after a reboot.

I.e.: log into the admin account, unlock the HDD (ideally saving the password in the admin’s keychain), then log out and log into your regular account.

Not a big issue, really.

Contacts Bugs in Mountain Lion

This issue is reproducable and obviously related to what I described in this post:
Dragging a picture, for example off a LinkedIn profile, into Contacts makes the cursor change to a green + when hovering over the picture drop zone, but letting go makes the picture “fall back” to whence it came from.

If I save it to disk (dragging it to a folder works fine) and then drag it from there to the contact I want it displayed in, the framing dialog comes up. In one instance, hitting “Done” didn’t do a thing. I had to switch back to Safari and then drag the picture to Contacts again to make it work.

The second bug comes after syncing the changes to iCloud: while the algorithm that pics out the face works well as usual in automatically cropping even large pictures, the picture contents “snap back” to the original, full-size picture contents once the contact is synced.

I’m very much looking forward to the next Mountain Lion Update (with hopes of having things fixed in there).

Mountain Lion: Image Drag-and-Drop broken?

Something new, I would call it a bug.

One of the really cool things about Mac OS has always been the ability to drag an image from the web browser, say of a person from LinkedIn, to another app, say the image well for that person’s contact.

A hugely time-saving thing to be able to do. Doesn’t work anymore.
I didn’t have this problem in Lion (or previous versions of the OS), ever.

In Mountain Lion, it seems to crop up more often than not. The image is legit - I can still drag it right out of the LinkedIn web page and drop it in a directory open in the Finder. Then, I can drag it from there to the contact card in Contacts. But not directly.

Yes, I’ve updated to 10.8.1 and no, this didn’t fix the issue.

Mountain Lion Update 3

The update from Lion to Mountain Lion turned out to be a bit more stable - at least on my MacBook - than the update from Snow Leopard to Lion (which was a complete disaster), but my opinion about upgrades from one cat to the next has firmed up: one seems well advised to do a clean install of such an update!

In addition to the already mentioned issues with the Ubiquity daemon, a few other things have cropped up. Also, a look at the current entries for Mountain Lion at support.apple.com show that there are massive issues - and quite abnormal ones - with this upgrade.

An example - at least on my MacBook - is the odd misshaping of the DropBox app. While files put into dropbox folders were still synchronized, the DropBox icon as well as the rightclick-menu entry for it disappeared.

This was relatively simple to fix - I just re-installed the current version of DropBox on top of the old app (apparently, with no ill effects), but it was a nuisance nontheless.

MacOS Mountain Lion Upgrade - Ubiquity

While Mountain Lion certainly seems more stable than the upgrade to Lion, I came across something nasty today.

While trying to get Pages to start so that I might do some work on the train, I noticed that Pages would load the inspector but nothing else and then lock up. I also noticed that a process “ubd” (which is the Ubiquity Daemon) was repeatedly restarting and using huge amounts of CPU resources. This was evident in the console log for Ubiquity, it kept coming back with an error:

[ERROR] 109710548aa [12/08/07 14:16:11.418] 768.main get_uuid_and_open_iidb:920 failed to mkdir "/Volumes/Macintosh HD/Users/Nick/Library/Application Support/Ubiquity/peer-A457E30B-FECA-D32F-0E18-059C1F0917D3-v23" (Permission denied)
[ERROR] 1097682a992 [12/08/07 14:16:11.510] 770.main ubd_main:2604 personid: 104544000
[warn] 1097b9d1c5a [12/08/07 14:16:11.595] 770.main find_existing_identity_unsafe:1104 Can't find identity. (error -25300 from SecItemCopyMatching)

There is a lot of content on this on support.apple.com (see this article).

As it happens, neither Numbers nor Keynote was coming up either. I tried deleting all the iWork com.apple.iwork.PLIST files in /library/preferences, but that didn’t help. Then - since ubd is related to iCloud, I opened the system preferences for users and - lo and behold - my Apple ID had been removed from my user account! Why? Nobody knows - perhaps this is “standard issue” for an OS upgrade, I don’t know.

In any case, as soon as I re-entered my Apple ID, ubd calmed down and iWork was startable again…

As with many of the issues reported in the article mentioned above, ubd had filled my Keychain with massive amounts of entries called com.apple.ubiquity.peer-uuid.n, where n is one of thousands of UIDs. Apparently, it was trying to generate self-signed root certificates for the missing one, but unable to do so due to the missing entry of my Apple ID.

In any case, Apple seems to really have made a complicated blunder here - there are, apparently, so many dependencies with the Apple ID and iCloud, that if something goes wrong, it tears down a large chunk of a previously running system.

MacOS Mountain Lion Upgrade - First Impression

Today, I upgraded my Lion Notebook to Mountain Lion.

The only apparent problem was with Mail - likely due to an issue with a plugin, it would freeze after about 20% of upgrading the mail database.

Some research gave the correct answer by a user called registerednderd on discussions.apple.com:

The Library folder has been hidden, starting in Lion. To access it, in finder, go to Go > Go to folder, and type "~/Library"
1. Force Quit Mail
2. Open Finder
3. Go > Go to Folder
4. Type in "~/Library/Mail/V2/MailData" (no quotes)
5. There are three files that start with "Envelopes," delete them
6. Re-open Mail
The upgrade should now proceed normally.

Thanks, registerednderd!

So far, Mountain Lion seems stable enough, time will tell.