Following Yosemite Upgrade, FileVault 2 systems freeze on login...

[pickerin]

We've now had two instances of this issue...

Following an upgrade to Yosemite, when logging in at the FileVault 2 login, you are then taken into the user account, with the progress bar. I believe this progress bar is unlocking the drive (What's displayed is the user's account name and profile picture, with a progress bar underneath it; looks the same as the Apple logo with the progress bar, but happens after authenticating with FileVault 2.)

The progress bar gets about 1/2 way through, then stops. We let one machine sit there for 8+ hours, it never moves.

The first machine this happened on, we eventually re-imaged and restored.

Then it happened again, and this time we think we found a work-around:
1) Boot into the recovery partition.
2) Verify and Repair the drive.
3) Decrypt the drive.
4) Reboot
5) Login as the user
6) Re-encrypt the drive

At least you don't have to rebuild it from scratch.

[adamcodega]

Thanks for the post. Have you had this not happen on any machines?

I didn't experience this when I upgraded to Yosemite with FileVault 2.

[signetmac]

Happened to me this morning exactly as you described. I booted into Recovery, mounted the HD and looked over the /var/log/system.log at the spot where it hung. Checked a few times and each time it stopped shortly after the "setting hostname" part of the bootup process, with a flurry of messages:

configd[32]: InterfaceNamer: timed out waiting for IOKit to quiesce
configd[32]: Busy services :
configd[32]:   MacBookAir5,2 [2, 64295 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert [2, 60789 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/CPU0@0 [1, 59416 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/CPU0@0/AppleACPICPU [1, 59407 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/CPU0@0/AppleACPICPU/X86PlatformPlugin [!registered, !matched, 1, 59117 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/PCI0@0 [1, 60754 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI [3, 60736 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/MCHC@0 [1, 59410 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IGPU@2 [1, 59415 ms]
configd[32]:   MacBookAir5,2/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/LPCB@1F [1, 59416 ms]
configd[32]:   MacBookAir5,2/IOResources [1, 60068 ms]
kernel[0]: en1: promiscuous mode enable succeeded

Finally, I let it run for a good long time and checked again, and this time it told me immediately after that block:

kernel[0]: AppleLPC::start - Could not find IOPlatformPlugin driver.

Googled on my iPad (I'm on a bus headed for Minneapolis. See you there?) and was informed that that message had something to do with power management. So, next opportunity I had to plug my laptop into power (again, bus), it booted right up.

Go figure.

[iJake]

I had this happen on my test box but was able to get in with another account. For me it was due to the login keychain being broken on the main account. Reset the keychain and see if you are able to get in.

[aamjohns]

I experienced this also. On A/C power and wired network connection. After a long wait, I held down power button, shut off, powered on, and it then booted up.

[pickerin]

So, for us:
1) Always on power, so it doesn't seem to be the same issue that @signetmac had.
2) We didn't have a second FileVault-enabled account to use (we just use Enterprise recovery, I think I'm going to change that now), so there was no way (that I know of) to bypass the auto-login from FileVault 2 to the affected user account.
3) Multiple reboots resulted in the same issue, I even booted from a USB stick and re-installed Yosemite (thinking it may have been a corrupt install), and the issue persisted.

It's possible that the Keychain issue that @iJake mentions could be the culprit, but another instance was restored normally by decrypting the drive and then logging in, and that wouldn't have reset the Keychain.

We've had 2 systems upgrade normally (this all started due to an error in the scoping of our Caching Policy, which actually ran on everyone's system, and then they became eligible for the in-place upgrade, and about 8 machines attempted it), 2 systems that failed with this issue, and 4 systems that did not attempt the upgrade (possibly due to the removal of the policy once we noticed the mistake).

Just to make sure we're all on the same page, "long wait", is multiple hours. I left the machine I eventually had to re-image alone on that user profile screen overnight. All of my systems had a "long wait" defined as 10 minutes to perform the initial login.

[pickerin]

New update. This morning, the user's machine that I re-imaged, is doing it again. Locks at 50% or so.
I had recovered her User directory from CrashPlan PROe, so I suspect it may be her login keychain causing the issue.

However, I had enabled a local Administrator account for FileVault 2 access on this computer, so I'm now logging in as that user...guess what? Yea, it locks at 50% as well.

So, now I'm rebooting into recovery to decrypt the drive to see if that resolves the login issue. Thing is, this is a freshly imaged machine, which was FileVaulted clean from a new Mobile account (then the files were recovered). The Administrator account is a clean account as well, with no file recovery. Seems odd that it would:
a) Be happening again.
b) Be happening to a totally different user.

This makes me think it's something with FileVault 2 and Yosemite.

[CGundersen]

I started clean with Yosemite on my personal (unmanaged) late 2013 MBPr. Encrypted it and it wouldn't power down w/out some help (black screen w/ cursor). Decrypted and all is well. Looking around, there seem to be a number of posts with folks having this issue. I didn't have the aforementioned issues on boot however. I didn't see these issues with test builds on machines at work.

edit: Clarification that my issue was with inability to power down after encrypting. loginwindow seemed to be hanging on shutdown/restart. Even though "Guest" was disabled, there was some persistence where Guest account was enabled again and I believe causing issue with 10.10. After disabling Guest account (again) I'm able to shutdown as expected.

[pickerin]

Update:

Booted to Recovery Partition (seems to be hidden in Yosemite, didn't see it with Option-key boot, but CMD-R worked).
Attempted to "Turn off Encryption", got error message that it couldn't turn it off, then a message that said it was turning it off in the background, then a message that said it was completed. It wasn't, it was still encrypted.

Target disk mode the laptop to another Macintosh, Disk Utility Verify, Turn off Encryption is currently running.

[pickerin]

Update:

Well, while I was decrypting the drive I decided to look at the system.log to see if I could find anything, I did. Everything looks "normal", and I see the drive unlocked, then see the user login, and see various logs working with her local files (meaning it can see the drive correctly), then I get this:

Oct 20 09:08:55 LAPTOP.local UserAccountUpdater[566]: Launching keychain migrator
Oct 20 09:08:55 LAPTOP.local KeychainMigrator[581]: STARTING editKeyACLs
Oct 20 09:08:55 LAPTOP.local iCloudAccountsMigrator[582]: iCloudAccountMigrator: Initiating migrate accounts: V: 0, D: 0
Oct 20 09:08:55 LAPTOP.local UserAccountUpdater[566]: Blocking completion of UAU on keychain migrator
Oct 20 09:08:55 LAPTOP.local accountsd[583]: CoreData: error: -addPersistentStoreWithType:SQLite configuration:(null) URL:file:///Users/USERNAMEHERE/Library/Accounts/Accounts3.sqlite options

From that point on there are tons of errors like these:

Oct 20 09:09:16 LAPTOP.local acwebsecagent[342]: Connection : Auth key is not provided or is invalid, applying connection failure policy. CMode : 2 TMode : 1
Oct 20 09:09:16 LAPTOP.local acwebsecagent[342]: OnConnectionFailure : Fail Open - Reason = Unable to verify the license key
Oct 20 09:09:16 LAPTOP.local acwebsecagent[342]: Connection : Auth key is not provided or is invalid, applying connection failure policy. CMode : 2 TMode : 1
Oct 20 09:09:16 LAPTOP.local acwebsecagent[342]: OnConnectionFailure : Fail Open - Reason = Unable to verify the license key
Oct 20 09:09:16 LAPTOP com.apple.xpc.launchd[1] (com.apple.lakitu): The JoinExistingSession key is only available to Application services.
[...]
Oct 20 09:09:17 LAPTOP.local NotificationCenter[629]: Dock connection invalid!
Oct 20 09:09:17 LAPTOP.local NotificationCenter[629]: disconnect 0x60000011b360

Finally, it settles down and I just get:

Oct 20 09:13:44 LAPTOP.local acwebsecagent[342]: License : One or more of the License/Public Key can't be NULL
Oct 20 09:13:44 LAPTOP.local acwebsecagent[342]: SSLExt : Failed to get ScanSafe headers
Oct 20 09:13:44 LAPTOP.local acwebsecagent[342]: DownloadUpdatedConfig : Failed to download updated config. Host hostedconfig.scansafe.net. Code 0x80004005
Oct 20 09:14:22 LAPTOP.local CallHistorySyncHelper[781]: [Warning] ************* CallHistorySyncHelper timed out connecting to identityservicesd, please file a radar, and attach the stackshots generated ***********************

Repeated every 5-10 minutes...forever.

I'm now going to try blowing away the user's Keychain. The issue of course is that this also happens with my Admin account that's installed and enabled for FileVault 2, so I'm not confident it's actually a Keychain issue, but it sure looks like one.

[aamjohns]

Not sure if this is of any help but isn't a lot of that related to Cisco Web Security cloud service?

[pickerin]

Following a decryption of the drive, login works fine now.
However, while I had it mounted in Target Disk Mode, I did set the login.keychain back to the original one from imaging when I logged in as the user, which was moved to the side when CrashPlan restored the User directory.

So, it could have been either.

I also removed the Cisco AnyConnect client entirely (though I was able to log in with it still enabled, the drive and keychain had been modified though).

We're going to keep testing, but there is something amiss.

[pickerin]

Another update:

Following a reboot, the machine now locks at the Apple logo (before giving a login prompt) and freezes.

[alexjdale]

We're seeing a lot of issues with logins taking a very long time (5 minutes to an hour+) with systems that were upgraded. Pretty frustrating and inconsistent.

[pickerin]

FileVault 2 enabled or not?

[dilok]

Having the same issue here on 4 systems 2 MBA's and 2 MBP's (non retina)
Turned off FV2 on 1 MBA and worked as normal.
I'm going to turn FV2 back and see if the issue returns.

[dilok]

Well this helps :) Should have read the release notes.
http://www.intego.com/mac-security-blog/yosemite-filevault/
http://onword.co/6642

I should have read some of the comments in the first link more carefully. And the second link, doing a little research, it goes back to June of this year, meaning whatever version he was using had to have been Beta? http://onword.co/user/_dte

sigh... back to square one.

[mattbomarc1]

I have seen this on 3 machines - all upgrades from OS X 10.9.5 with FileVault enabled.

Each time I have been able to resolve by:

1) Power cycle machine, then log in as the local admin account that is FV-enabled
2) Remove the user from FileVault using 'fdesetup remove -user <username>' and then 'fdesetup sync'
3) Restart the machine, login as the local admin as in step 1
4) Add the user back to FileVault in the Security preference pane, hard-wired to the network as these are Active Directory accounts
5) Restart and have the user login again at the FileVault login screen

