Apparently a new Apple software update (March 2015) is causing this 50-percent dead bug on a lot of systems, according to the Apple-authorized service place at my university. None of the solutions posted here worked for me. My hard drive now has bad sectors and must be replaced. (Thanks, Apple.)

Lesson learned: Always make sure you have a complete backup before you do any Apple updates. I have had a Time Machine problem ever since Yosemite came out, so my data backup was not up to date. Panic! Terror!

Thanks to the generosity of others, I was able to recover my own data. Here's the procedure (with links), if you ever need it:

https://github.com/macloo/recovering-mac-files

Nope, LoginLock is a Yosemite bu^H^H"feature" that has been existent since 10.10.0. Your issues are likely hardware failure unrelated to any update.

Agreed w/ @RobertHammen. Bad Sectors are much more likely a sign of hardware failure than any updates applied. Sounds like a lot of crazy and unfortunate speculation coming from that AASP if they are reporting an issue of that magnitude...

We have Apple Macbook Air's and Pro's using Active Directory Domain binding.

There is a key that can be modified to lower the timeout value for AD when connecting off-network on a FileVault2 Apple system. If the value is set too low, the user may miss password expiration notices and other AD policies.

sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

I set this to -8 to -10 and the mobile profile loaded in 10-15 seconds.

Thank you achand for this.

Did some quick tests on my test MacBook and so far it appears fixed for me as well.

Yeah, I've seen just last week a freshly-imaged Macbook Air with this 50% boot problem. Not bound, no FileVault - just stuck right after install. None of the fixes worked. I'm not above believing that it was something about the base image (autodmg created, so it seems a bit unlikely) or the imaging process (there's some... interesting... steps) but it's more than just an AD or FV issue. This one's deep I suspect.

I am trying to use the @chris.hotte method but I am unsuccessful. GNU nano does not allow me to save. It states:

[ error writing ect/rc.server: no such file or directory ]

Can someone walk me through this please? I know very little about Unix. Thanks.

Hi @bk37 Check your syntax! The directory is etc/rc.server

If UNIX isn't your thing, then you may be safer waiting for the official Apple patch....

Hi @bk37, welcome to the forum! Just so you know, this forum is designed for Mac Administrators in the business and education space and machines imaged and configured for work/education/business use. If you're having an issue with your work machine I recommend you contact your Help Desk team. If this is your personal computer, this is most likely not the place to be for a solution to the issue you're having.

Syntax error! Thanks @alexforsyth @emilykausalik If that's a nice way of saying l'm not welcome no worries. I got what I need. Good day.

@bk37 if we're lucky the next release from Apple (10.10.3) will resolve this for everyone! :)

We got to the bottom of what caused this issue in our case. I thought I'd share it because symptomatically it looks very similar.

It was stuck between the transition stage between text startup and graphical mode, at which stage loginwindow would start.

An Office update deployed through Casper on logout put down a file in the User's home directory, ~/Library/Preferences/loginwindow.plist owned by root:wheel, so the system chews on it continually with the wrong permissions, preventing the process to continue after login window. After chown'ing the directory, we haven't had an another incident.

@htse Was the 50% stuck at boot or was your problem happening when you came upon a logon screen and a user was attempting logon and then got the 50%?

It was stuck 50% stuck at boot after it passes EFILogin to decrypt the disk.

50% - fixed.

"sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>"

I set this to -8 seconds and unchecked the "Use UNC path from Active Directory to derive network home location" in Safe Mode.

MacBook Pro, Filevault, AD bind.

bielaski, thank you!

The last few Yosemite boot stuck issues, I have restarted the laptops log into safe mode, then restart them again and I am able to log back into them and the boot issue resolved itself.

It's good to know the 10.10.3 update is going to fix this. Guess I'll ride it out till then. Unfortunately, I can't get approval to roll a beta :*(

I have verified that 10.10.3 Beta fixes this issue. For now, I have been disabling UNC from Directory Utility and that works 100% of the time.

Just to clarify: While my Macs are bound to AD, I don't have UNC enabled on any of my 10.10 Yosemite Macs and I still have the 50% boot hang issue.

The most recent 10.10.3 beta does seem to have resolved the issue. The /etc/rc.server temp fix also seem to mitigate the issue on most of my Yosemite Macs, too.

Is anyone rolling the 10.10.3 in production? If so how are you doing this with imaging?

No, no I am not rolling 10.10.3 beta anything into production. ;)

Uh, yeah, its still beta, not a final release. I'd hope no-one is crazy or desperate enough to roll it out in production yet :)
Even when its final, you can bet that sucker is going to go through a lot of internal testing before we roll it out. I'm concerned it will fix one thing and break something else! In all seriousness, Yosemite has been one of the biggest headache OS X releases we've seen in years. So many problems with it. We have several open tickets with enterprise support that we're still working through of stuff that just flat out broke with this version. Apple's quality of their releases is really slipping.

any update on the 10.10.3, is the fix in the next update?

I can confirm that I have six brand new Mac Mini's with the same issue on 10.10.2. It happens every time when the power is cut by accident.

Did the rename apple.loginwindow.plist fix, and it worked fine. Only thing was that it listed an new user at login Window called Casper, with root user password for access. Curiouser and curiouser!