Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. Join us in person at the ninth annual Jamf Nation User Conference (JNUC) this November for three days of learning, laughter and IT love.

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

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.

Like Comment
Order by:
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by aamjohns

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by pickerin

Another update:

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by pickerin

FileVault 2 enabled or not?

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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/

Like
SOLVED Posted: by 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.
Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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>

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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/

Like
SOLVED Posted: by Shawn.Waller

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

Like
SOLVED Posted: by Kaltsas

See this discussion

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

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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! ;)

Like
SOLVED Posted: by 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?

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by nessts

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

Like
SOLVED Posted: by 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!

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by mm2270

Yeah, one a few of the accounts affected by this, the attribute doesn't exist to remove, but I'm still doing some tests.
We already have a separate app/script that launches at login via a LaunchAgent and does a check for the network, looks up their home share info and mounts it, or exits silently if not on the network or no home share is mapped to the account. So we don't want nor need the auto mounting behavior in 10.10, but actually getting it to stop short of removing and recreating the account is proving a little hard.

Anyway, thanks for the info. I'll keep checking. Maybe I just got unlucky on the ones I was doing some tests on.

Like
SOLVED Posted: by Shawn.Waller

@spraguga What is the DSCL command to remove the users home directory with DSCL, I cant figure it out for the life of me, Unless im doing something stupid lol.

Like
SOLVED Posted: by spraguga

@Shawn.Waller][/url Here you go...
dscl -u <adimin username> . -delete /Users/<user> OriginalHomeDirectory

Like
SOLVED Posted: by Shawn.Waller

Thank you sir!

Like
SOLVED Posted: by Shawn.Waller

Ever seen this error when trying to run the command? Cannot open remote host, error: DSOpenDirServiceErr

Like
SOLVED Posted: by shurkin18

So far had to restrict everyone from upgrading to Yosemite... very sporadic system failures and users are really mad with this. Just got one of the machines working with de-crypting (just started decryption, reboot and logged in right away - it continues to de-crypt at this point) the drive. Tried all possible solutions: PRAM, SMC Reset, turn off WiFi, login with connected LAN cord to our network, without the cord, without the AC power cable, tried fixing/repairing permissions and the disk.

What I am also seeing is that for users where PRAM usually helped - it no longer helps :(

Like
SOLVED Posted: by yellow

We have Macs with PGP that also exhibit this behavior.

Like
SOLVED Posted: by BruceLM

Does this only affect users that are using homedir redirection? We're suddenly seeing Yosemite upgrades freeze on first reboot after drive unlock. The boot begins and there seems to be an issue accessing the volume. We're just trying to narrow down the problem and rule potential issues in our out.

Like
SOLVED Posted: by ernstcs

We do not do home directory redirection and have this issue.

Like
SOLVED Posted: by pickerin

Just thought I'd wade back in. The issue isn't about home directory redirection, per say. The issue is about "derive home directory location", regardless of whether or not that's actually where it is...

If you have this box checked in your Active Directory bindings, which can be seen as the dscl attribute listed earlier in the thread, then you have the potential of having the issue happen:

Like
SOLVED Posted: by Br3ck

Have a look at this thread:

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

Like
SOLVED Posted: by spraguga

FileVault2 boot/login is now working on/off network now with a mobile AD account created with the UNC path checked. Tested with the default BindTimeout and a custom setting of 15 seconds. The progress bar stalls about 1/3 through during the BindTimeout and then pushes through and you are displayed the usual, 'There was a problem connecting to the server "server-name".' This was a clean 10.10.3 build test not an upgrade.

Cheers!

Like
SOLVED Posted: by MGL

We were experiencing this issue on some of our AD-bound Macs running 10.10.x with FileVault2 enabled. 2COlaltman's post was a huge help in figuring out what the root cause was for us, and I was able to find a fix.

First, the fix:
1. After a cold boot, type in a username and password, then hold "Option" and click the "->" button optional image ALT text
2. You should then get a dialog box like this: optional image ALT text
3. Check the "Remember my choice" checkbox, then click "Allow Settings"
4. This needs to be done for each user account on the Mac.

The root cause for us was that the "This computer will be managed..." dialog box will load when a Mac is bound to Active Directory and is subject to GPO's. On OS X 10.10.x, this dialog box appears behind the FileVault2 login progress bar window, so the user cannot see it and the login does not continue until someone presses "enter", which is equivalent to clicking the "Allow Settings" button. However, this is only temporary unless you can also check the "Remember my choice" checkbox. We can force this dialog box to show up at login by holding down the "Option" key when logging in.

Haven't tested this in El Capitan yet, will update this post when I or one of my coworkers get a chance.

Like