Step 5 usually takes a minute or two, but it does get in. Also verified the logins work offline with cached credentials.

[dilok]

I just found this a few minutes ago and thought I would share. On my test Air, the second option worked for me.
http://www.macissues.com/2014/10/27/filevault-bug-makes-yosemite-pause-or-hang-at-login/

[dwandro92]

I experienced this issue this morning on my own system and was able to resolve the problem using a much simpler method:

1. Reset the PRAM http://support.apple.com/kb/PH14222.
2. Startup in Safe Mode http://support.apple.com/kb/PH18760.
3. Reboot normally.

[spraguga]

@pickerin I would rule this out as an upgrade issue and just an overall Yosemite issue. I'm testing with a clean Yosemite base build and seeing the same results.

[alexjdale]

Yeah, I see this sometimes on new systems without FileVault, I just give it a hard restart 2 or 3 times and then it goes through.

[spraguga]

I'm getting consistent results with mobile accounts off the network. The startup/login progress bar gets to about 30%-50% and then the system just beach balls forever.

We are use to seeing the typical 2 to 3 minute login times for encrypted machines. We have removed the AD auth path to speed this up in Mavericks. However, it doesn't seem to make a difference with Yosemite.

[spraguga]

What I found so far: If the "Use UNC path from Active Directory to derive network home location" is checked in Directory Utility when an AD account is created then you cannot login to a Yosemite encrypted machine off network.

