I do a lot of my application testing in VMs, so when Firefox 39.0 came out, it went into my test environment and I built a new VM to check it out.
Firefox 39.0 looked like this when I launched it in my test VM.
As part of my testing workflow, I also installed Firefox 39.0 onto a couple of actual Macs.
Firefox 39.0 looked like this when I launched it on those machines.
As you can see, two very different results were discovered as part of my testing. After a few rounds of “It’s broken in the VM, retest, it’s still broken, retest on my laptop, no problem, repeat,” I finally tracked down a Mozilla bug report that indicated that the issue was not specific to my environment and gave me the potential scope of the issue. For more information, see below the jump.
I had previously written about deploying Sophos Enterprise Anti-Virus for Mac 9.2.x, but I was recently notified that the method I had been using would stop working in a future release of Sophos.
Sophos has a KBase article about pre-configuring their installer application with the AutoUpdate settings, but I also wanted to be able to deploy Sophos using an installer package. Using the information from the KBase article, I was able to update my existing method for building an installer package for deploying Sophos Enterprise Anti-Virus for Mac 9.2.x. For the details, see below the jump.
When Yosemite was released in October 2014, one of the changes it introduced was including a new FileVault 2 enablement option in Apple’s Setup Assistant. This option encouraged new users of Yosemite to enable FileVault 2 encryption and had the choice to enable FileVault 2 selected by default.
When the encryption process began, a significant issue then appeared for a number of users where the Mac would report Encryption paused during the encryption process, then never resume the encryption process.
This produced a situation where the Mac could not complete encryption, but would not decrypt either because the encryption process had not completed. The only fix appeared to be deleting the existing CoreStorage volume, which addressed the issue at the cost of deleting everything stored on the boot drive.
Fortunately, OS X 10.10.3 includes a fix that should stop this issue from occurring on OS X 10.10.3 and later. There is also now a procedure that should fix Macs still affected by this problem. For more details, see below the jump.
I use screensharing quite a bit, both at home and at work, to connect to machines. As part of this, my process for connection has looked something like this:
1. Verify I’m on the right network.
2. On the Mac I’m connecting from, under the Go menu, select Connect to Server…
3. In the Server Address: line, enter the address of the Mac which I want to remotely connect to:
4. Logging in by entering my authentication credentials into the screensharing login window’s username and password blanks.
5. Assuming username and password are accepted, the remote Mac’s screen is displayed.
As with any task I perform frequently, I wanted to shave some time off of this process but I didn’t want to save the screensharing authentication info to my keychain (personal preference).
Fortunately, there’s an easy way to pre-define the username for the screensharing login window by adding username@ to the vnc:// address:
The username should now be filled in when the screensharing login window appears.
Since you can also make bookmarks in the Connect to Server window, my next step was saving a bookmark for the updated screensharing address.
It’s simple enough to do, but not having to manually enter the username will save me at least a few seconds every time I connect to a remote machine’s screen.
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.