FileVault 2 decryption can be initiated but will not complete while booted from Yosemite’s Recovery HD
To address this issue that caused problems for folks decrypting from Mavericks’ Recovery HD and Internet Recovery, Apple has made a change to Yosemite’s Recovery HD and Apple Internet Recovery with regards to FileVault 2 decryption. As of 10.10, you can initiate the decryption process from Yosemite’s Recovery HD and Internet Recovery, but the actual decryption will not proceed until you have booted from a drive that is running a regular Yosemite OS install.
When you decrypt from Yosemite’s Recovery HD, you will be notified that decryption is in progress and to run the following command to check on its progress:
diskutil cs list
When checked, you should see output for Conversion Status, Conversion Direction and Conversion Progress similar to what’s shown below:
- Conversion Status: Converting
- Conversion Direction: -none-
- Conversion Progress: -none-
These statuses will not change while you’re booted from Yosemite’s Recovery HD. If you reboot and boot back to Yosemite’s Recovery HD, you should see output for Conversion Status, Conversion Direction and Conversion Progress similar to what’s shown below:
- Conversion Status: Converting
- Conversion Direction: -none-
- Conversion Progress: Paused
Once booted from a regular Yosemite OS install, you should see decryption proceed.
I had filed a bug report about the decryption behavior in Mavericks’s Recovery HD which evolved into a bug report about this behavior. The bug report has been closed by Apple and I’ve posted the bug report at Open Radar now that the Yosemite NDA has been lifted. For those interested, the details are available via the link below:
With the release of Yosemite, Apple has apparently made an undocumented change to the way it allows packages to be added to the OS installer. If you add any additional packages for installation as part of the OS install/upgrade, they must all be distribution-style flat packages. You can convert a component flat package to be a distribution-style flat packages by running the command below:
productbuild –package /path/to/component.pkg /path/to/distribution.pkg
This change is a problem for First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg, as they are both built as a bundle-style package and not as flat packages. While both First Boot Package Install.pkg and First Boot Package Install With Automated Apple Software Update.pkg run fine on Yosemite, they cannot be added to customized NetInstall images created with System Image Utility or to createOSXinstallPkg-built Yosemite OS installer packages.
To address this issue, I’ve developed First Boot Package Install Generator.app, an Automator application that will allow the selection of a folder containing installer packages and then generate a distribution-style flat package that enables the selected packages to be installed at startup. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be used as part of a createOSXinstallPkg deployment workflow. See below the jump for the details.
Starting in 10.7.2, Apple has set the iCloud sign-in to pop up on the first login.
In 10.10, Apple added a new Diagnostics & Usage window that pops up at first login after the iCloud sign-in.
Since having these pop-up windows appear may not be desirable in all Mac environments, it makes sense to be able to turn this off for new user accounts. As part of preparing for Yosemite in my own shop, I’ve developed a script that should disable both the iCloud and Diagnostics pop-ups on 10.7.2 – 10.10.0. See below the jump for the details.
Something that has usually been a manually-driven process for me has been FileVault 2 decryption when using an institutional recovery key. In large part, this is because you need to boot to either Recovery HD or Apple’s Internet Recovery. When you combine that with this known issue with decrypting when booted from Recovery HD or Apple’s Internet Recovery, it made me wish for a scripted process for decrypting when using an institutional recovery key.
Apparently, I should wish for things more often because @ttaniguti has developed a script that does precisely that. FileVault Rescue’s decrypt.sh script is designed to properly decrypt a FileVault 2-encrypted Mac using an institutional recovery key while the Mac is booted to Mavericks’ Recovery HD or Apple’s Internet Recovery.
In my testing, the script works fine on a FileVault 2-encrypted Mac running 10.9.5 and it avoids the known issues with decrypting while booted from Recovery HD by running diskutil cs revert twice at the proper times in the decryption process.
To use this script, you will need the following:
1. A FileVaultMaster.keychain file that contains the private key of your institutional recovery key.
2. The unlock password for the FileVaultMaster.keychain file stored in a plaintext file named pass.txt
Once you have both of these, copy the two files along with the decrypt.sh script to something that you’ll be able to access while booted to Mavericks’ Recovery HD or Apple’s Internet Recovery. A USB flash drive would work well here.
A YouTube video is available to show you how to use the script and I’ve linked it below:
For the past few major releases, Sophos used a standard installer package to install both their free and paid antivirus solution. With the release of Sophos Anti-Virus 9.x though, Sophos changed how their antivirus solution for Macs was installed. Sophos has now switched to using an application to install their antivirus. However, for their customers using Sophos Enterprise Console, Sophos still provides an installer metapackage. This is good news for Mac admins, but the configuration and login credentials that used to be stored in /Library/Preferences/com.sophos.sau.plist in Sophos 8.x has been overhauled in Sophos 9.x. /Library/Preferences/com.sophos.sau.plist in Sophos 9.x now no longer contains login information, only server locations.
The login credentials no longer being available in /Library/Preferences/com.sophos.sau.plist meant that the Sophos Anti-Virus client was not able to connect back to the Sophos enterprise console and receive either management or updates. Since those login credentials were working in my shop for machines in Active Directory OUs that the Sophos enterprise console was managing, that meant that those credentials were available somewhere on the system. After working on the problem in his own shop, Tim Kimpton figured out that both of the following files were needed:
Once I had this information and understood what was going on, I was able to build and deploy a Sophos Enterprise Anti-Virus for Mac OS X 9.x installer that was able to install a pre-configured set of auto-update settings. For more details, see below the jump.
Following up on a pull request by Matthew Kweskin, I’ve updated First Boot Package Install so that it now reports whether an installation has succeeded or failed. This error reporting is in addition to the error logging recorded by OS X’s installer tool to /var/log/install.log.
For those interested, here are the changes to First Boot Package Install‘s firstbootpackageinstall.sh script.
I’ve updated the First Boot Package Install GitHub repo with the new First Boot Package Install installer package, along with updating the posted firstbootpackageinstall.sh script and the Iceberg project files with the changes.
Over the weekend, Rasmus Sten posted to Twitter about an interesting uninstall command line utility that he had found while testing 10.10.
On investigation, it became apparent that this uninstall utility was not new and was available starting in 10.7.x and later. It also appears to be undocumented and has neither a man page or help pages available.
To use the uninstall tool:
1. Log into the Mac in question
2. Verify that your application was installed by the App Store
3. Open Terminal
4. Run the following command with root privileges:
5. You will be prompted to authenticate with an administrator’s username and password
6. The application should then be uninstalled.
After working with this tool, it does have some limitations. For more details, see below the jump.