Uncheck that box, recreate the AD account, add the account to FV users, and you can login off network fine.

[spraguga]

This is a known Apple bug.

Deleting this DSCL attribute fixes the encrypted off network login issue for our environment.

OriginalHomeDirectory: <home_dir><url>smb://server/username$</url><path>/</path></home_dir>

[jtol]

Hi Spraguga,
I think you have isolated the issue pretty well. It seems to only affect Active Directory bound machines regardless of file vault or machine model. I have a machine that I upgraded from Mavericks that has this issue. At the moment when I try and search for that attribute it says attribute not found. Is there another way to fix machines that have been upgraded or migrated instead of deleting and recreating their AD accounts on the machine? This would be too time consuming for the rest of our organization.

[dgreening]

Hey Spraguga do you have a bug number for this defect from Apple? We are seeing the same issue at one of our sites which uses "unc path", and disabling it doesnt work to rectify the login hang without re-creating their account.

[spraguga]

@dgreening You can delete the attribute using the dscl command to fix current users. Apple is aware of it. However, I'm not sure if it is on their official Radar bug list.

[spraguga]

@dgreening Looked into this a little further. I'm not seeing anything for this in the open radar bug list.

http://openradar.appspot.com/

[Shawn_Waller]

@spraguga What is the DSCL command to fix the current users?

[Kaltsas]

See this discussion

https://jamfnation.jamfsoftware.com/discussion.html?id=12589

[2COlaltman]

@spraguga][/url : Your post is much appreciated, and saved my organization lots of time. Thanks!

I used your knowledge as a starting point, and did a little more testing. I was looking for a way to avoid stripping out the homedir redirection, as many Mac users in my organization use that functionality. I stumbled onto a workaround that worked for me. I was able to confirm that the workaround is successful on all the Macs in my organization that presented the issue.

TL;DR
1) Login normally until you see the progress bar
2) DONT TOUCH ANYTHING until you see the spinning pinwheel of death (~60 to 120 seconds)
3) Hit enter (if it does not immediately work, wait ~90 seconds and hit enter again)
4) Profit.

Here is a write up of this, included for clarity. I honestly laughed out loud when I figured this out.

Issue: On Macintosh computers running OSX 10.10 (Yosemite), there is an issue with logging into an Active Directory account, when “off the wire” (i.e. not on the network with access to the location that the OriginalHomedir Attribute points to.) with FileVault enabled

