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.

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

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

[spraguga]

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

[Shawn_Waller]

Thank you sir!

[Shawn_Waller]

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

[akamenev47]

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 :(

[yellow]

We have Macs with PGP that also exhibit this behavior.

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

[ernstcs]

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

[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:

[Br3ck]

Have a look at this thread:

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

[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!

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