Just wanted to chime-in with my observations, too.
Prologue:
My Desktop team bought (50) 2013 iMac 21.5" workstations for our 2014 summer Refresh. These are the second generation "thin" iMacs. The Macs arrived in July, but remained in Apple retail boxes until August where there were imaged with my 10.9.4 Mavericks production modular image (DeployStudio/NetBoot). 40 of the 50 iMacs went into production running 10.9 Mavericks last summer/fall.
The remaining (10) iMacs got pushed back due to other projects in 2014, so they didn't get deployed until Jan 2015.
By this time I had a production Yosemite 10.10.1 image ready, so the Desktop Techs re-imaged the new iMacs again, this time with my 10.10.1 Yosemite image.
According to the techs, the iMacs came up from the DeployStudio imaging process just fine once, and then the issue covered in this form post was discovered \- it affected 9 out of the 10 Yosemite iMacs. Why (10) iMac is immune to the issue is beyond me. Weird.
Before I discovered this post, we tried the following things:
Rebooting \- fixed 1 iMac. That was easy!
Zapping PRAM \- fixed 1 iMac
Running fsck and/or Recovery GUI tools \- fixed the remaining Macs
Multiple rents were required. Like a Vegas slot machine.
One of my Techs claimed that unplugging Ethernet at boot fixed 1 iMac too.
One Tech here also swears by running fsck first THEN 3 PRAM zaps.
Total voodoo. Am I on an episode of "Mac Admin PUNKED Season 2"?
I did notice a few things:
The iMacs were all stuck on a light get and dark grey boot loader screen. After the Macs were "fixed" they started booting with the new, improved sexier black screen with white logo. Related? I dunno, but there is a pattern here.
When booting into Verbose mode, All the iMacs would all get stuck at the following standard output boot message: "promiscuous mode enabled succeeded" and other output related to Apple/Broadcom driver information. This was 100% reproducible. Sounds like boot cache corruption to me...possibly.
The lowdown:
All 10 of my Yosemite iMacs are on identical 2013 or 2014 hardware.
All Macs are imaged from an identical 10.10.1 or 10.10.2 deployment image.
All Macs are bound to the same AD (with Managed Mobile cached accounts).
None of the Macs are using FV2 or any disk encryption.
Firewalls (ALF) are enabled on most iMacs but not all.
None of the Macs have Wi-Fi enabled \- they all use copper Ethernet.
No Brew or 3rd-party low-level stuff in /usr. No VMs. No BootCamp.
No 3rd-party drivers other than some HP printer stuff (from Apple's blessed SUS)
I have almost 300 Macs in production \- good thing most Macs are running 10.8 or 10.9!
Speak of the devil!
It JUST happened to me during a power blink as I was typing this post (freaky!). I now have 10+ more production 10.10.1 and 10.10.2 Yosemite Macs in boot limbo \- right this very moment. I was hoping 10.10.2 fixed this issue, but I can confidently confirm that 10.10.2 did NOT fix the issue.
Epilogue:
OK, so me and my team have figured out 2 ways to fix this based on suggestions.
Option 1:
Force a reboot (press and hold power button if needed)
Boot into Single User Mode (Command \+ S)
Run fsck -yf as needed
Reboot
Zap PRAM 3+ times
There is some confusion if zapping PRAM should be done first or last. We now think last is best.
Option 2:
(from Allister's post @ https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/)
From the recovery partition (or target-disk or single-user mode, 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*
Reboot
He optionally mentions running this too:
defaults write /Volumes/Macintosh\ HD/Library/Preferences/com.apple.loginwindow.plist DSBindTimeout -int 10
I am not doing this step on my production Macs yet, but I do have it applies to some of my IT Macs.
If need be I suppose I can add this command to my DeployStudio final setup script.
Option 3:
Call a priest and request an exorcism.
Editorial rant:
Apple is delinquent regarding this matter. This issue goes back several months ( first heard about if from a Desktop Tech here who saw it once back in October 2014). I'd call it a critical issue.
OS X 10.10.3 where are you?