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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Another update:

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

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.

FileVault 2 enabled or not?

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.

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.

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.

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/

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.

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

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.

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.

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.

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>

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.