Problems decrypting FileVault 2 encrypted drives while booted from Mavericks’ Recovery HD
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:
Leave a comment
Recent Comments
 | markandlucie on Migrating a Jamf Pro AWS-hoste… |
 | Dark on Creating root-level directorie… |
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
Der Flounder 
I ran into the same problem last thursday. We use an institution recovery key. I was able to unlock the CS volume, and revert it from the recovery partition, but it never finished or removed the CS volume family like you said. After waiting about a day, I restarted the machine and got the prohibited boot sign. I then booted back into the recovery partition and attempted to unlock the drive. Unlike your scenario, the drive would unlock but it would not mount. Because it would not mount, I couldn’t use any of the diskutil CS commands to decrypt, revert, etc. I ended up having to manually mount the drive and ditto its contents to an external drive that I could then bless and use to rebuild the system.
mkdir /Volumes/Macintosh\ HD
mount -t hfs /dev/disk0s2 /Volumes/Macintosh\ HD
As I have also seen this issue with our institution, if you need any additional testing or backing, please let me know.
Wesley,
Please file your own bug report on this with your own experiences included, and feel free to reference mine. The more people that report this bug to Apple, the more likely it is to be fixed.
Wesley, I was in the same situation as you were. When I performed a diskutil cs unlock volume it would unlock, but not mount. I think it is a bad disk/sector which caused the volume to fail the CS. I ran fsck_hfs on /dev/rdisk0s2 (my volume) and it fixed errors. I did this a couple of times, and also ran fsck_hfs -Race -c 1G -y /dev/rdisk0s2/ to fix the extended attributes. When I did a revert it would not work. I followed your instructions and I could mount the drive just fine. When I did that, I found that running the diskutil cs list command showed no CS volumes. How wonderful, however, the diskutil list still showed it as a CS volume. I used gpt to rewrite the partition table to make diskutil think (since it probably was not encrypted it was a hfs and not cs volume). Had to use gpt to wipe the partition table of the bad entry and put in the new one: gpt show -l /dev/rdisk0 (shows you the partition table with information. In my case the CS volume was index 2, note down the Begin block, index, and the size). gpt remove -i 2 /dev/rdisk0 and then read it gpt add -b -i 2 -s /dev/rdisk0 I then went to the Disk Utility GUI and it found the right partition as hfs and I did a repair disk, rebooted, and it worked.
Nick, thanks so much! Your approach worked perfectly for me.
Nick, thanks for posting your solution. It worked perfectly. However, I didn’t try it until I could figure out a way to back up the partition since I am paranoid about messing with partition tables especially when I don’t have any experience with the gpt command.
Since we have an AppleCare OS support agreement I contacted Apple and they stated that the decrypted volume could be copied using the dd command even though the volume could not be mounted via diskutil. The command I used was:
dd bs=65536 if=/dev/rdisk0s2 of=backup.dmg
After about an hour (for a 256GB SSD) it was complete and I double-clicked on backup.dmg and the disk image mounted with an exact copy of everything from the unmountable drive.
Reblogged this on sea-swoon and commented:
uh oh- sounds bad!
In your testing were you able to “bring back” a machine that was rebooted after running the first iteration of the revert command? I missed the update the the blog post with the original instructions and now have an unhappy mac. The “family” says that its “Converting” “Backwards”, but I believe its stuck. I cannot rerun “revert” command a second time as the “unlockVolume” command says that the drive cannot be mounted.
DATA RECOVERED:
If you were like me and did not read this post BEFORE restarting your machine and getting the “Do Not Enter” sign as depicted above, you can follow these steps to recover your data:
Assumptions:
1. you ran the diskutil cs revert UUID -stdinpassphrase command
2. You let the decryption process finish – ie got to 100%
3. You RESTARTED your machine and got the “Do Not Enter” sign
4. You cannot mount or successfully unlock your locked volume
Recovery Procedure:
1. Find your favorite Linux live cd (i used the most recent Kali linux as of this post)
2. Boot to the linux environemnt
3. Open Disk Utility
4. Find the volume in question (NOT DISK, VOLUME)
5. Change the Partition Type to “Apple Boot”
6. Reboot to the LINUX live cd
7. Disk should automatically mount and data should be recoverable.
Hope this helps someone in the future.
BTC Tips Appreciated: 1KQReGFaBt4HoewrvFRQ6M2TUbk4vs7j1v
(Workaround A) After you have started decrypting from booting to the Recovery (command r) “then reboot from the Recovery HD partition to a drive running a full version of OS X 10.9.x”. Do I just interrupt the decrypt by restart and hold down command r again?
I read this after getting to 100% and the “Do Not Enter” sign. Is there another solution besides linux live CD?
Thanks.
I will confirm that using Disk in Linux does work. I booted off an Ubuntu install DVD – and didn’t run install – I ran Linux from the DVD – Opened ‘Disk’ and changed the setting from CoreStorage volume to HFS+ volume on Macintosh HD… Shut down restarted the Mac in single user mode – ran fsck.. rebooted into the mac and it was back…. whew….
Hello I amgrateful for your tutorial, however after I unlocked my drive and run the decrypt commands my conversion progress reads paused, what can I do to unpause it. I also see high level queries as not fully secure, has visible users and had volume key. Thanks
Oh my i befell victim to this too. Like some of the people above i could not mount my drive after unlocking. I ended up using the linux trick too, ill post that side of it in a little more detail just incase it helps someone, also this is a non-cd based workflow for people without optical drives, though i did need to use another computer (osx) to prepare the usb thumbdrive. There are equivallent tools to Mac-Linux-USB-Loader for both Windows and Linux
0. get a 2gb or larger thumb drive
1. download ubuntu desktop (i used 64bit for my macbook pro retina 2012) http://www.ubuntu.com/download/alternative-downloads
2. download mac linux usb loader and follow the instructions on the site for creating a live linux usb stick (the video is enough info to get the job done) https://sevenbits.github.io/Mac-Linux-USB-Loader/
3. insert freshly made USB in to affected computer and boot from it (either hold down ‘option’ during power up, or boot in to recovery mode, launch a terminal then ‘bless’ the thumb drive so it will auto start on next load http://macstuff.beachdogs.org/blog/?p=14)
4. once in ubuntu, find and launch the ‘drives’ program, select the partition that you are having decryption issues with (in my case ‘Macintosh HD’), and in settings for tht partition change the partition type to ‘Apple HFS+’ or ‘HFS+’.
5. Reboot and launch OSX as normal, all should work (remember to bless main partition again if you blessed the thumbdrive)