OS X 10.10.3 breaks firmware password

[skeb1ns]

Hi,

Just want to give a heads up. Our MacBooks are configured with a firmware password and are encrypted with FileVault. An upgrade from 10.10.x to 10.10.3 causes startup issues halfway the process. (You'll see the infamous folder with a question mark).

This is fixed if you remove the password in Recovery -> Unlock the disk -> select the startup disk -> Reboot -> Wait for OS X to finish the upgrade -> Reapply the firmware password.

My conclusion, don't upgrade at this time if you have a similair setup in your organisation!

[loceee]

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

[khurram]

thanks @rschenk you really saved us

[skeb1ns]

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.

[loceee]

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

[H3144-IT]

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!

[skeb1ns]

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.

[arminhempel]

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?)

[loceee]

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.

[skeb1ns]

@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.

[calumhunter]

@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

[acdesigntech]

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?)

[acdesigntech]

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

[pearlin]

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).

[mm2270]

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.

[RobertHammen]

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

[denmoff]

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.

[htse]

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.

[RobertHammen]

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

[htse]

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

[laurendc]

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.

[denmoff]

@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.

[mm2270]

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.

[RobertHammen]

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/

[mm2270]

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.

[RobertHammen]

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.

[mm2270]

I've never seen afp548 be blocked from here, and usually when something is blocked it states so in the page load. In this case I'm just getting the "Safari can't open the page" error. Strange. I'm going to try from outside the network.

Edit: Ok, something with the network here. Got it loaded on an external connection.
Anyway, looks like it may in fact be the Recovery HD update causing this. Wonderful. I have to say, I've about given up on Apple at this point. It just seems they can't get any update out anymore without some pretty major issues.

[isaacordonez]

Sorry this is a looooong thread but I don't see any answers. It's not 10.10.3 rather it's the 'OS X Yosemite Recovery Update 1.0' per the following Apple KB https://support.apple.com/en-us/HT6647 AKA com.apple.pkg.RecoveryHDUpdate.14D131

Note it happens only if you have FileVault + EFI enabled, if you just run the 10.10.3 update everything is fine.

We made a workflow that basically works around it but requires EFI be disabled until the computer is updated.

1. Extension attribute to report EFI status (Yes/none)
2. Smart group to for EFI = no
3. Smart group for Not Yosemite
4. Smart group for Has installed com.apple.pkg.RecoveryHDUpdate.14D131
5. Smart group called EFI and Recovery Update for that contains members of both EFI =no and Has installed com.apple.pkg.RecoveryHDUpdate.14D131
6. Policy to set EFI to none (BUG: you have to save the policy as command with the password first then change it to none and save again) scoped to all computers, excluding the following groups: EFI = none, Not Yosemite, Has installed com.apple.pkg.RecoveryHDUpdate.14D131.
7. Policy to enable EFI scoped to the smart group EFI and Recovery Update

Sorry for the fuzzy directions, hopefully they're enough for you guys to decipher. Anything that I should clarify?

[htse]

I decided to confront this today, expecting startup volume issues after installing the Recovery HD Update, but I wasn't able to replicate it. I verified EFI Password was enabled, and as a control updated with softwareupdate -ia, to ensure an prescribed Apple method works. After a successful install and reboot, I uploaded the packages into Casper, and applied packages onto a second client. I nervously expected it not find to the Recovery volume at restart, but it started successfully into EFI Login framework to decrypt the volume.

I performed these on Mac mini (Late 2014). I'm going to try it on a system of different model and vintage, to see if it makes a difference.

[skeb1ns]

After some testing I cam to the conclusion that the culprit is definitely the Recovery Update that is supplied with the patch.

I find it much of a hassle to figure a way out to upgrade everybody at the moment (as mentioned by iordonez for example.

I'll wait for 10.10.4 to see if apple made some changes to the process.

[Lotusshaney]

On a side note @loceee, what mods have you done to Margarita to get it to show the downloads and what looks like the OS it apples to ? Wanna share :) ?

[Lotusshaney]

@loceee, dont worry I found your git repo !!

[skeb1ns]

So 10.10.4 is out, any news on the update process from 10.10.2? Is this altered or..?