When a FileVault 2-encrypted Mac sits for more than a minute with an account selected at the FileVault 2 pre-boot login screen, a message like the one below should appear:
If you’re having a problem entering your password, press and hold the power button on your Mac to shut it down. Then press it again to start it up in the Recovery OS.
If the instructions are followed, the Mac will boot from the Mac’s recovery partition on the next startup and go into a FileVault 2 Reset Password wizard.
In the Reset Password wizard, there are currently three options available.
- I forgot my password
- My password doesn’t work when logging in
- My keyboard isn’t working when typing my password to login
However, if you don’t want or need to use the Reset Password wizard, there’s not an obvious way to get back to the FileVault 2 pre-boot login screen. There’s no visible way to quit, and rebooting the Mac using the power button will return you to the Reset Password wizard.
Thanks to research by the folks in the ##osx-server IRC room, it looks like there’s a relatively straightforward way to reset the boot process:
- While booted to the initial Reset Password wizard screen, press and hold the power button on your Mac to shut it down
- Reset NVRAM
- Once the NVRAM reset procedure has been completed, let the Mac boot.
At that point, you should be taken to the FileVault 2 pre-boot login screen instead of the Reset Password wizard.
Credit to arrose in the ##osx-server IRC room for figuring this out.
Update 5-28-2015: As elvisizer mentioned in the comments, there is also the option of revealing the hidden menu at the top of the screen and using the Startup Disk preferences to select your hard drive and reboot back to FileVault 2 pre-boot login screen. Since this is easier to show rather than explain, I’ve made a short video of the process.
Note: The password used to unlock the drive in the Startup Disk preferences can be the password of any account that appears on the Mac’s FileVault 2 pre-boot login screen. If you can log in at the pre-boot login screen, you should be able to enter your password to unlock.
I do a lot of work with payload-free packages and while I have a process for creating them as I needed them with pkgbuild, this approach requires some setup work. To help make the package creation process more convenient, I developed Payload-Free Package Creator.app, an Automator application that will allow to select an existing script and create a payload-free package that runs the selected script.
However, this tool has used pkgbuild‘s –nopayload function, which creates a package which doesn’t leave an installer receipt behind. This is intended behavior according to Apple, but not leaving a receipt behind can make it hard to determine whether an installer package has been run on a particular machine. This is especially problematic for Munki, which uses receipts along with other methods to track installation status.
While I don’t use Munki, I’ve heard from a number of folks who do and who had run into the no-receipt problem when they tried to use payload-free packages generated by Payload-Free Package Creator.app with Munki.
So the problem was this:
- I wanted to create payload-free packages which only run scripts and do not install files.
- I wanted to have an installer receipt.
- Apple’s built-in method for generating payload-free packages with pkgbuild didn’t provide receipts.
- I thought I needed to provide a payload to pkgbuild in order to generate a package which would provide receipts.
- Providing a payload meant I was installing files, which is what I didn’t want to do.
The matter had rested there for a while and I didn’t see a good way to fix it.
Fortunately, I was wrong about point 4. Greg Neagle recently documented that you can make a package with pkgbuild that, while not technically payload-free, will act just like one. The key is to create an empty directory and set pkgbuild‘s –root option to look there for files. pkgbuild‘s –root option is used to tell pkgbuild which files to package, but since there will be no files in an empty directory, the package will install no files on the destination Mac.
That’s where I had gone wrong on point 4 – I thought I had to give pkgbuild something to install in order to build a package with a receipt, but it turns out that pkgbuild will successfully build a package while using an empty payload directory. This information allowed me to reconcile points 1 and 2, which resolved the problem.
With this new information, I was able to update Payload-Free Package Creator.app and I’m happy to announce it has two new features:
- Version numbering
- Packages generated by Payload-Free Package Creator.app will leave receipts behind after installation.
For more details, see below the jump.
When the Office 2011 14.5.0 update was released, it was initially noteworthy for the fact that in certain circumstances it removed Office’s license. Shortly thereafter, Outlook 14.5.0 became noteworthy for the fact that Outlook’s main window (which displays the mailboxes, list of emails, calendars and other functions) was now invisible.
Another thing that was curious was that this problem did not affect everyone. It seemed to affect only those who met both of the following conditions:
- Macs running 10.10.x
- Accounts that had mailbox subfolders and had those mailbox subfolders expanded at the time of quitting Outlook.
Update – 5-22-2015: Microsoft has released Microsoft Office for Mac 2011 14.5.1 Update to address this issue. As of 5-22-2015 at 11:37 AM UTC, the 14.5.1 update is not yet available in Microsoft’s update feed for Office 2011, so it will need to be manually downloaded from Microsoft’s website. It’s available from the link below:
With this update, the procedure to fix should now be this:
1. Quit all open Office applications
2. Install the Office 2011 for Mac 14.5.1 update.
3. Once the 14.5.1 update has been installed, launch Outlook
Outlook’s main window should be visible again and work normally.
Update – 5-27-2015: The Microsoft Office for Mac 2011 14.5.1 Update is now available via the Office 2011 update feed. If you’re not familiar with updating Office 2011 for Mac, please see here for how to update using Microsoft Office’s AutoUpdate application.
Once the Microsoft Office for Mac 2011 14.5.1 Update has been installed, Outlook’s main window should be visible again and work normally.
For better or for worse, I have a large number of mailbox subfolders so I could pretty much reproduce this issue (which I quickly dubbed Inbox Invisible) on demand.
A number of suggested fixes included the following:
- Removing the Outlook preferences from ~/Library/Preferences
- Rebuilding the Outlook identity
- Deleting cache files
- Some combination of all of the above
In my testing, those fixes would work for one time. I’d launch Outlook, the main window would be there, I’d quit Outlook and re-launch it and be confronted again with Inbox Invisible.
What ultimately fixed it for both myself and those in my shop affected by this issue was the following:
- Quitting all Office applications
- Uninstalling Office 2011
- Restarting the Mac
- Reinstall Office 14.4.9 following the restart.
Outlook started working again once rolled back to 14.4.9. The weird thing was that uninstalling Office and reinstalling it fixed the issue, without needing to change anything else. This is one of the very few times I can recall when uninstalling Office 2011 and reinstalling it actually addressed a serious problem. Normally, problems with Outlook are caused by something amiss on the user account or email account level. However, it looks like there may be an explanation. For more details, see below the jump.
One of the issues I worked on this week was building a new Office 2011 installer after Microsoft released the Office 2011 14.5.0 update. I have an existing process to build a combined Office 2011 installer using Packages, which I’ve used successfully for a while.
This time though, I hit a problem. When I installed the combined Office 2011 installer with DeployStudio, then logged in, I was asked to enter a product key. Since my work has a volume license, this isn’t a screen I should ever see.
This is a problem that I’ve seen before with previous Microsoft Office 2011 installers and usually involves the license file not being applied when it should be. This behavior is seen on Macs in the following cases:
- Office 2011 is installed and then updated to 14.5.0 while nobody is logged in
- Office 2011 is installed and then updated to 14.5.0 without any Office applications being launched between the initial installation and the update.
These two scenarios will likely apply if you’re building a new machine using an automated deployment tool, but likely will not if you’re a home user.
The easiest fix I’ve found in my testing is to get the necessary volume license file from a machine that has Office 14.4.x installed on it and put it back on an as-needed basis.
The needed file is /Library/Preferences/com.microsoft.office.licensing.plist. If you have a volume-licensed version of Office 2011 installed on your Mac, you should have this file.
To address this issue, you can use Packages’ ability to add resources to a Packages-built package. See below the jump for an an example using an Office 2011 SP 4 installer package, the Office 2011 14.5.0 Update, and the com.microsoft.office.licensing.plist license file to build a unified Office 2011 14.5.0 installer package that does not prompt for a product key.
Update – 5-27-2015: The Microsoft Office for Mac 2011 14.5.1 Update has the same license-removing issue as 14.5.0. The solution is the same for both 14.5.0 and 14.5.1: put the volume license back on an as-needed basis.
I’d previously written a post about Yosemite’s FileVault 2 pre-boot recovery options and how they can be accessed via the FileVault 2 pre-boot login screen. This process uses a Reset Password wizard to help users recover from login problems at the FileVault 2 pre-boot login screen.
I recently learned that the FileVault 2 Reset Password wizard can also be manually launched while booted from the Recovery partition. For more details, see below the jump.
As part of working with OS X VMs in VMware Fusion and ESXi, I’ve regularly installed the VMware Tools and have even found ways to incorporate their installation into my build process. However, getting the latest VMware Tools installer into my VM building workflow has usually involved at least one manual step or having a system management tool handle the installation for me. I wanted something that was completely automated without needing to also install a system management client. My end goal was that I didn’t have to worry about doing anything; the latest VMware Tools for my OS X VM would just be installed into the VM as part of the build process.
After doing some research and testing, I have a solution that looks like it does just that. For more details, see below the jump.
“Take Vacations using this One Weird Trick – DOCUMENTATION!” session at Penn State MacAdmins Conference 2015
I’ll be collaborating with my colleague Vanessa White to give a lab session at the Penn State MacAdmins Conference 2015, which is being held from July 7th – 10th 2015 in State College. For those interested, our session will be a two-parter lab on Wednesday, July 8th.
For a description of what we’ll be discussing, please see the Take Vacations using this One Weird Trick – DOCUMENTATION! session description. You can see the whole list of speakers here on the Sessions page.