I’ll be speaking at MacTech Conference 2014, which is taking place from November 5th – 7th in Los Angeles. I’ll be talking about documentation and the various lessons I’ve learned over the years that I’ve been writing it.
You can see the entire list of speakers at http://www.mactech.com/conference/sessions. If you’ve been on the fence about attending, it’s not too late! Come attend a great conference; seats are still available.
A new feature that appeared in VMware Fusion 7 Pro was its new ESXi management. This included the ability to upload VMs from Fusion directly to an ESXi server. However, when I tried to upload OS X VMs something seemed to go wrong. The upload would work, but the OS X VM would then hang on boot.
Non-OS X VMs were uploading fine, so the problem was specific to OS X VMs. Since I could still build OS X VMs using the Windows vSphere client, I didn’t invest a lot of time into solving this issue. Fortunately, Calum Hunter was more motivated in this regard and found a solution.
There are a few things to know about if you want to upload an OS X VM to an ESXi server running 5.5, so I’ve put together a procedure for those who want to leverage Fusion 7 Pro to upload OS X VMs. See below the jump for the details.
Apple has been warning folks for the past few OS releases that the /etc/hostconfig file was going away and it looks like they decided that Mavericks was the hostconfig file’s last hurrah.
As of OS X Yosemite, /etc/hostconfig is no longer installed as part of the OS.
Thanks to Dan O’Donnell for the heads-up:
Apple’s release of Yosemite has brought with it the ability to use an Apple ID to unlock and reset a forgotten account password to log into a FileVault 2-encrypted Mac. You can use this ability in a couple of ways:
1. By setting up your iCloud account as your account on the Mac in question.
2. By associating your local or mobile network account on the Mac with an Apple ID, and selecting the option when enabling FileVault 2 to use your Apple ID to unlock the disk and reset your password.
Note: This method uses Apple’s services to store the needed FileVault 2 recovery key. If your Mac’s FileVault 2 recovery key is not being stored by Apple, you will not be able to use an Apple ID to reset your account’s ability to log into a FileVault 2-encrypted Mac.
For more details, see below the jump.
One new window that appears in Apple’s Setup Assistant application for Yosemite is one that encourages new users of Yosemite to enable FileVault 2 encryption.
However, this Setup Assistant window appears to be selective as it appears for some users but not others. After some digging with the strings command, it looks like the FileVault 2 option in Setup Assistant does not appear in the following conditions:
- The Mac is not a laptop.
- The OS is unable to check the processor for certain features.
- The processor does not support AES-NI.
- The OS is booting from an external drive.
- There’s more than one user account on the system.
- The boot drive does not have a CoreStorage logical volume set up on it.
- The boot drive is already encrypted.
- The Mac was configured by the Device Enrollment Program to not display this option.
- This window had already appeared for this drive and user account.
- The user’s home folder is located somewhere other than the boot drive.
- The user has not logged into iCloud on this machine.
These criteria can be examined using the following procedure:
- Install Xcode or the Xcode Command Line Tools.
- Once Xcode or the Xcode Command Line Tools are installed, open Terminal and run the following command:
strings /System/Library/CoreServices/Setup\ Assistant.app/Contents/SharedSupport/MiniLauncher | grep "FDE upsell"
On a 10.10.0 system, that should produce the following output:
Skipping FDE upsell, machine is not a portable Skipping FDE upsell, unable to inspect cpu features Skipping FDE upsell, unable to gather cpu features Skipping FDE upsell, CPU doesn't have AES instruction set Skipping FDE upsell, somehow running buddy on a disk image Skipping FDE upsell, not an internal volume Skipping FDE upsell, not a single user system Skipping FDE upsell, root disk is not a CSLV Skipping FDE upsell, root disk is already FDE Skipping FDE upsell, system was opted out via Device Enrollment Program setting Skipping FDE upsell, already occurred for this volume and user Skipping FDE upsell, user home volume is separate from the system volume Skipping FDE upsell, not logged into iCloud
Slides from the “Bringing the Casper Suite to Life with Virtual Test Environments” session at JAMF Nation User Conference 2014
For those who wanted a copy of my virtualization talk at JAMF Nation User Conference 2014, here are links to the slides in PDF and Keynote format.
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: