People are noticing a symptom, branded LoginLockout (credit @andrewrose), where Yosemite seemingly freezes during startup. The keyboard shows caps lock light, no mouse cursor appears, and it could either be during post-FileVault(hereafter referred to as FV2) login, or on a ‘black-screen with white apple’, normal boot. Correlated ingredients for this symptom are 10.10+, AD binding, and possibly FV2. I’ve noticed it on roughly 20% of the computers I’ve migrated, and in some instances a reimage does not clear it – the moment the computer is bound to AD, even with a clean shutdown or without FV2, the progress bar at boot starts stalling at about 1/4 in, and definitely makes no progress when reaching about halfway. You know you’re NOT having the symptom if a mouse cursor appears by about a 1/3rd into the progress bar. We started noticing it on 10.10, and its persisted through 10.10.1.
loginLockout from Allister Banks on Vimeo.
I wouldn’t go wasting your time by fixing permissions, resetting PRAM, or sacrificing rubber chickens once seasoning to taste. Maybe your environment has never seen it, maybe you don’t need cached mobile accounts, maybe playing with network adapters being active helps.
You should run “`sysdiagnose“` if you’re going to be reaching out to Apple, and maybe even “`odutil set log debug“` if you’re sure you’ve got a way to reproduce it in your environment, and then mark the time of occurrence. In any case, as this should (god-willing) have a short shelf-life, news-wise, let me just jump straight to the two fixes gathered from various sources and presumed to be the most consistently reliable, in hopes this can help someone in the meantime:
1. From the recovery partition (or target-disk or single-user mode, if you don’t have a firmware password,) deleting the following directories has sometimes been enough:
rm -rf /Volumes/Macintosh\ HD/private/var/db/BootCache*
rm -rf /Volumes/Macintosh\ HD/Library/Caches/com.apple*
Remember to unlock the drive with Disk Utility if it’s FV2-encrypted, the commands assume you’re running Terminal from the Utilities menu in the recovery partition, remember to change “Macintosh HD” to your drive label accordingly(and escaped, if necessary).
2. For the more pernicious instances of the symptom, setting this preference via defaults write has been needed, along with one more reboot:
defaults write /Volumes/Macintosh\ HD/Library/Preferences/com.apple.loginwindow.plist DSBindTimeout -int 10
(Make sure the above is all one line.) We’ve noticed it reboot on its own if this happens soon after the OS update. Man, does it feel crappy to say ‘yeah, if these don’t do the trick, just keep rebooting!’… but that’s what it seems we have to do to make it work at this point.
The above preference change overrides what is supposed to be the default value, 60 seconds, but alter if you think latency to getting a response from your DC(‘s) may be longer. As you may have experienced, waiting 60 seconds does not actually make a difference, so it’s a possibility that this code path just isn’t being folllowed properly, but that’s for Apple engineers to assess and fix. And they will, hopefully soon, but supposedly 10.10.2 betas have not successfully addressed the symptom as of yet.
Good luck, and as they said in Hill Street Blues, be safe out there.
NOTE – our apologies to those who commented on this post previously, XFox, Chris Hotte, and sonic84. The server had a hiccup and… computers, amirite?
I just got hit with this soon after upgrading to 10.10.2. AD mobile account, no FV2.