OS X 10.10.3 breaks firmware password

Oh... this proper sucks. Yet another reason to be staging Apple updates with reposado.

thanks @rschenk you really saved us

No problem.

I don't know what the behaviour is with a fresh 10.10.3 Image though, I will create an Image with AutoDMG later this week to test this.

Thar be a mysterious FirmwareUpdate.pkg that requires further investigation. It certainly did something on my rMMP (mid 2014)

I have Issues with HDCP now (!)

On my Mid 2011 Test MacMini - iTunes purchased Content will not play, because it states that the HDMI Connection between PC & Screen is not HDCP compatible.

Although the Films & TV Shows did play just fine in HD before the 10.10.3 Update!

Small update,

http://forums.macrumors.com/showthread.php?t=1863597

This seems related to the FileVault encryption that is also configured in my regular deployment. The solution is simple but not user friendly. My advice remains the same for now.

Can't confirm on that. 10.10.3 update incl. recovery partition update worked fine for me on several iMacs and MacBook Pros while having firmware password enabled. (But we are not using FileVault, so maybe this issue is related more to encryption than to having firmware passwords enabled?)

Something going screwy with fdesetup authrestart perhaps?

And yet another firmware update delivered in / with an OS X updater which will give @Banks something to pull apart again.

Can confirm my own fv but unfirmwared passworded rMBP mid 2014 upgraded ok using bog standard softwareupdate delivery via AppStore.app.

There was an extra message during shutdown "don't turn me of!!!" which I assumed was due to a firmware update prep. A tone on first boot and then boot into installer completion.

Are you guys doing anything funky for the delivery of the updater?

I am yet to test Patchoo, or manually pushing a combo updater via another method.

@arminhempel

This issue seems to be related with filevault in combination with firmware passwords indeed. I was able to successfully enable the firmware password after I unlocked the disk in recovery and choosing that one as startup disk.

I will change my first post to make it more clear.

@rschenk can you provide the steps to replicate?

will see if i can recreate on machines here to confirm so we can open a bug report if needed

We are using both firmware passwords and FV2 encryption. 3 updates to 10.10.3 yesterday went fine. We are utilizing a caching server onsite here.

There is ONE case I am investigating where a 4th Mac started exhibiting the above behavior, but I haven't been able to confirm whether or not the update was the cause. (did it take a crap before the update, or was it in the middle of the update?)

UPDATE: the one case where the mac exhibited above behavior was not related to the upgrade. It happened before the update to 10.10.3

Just upgraded a FileVault 2/Firmware PW MacBook Air with out issue. However, I've seen the exact issue described above on an iMac running 10.10.2 and it happens at random during restart (boots to ? folder). The workaround is to boot holding down option and selecting the local drive and then it boots just fine. So, I'm not entirely sure this is solely a 10.10.3 issue, but probably a larger 10.10 issue with machines FileVaulted/Firmware protected prior to upgrade (using setregproptool).

We just heard of one report of a user who upgraded their company issued Mac to 10.10.3 and is having the question mark boot issue. Even before this was known, we tell our users to not try updating their Mac until we put it in Self Service for them, but of course many of them get a severe case of 'something-new-itis' and just go and seek out the update anyway.

I just tested out updating a 10.10.2 MacBook Air by installing the delta update from the App Store. No issues, and all our laptops have FV2 enabled and a Firmware Update in place. This one was no exception. So its not a universal issue for sure.

I wonder if this can result from a Mac that needs a firmware update and installs the 10.10.3 update from the MAS. Apple may be issuing specific updates for Macs that needs a fw update along with the 10.10.3 updater rolled together. Not the first time they've done this as we know. I think its a really bad practice to roll these together, so if that's what they are doing, I'm going to give Apple a piece of my mind - not that it will matter much other than making me feel a little better.

The firmware update is for more recent Macs, to prevent against the Thunderstrike vulnerability, I'm pretty sure.

Ran the update on a user's mac that had firmware pw and FV2 enabled. Got the folder with a question mark. Rebooted with the option key, selected the boot drive, and it did boot. On reboot, got the folder again.

In the Mac App Store, there's a separate Recovery Update that accompanies 10.10.3, I'm betting the changes the Recovery Partition means the Startup Disk variable in PRAM isn't updated to reflect it.

What if you did the Option-boot and then specified the Startup Disk in System Preferences, then restarted? Does it boot successfully?

I'm curious as to the approach. How is the update being deployed, through Apple Software Update or through package deployment in Casper?

Whew, I usually like to stage these in our testing branch anyway as a matter of caution. This provides me with good info in case I'm asked to expedite the update to SUS since we've been waiting for this. Don't have too many with 10.10.x outside IT so that's good at least. I am very curious to see if we can see this on machines that just have 10.10.3 on it (as @rschenk mentions) and will be following this thread.

@RobertHammen I found that setting the startup disk in preferences after the option-boot seems to solve the problem.

I wonder if this is definitely caused by the 10.10.3 update, or if it is caused by another update, like the Yosemite Recovery Update. I'm still hesitant to release either to my users.

We're seeing cases of Macs becoming busted when updated here as well, but I'm not convinced yet that its the 10.10.3 update (delta or Combo) that is causing it. So far in the couple of cases that have come my way, the Recovery HD update was also installed on these Macs, and I believe that's what's causing this issue.

Here's a section of the install.log from one affected system (scrubbed):

Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery:     RecoveryDonorPartitionBSD = disk0s2;
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery:     RecoveryPartitionBSD = disk0s5;
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery:     RecoveryPartitionDADiskRef = "<DADisk 0x7fbea0d22e70 [0x101ec1ed0]>{id = /dev/disk0s5}";
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery: }
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery: <--[Local dmAsyncFinishedForDisk:mainError:detailError:dictionary:]
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery: Creating recovery partition: finished
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery: "disk2" unmounted.
Apr 10 12:17:44 <hostname removed> installd[7575]: replaceRecovery: "disk2" ejected.
Apr 10 12:17:46 <hostname removed> installd[7575]: PackageKit: Writing receipt for com.apple.pkg.RecoveryHDUpdate.14D131 to /private/var/db/receipts
Apr 10 12:17:47 <hostname removed> installd[7575]: Installed "OS X Yosemite Recovery Update" (1.0)

This update looks like its literally rewriting the Recovery HD partition. I have no idea what Apple was thinking with this update. How could this not cause an issue with FV2 encrypted Macs? Or maybe its the combination of FV2 and Firmware password as has been speculated. Ours have both and are exhibiting this problem.

Here is a post from @Banks on AFP548 that seems germane to this discussion:

https://www.afp548.com/2015/04/13/return-of-the-intermittent-bricking/

Hmm, something wrong with afp548.com? I can't load either that link or the site in general. Or is it just me? Gonna try from another system in a moment.

Loads just fine for me, it's not blocked on your network, is it? If you have the ability to try from off-premise network, suggest that you do.