While working with a colleague to prepare a FileVault 2 rollout at his institution, he reported that in his testing, the decryption process did not appear to be working correctly when he was booted from the Recovery HD partition and using the command line diskutil-based decryption procedure that I had posted. In his testing, he was finding that the CoreStorage volume that the FileVault 2 encryption process created was not being removed when the diskutil corestorage revert command was run. The drive was being decrypted, but the CoreStorage volume was being left behind. This caused problems in his testing, because he found that rebooting afterwards led to the Mac booting to a prohibited sign.
This symbol at boot means the system has found a bootable installation of Mac OS X on the system, but there is something wrong with it.
After some additional testing, he discovered that he actually needed to run diskutil corestorage revert twice in succession. Running diskutil corestorage revert the first time would decrypt the drive. Running diskutil corestorage revert a second time following the first command would then remove the unencrypted CoreStorage volume. Once the CoreStorage volume was removed, the Mac would then be able to reboot normally to the regular boot drive.
The behavior seems to be tied to the following:
1. Booting from a Mavericks Recovery HD partition (all testing was done with a 10.9.4 Recovery HD partition.)
2. Decrypting either of the following methods:
A. Using Recovery HD‘s Disk Utility to decrypt the FileVault 2-encrypted boot drive. This decryption method is described here.
B. Running diskutil corestorage -revert from the Terminal. This decryption method is described here.
3. Letting the drive get to Conversion Progress: 100% while booted from the Recovery HD partition. Conversion Progress status can be displayed by running the diskutil corestorage list command in Terminal.
4. Rebooting back to the main boot drive once Conversion Progress: has reached 100%.
The end result is a locked CoreStorage volume that will not unlock or mount on boot, or when accessed from a Recovery HD partition or Apple’s Internet Recovery. This was the root cause for the prohibited symbol at boot that my colleague was receiving.
In my testing, I did find it was possible to decrypt the drive via Disk Utility or the command line when it was attached as an external drive (via Target Disk Mode or other means) to a Mac that was booted to a full version of OS X 10.9.x. Once decrypted, I verified that the CoreStorage volume was removed. Once I had verified that, I further verified that I could now boot normally from the previously non-bootable hard drive.
One drawback to decrypting while attached to a regular 10.9.x boot drive is that you are not able to use an Institutional Recovery Key (IRK). Using that kind of recovery key for unlocking or decryption only works when booted from a Recovery HD partition or Internet Recovery. Since that’s precisely where our problem exists, I investigated further to see if there were alternate workarounds for this problem. For more details and the workarounds I found, see below the jump.
In my testing, I identified two workarounds for this issue:
A. Reboot from the Recovery HD partition before the drive fully decrypts
It appears that the issue is specific to completely finishing decryption while booted from a Mavericks Recovery HD partition. However, if you start decryption on a drive, then reboot, decryption will continue after the reboot.
To take advantage of this behavior, I tested and verified that if you start decryption while booted from the Recovery HD partition, then reboot from the Recovery HD partition to a drive running a full version of OS X 10.9.x, decryption will complete normally. As part of the decryption process, the CoreStorage volume is properly removed and the drive is converted back to a normal HFS+ drive.
B. Decrypt using the command line and run diskutil corestorage revert twice
In my testing, I verified my colleague’s finding that running diskutil corestorage revert will decrypt the drive. Once Conversion Progress: has reached 100%, running a second diskutil corestorage revert command will result in the the CoreStorage volume being removed and converting the drive back to a normal HFS+ drive. On reboot, the formerly encrypted drive will boot normally.
When you run the first diskutil corestorage revert command, you should see output like this:
Started CoreStorage operation on disk14 Macintosh HD Core Storage LV UUID: D28C59B2-3720-4A3F-BCB0-6731338CEE44 Core Storage disk: disk0s2 Finished CoreStorage operation on disk14 Mac HD Decryption in progress; use `diskutil coreStorage list` for status
Once Conversion Progress: has reached 100% and you run the second diskutil corestorage revert command, you should see output like this:
Started CoreStorage operation on disk14 Macintosh HD Switching partition from Core Storage type to original type Reclaiming space formerly used by Core Storage metadata Ejected Logical Volume Removing Physical Volume Destroying Logical Volume Group Remounting former Physical Volume as normal disk Core Storage LV UUID: D28C59B2-3720-4A3F-BCB0-6731338CEE44 Core Storage disk: disk0s2 Finished CoreStorage operation on disk14 Macintosh HD Decryption in progress; use `diskutil coreStorage list` for status
See below for screenshots showing how this should look for the following commands:
diskutil corestorage revert UUID_here -stdinpassphrase
diskutil corestorage revert UUID_here -passphrase recoverykey_here
diskutil corestorage revert UUID_here -recoveryKeychain /path/to/FileVaultMaster.keychain
I’ve filed a bug report with Apple about this issue. If you want to duplicate it, the bug ID number is available below:
17985943
For those who want more details on the bug report, I’ve also posted the bug report information at OpenRadar:
http://openradar.appspot.com/radar?id=5885738759487488