Symptoms: Upon login attempt from cold boot, progress bar will quickly reach ~25%, and stop, followed shortly by the cursor turning into the Apple “pinwheel” and spinning. The spinning appears to continue forever.

Suspected cause: When logging in from cold boot, with FileVault enabled, 2 things happen: 1) Filevault disk lock is “unlocked”, and 2) login to the selected account is attempted. In cases where the home directory is an unaccessible SMB share on an Active Directory account, the disk will be “unlocked” and login is successful, but OSX will throw an error dialog stating that the SMB share can not be connected. Unfortunately, at this time, it spawns that error dialog behind the login screen, where the user can not see it, nor move focus back to it if initial focus is lost.

NOTE: If one were to “Login” from cold boot with a local account that does not have an SMB Share mounted as the home directory account, log out of the local account, and then login as the network account, the dialog is spawned in the correct GUI ‘layer’, and the user is able to see it and move focus on and off of it. In this scenario, it displays the same behavior of the spinning pinwheel until the “Close” button is pressed.

Workaround: When logging in from cold boot, enter password and hit the login button or press enter, as you would normally. Once you see the progress bar, it is imperative that you not click anywhere. The cursor will be drawn on the screen at some point; if it is not on screen after 10 seconds, move the cursor around till you can see it. In between 60 and 120 seconds, the cursor will start to pinwheel. Press enter. Login should finish almost immediately and drop you onto the desktop. If it does not immediately work, wait ~90 seconds and hit enter again.

TL;DR
1) Login normally until you see the progress bar
2) DONT TOUCH ANYTHING until you see the spinning pinwheel of death (~60 to 120 seconds)
3) Hit enter (if it does not immediately work, wait ~90 seconds and hit enter again)
4) Profit.

[spraguga]

@2COlaltman][/url][/url Wow this is awesome, nice workaround! Thank you for providing this! ;)

And thank you for giving me credit, glad to be recognized on such a great forum! ;)

[analog_kid]

@2COlaltman

By golly, you're right! What a horrendously stupid bug. This begs the question: how many Apple engineers does it take to fix a dialog box which isn't appearing?

[annedelina74]

same problem here. I tried to upgrade to Yosemite from mavericks 10.9.5. The upgrade goes smoothly, and the drive in encrypted however, once i log in as any user it freezes at the user name and progress bar.

I was almost able to login as a local admin and that froze on "setting up your mac computer" after i skipped the iCloud setup.

*** Ran the suggestions of recovery mode to repair the drive.
I was able to erase my drive finally - no file vault error messages

reinstalled as a clean os Yosemite only.

Will migrate from time machine back up tonight.

[nessts]

out of curiosity, do you have mobile AD accounts (-mobile enable, or the Create Mobile account at login box checked)

[mm2270]

@2COlaltman - I just wanted to say thank you for the information you provided above. I had remembered seeing your post some weeks ago, but until a few days back had not really considered this as the cause for our Yosemite lock-ups. Turns out this is exactly what's happening, and my post located here shows how to actually reveal the dialog causing the hang condition.
https://jamfnation.jamfsoftware.com/discussion.html?id=12589#responseChild80527
I did not give you credit because when I posted this because I couldn't recall where I'd seen this information. Now that I found it again, I'll be updating my post to point folks back to this thread for credit purposes.

This bug is absolutely infuriating. I really just don't know what's going on anymore at Apple and I'm losing a lot of faith in them to deliver a good OS. We've been working with Apple enterprise support on this and have even provided snapshots of the dialog that comes up. The kicker is, even if you explicitly disable the mounting of the home share with dsconfigad by running-

dsconfigad -sharepoint disable

and

dsconfigad -useuncpath disable

and reboot, the Mac still insists on trying to mount the user's home share while off the network, so its not even respecting the setting. Ugh! Shame on Apple for such stupid bugs!

[spraguga]

@mm2270 That setting is only for mobile account creation. You need to remove the path manually from your DSCL attr. if the account was created with the UNC path enabled.

[mm2270]

@spraguga, yeah I understand, but I'm not seeing anything in the settings for the local cached account to remove to help get past the issue. Still trying to locate something that will actually help us. We're testing deleting the account from dscl and recreating it, and pairing it up with the existing home folder. I know that will likely work, but I was hoping we wouldn't need to do that for every affected client.
Also, Apple enterprise support engineering is saying that setting those to disabled should be stopping the dialog from coming up, so they may confused about what it does. But they are claiming it should work anyway.

[spraguga]

@mm2270 Did you try my fix list above which is to delete this from the user's DSCL attributes:
OriginalHomeDirectory: <home_dir><url>smb://server/username</url><path>/</path></home_dir>

If they need their home folder mounted you can create a login script or Self Service offering.