We are an education environment and the root of this issue seems to stem from misuse (other than the documented issues with 10.10 having this issue). Our users like to put devices to sleep no matter what it's doing, mash the power button during boot, and all of the other fun things that can cause issues. We see the same issue frequently. We have everything from 10.9 to 10.11.5 (the issue really seemed to popup with 10.10), all bound to AD. A lot of the time, resetting the PRAM clears the issue. In the more extreme cases, booting into recovery and loading the OS over the top of itself fixes it.

@Jerod Thanks. It's weird because sometimes those things will work and other times they won't. So hit and miss. I then find myself just re-imaging the computer because nothing I troubleshoot works and I'm done spending time on it. Thanks for the info.

Yes, its an unfortunate consistent issue we face here as well. Although its gotten a bit better under 10.11 for us, almost all versions of 10.10 exhibited this problem from time to time. Oddly, 10.10.3 and 10.10.4 improved the situation and then 10.10..5 came along and things blew up again for us. As you stated, sometimes a reboot will fix it. Other times we need to do SUM and run a disk check (for us that means booting to Recovery HD and disabling the firmware password first) its incredibly annoying. And yes, our Macs are all joined to AD and have FileVault 2 enabled. In rare cases I've need to go in and disable FV2 and the firmware password from Recovery HD and reboot and then it would come right up.
Something with the combination of these settings causes this boot hang problem, but I'll be damned if I know exactly what it is.

Just curious, but do you tend to see this after a Mac gets updated with any software updates? That seems to be when we see it most frequently, like a Mac running 10.10.4 that updates using the 10.10.5 Combo Updater. User reboots and... hang! As Apple has a horrible tendency to put firmware updates within their OS updates these days, I suspect its a firmware patch being applied that causes the initial problem, until the Mac is booted into single user mode or Safe boot mode, and then it seems OK. Irritating to say the least.

@mm2270 Thanks for all the great info. I've checked updates after I've gotten it to come back and sometimes no updates have even been applied. It's so random that I can never pinpoint the issue. I'm glad to see I'm not the only one having this issue so it makes me feel a little better.

I've mainly been seeing this issue with 2012+ iMacs that get used heavily on a daily basis. They are located in a lab so I have a lot of users coming and going all day logging in and out.

When 10.10 first came out I was seeing it a lot on single user computers but seems like they fixed it and now I really only see it on these lab computers that are heavily used. Super frustrating.

We are also having this issue on 10.10 and 10.11 machines - we are a university and it mainly occurs on open access machines. It seems to have become worse recently, and we’ve also identified that it tends to take hold when machines are forcibly shutdown. Unfortunately, it becomes a catch 22 as machines that are failing to startup are then forcibly shutdown until they eventually boot.

We have noticed that on 10.11 a verbose boot will sometimes allow booting. PRAM zapping seems less reliable.
On 10.10 it also seems to occur on machines where very large numbers of users are logging in - for example print stations. That said, it is infuriatingly inconsistent and it is very difficult to advise users of a reliable fix.

From a predecessor, we had a legacy LaunchDaemon that was set to delay the loginwindow to ensure network and AD were active before the login window was. This meant it unloaded the loginwindow, waited and then re-loaded it. The weird thing here was that this caused an issue with a white screen instead of the login screen, but only on 2011 iMacs. No other hardware showed this. Of course, we didn't really need this anymore, removed it and all is well, although before doing this we were able to ssh into the machine and re launch the process.

We are running 10.10.5 throughout and we are seeing none of the above described.

With that in mind, it may be worth working through LaunchDaemons. Try shelving them and see if this makes a difference.

You may also want to, for example, check out the timings you use for sleep, standby, etc. If you try and set something that doesn't tally, perhaps this will cause something obscure like this to happen. Try and set sleep to be less than displaysleep, but not zero and you'll see something like this:

Warning: Idle sleep timings for "Battery Power" may not behave as expected.

- Display sleep should have a lower timeout than system sleep.

- Disk sleep should be non-zero whenever system sleep is non-zero.

Warning: Idle sleep timings for "AC Power" may not behave as expected.

- Display sleep should have a lower timeout than system sleep.

- Disk sleep should be non-zero whenever system sleep is non-zero.

So it may be worth testing your profiles/mcx via command line to ensure they are correct.

Thanks for the suggestion, but we've already tried clearing out LaunchDaemons/Agents, StartupItems, non-standard extensions, caches, Pram, settings and pretty much everything we can think of and are yet to find a rock-solid solution that works every time. I’ve also seen this issue happen on a similar model (it mainly seems to affect iMacs) with a non-standard image, with a quite different set of software and very minimal management.

@amosdeane It seems to only affect iMacs in my environment. I have pretty basic software installed nothing that should be causing this to happen yet it still happens. I re-imaged a culprit iMac and the following morning it was stuck on startup, less than 10 people used. I'm lost right now as to what to do now. It seems to be my Late 2013 iMacs. . .

I feel your pain; This has been a consistent problem and happens most frequently in our high traffic public Mac labs. Usually a combination of reboot, safe boot, pram reset will allow the machine to boot, but next restart all bets are off.

We've provided Apple with diagnostic data, but sadly they have been unable to resolve the problem and I'm not convinced they are allocating many resources to solving it. Statistically it's a low number of our Macs that have been affected, but because they are in high traffic locations, the problem is highly visible.

There allot of different reasons a computer can be stuck at boot.

Failed update, Failed OS Install, Disk Corruption, Failing HD.

There is nothing like an OS upgrade to bring existing issues to the surface.

If there is no detectable issues with the hard drive. (no IO errors about the drive in console, SMART status passes, disk has nothing to repair) Then re-installing the OS usually fixes the issue.

If it was OK on the original OS upgrade, but started having issues after an udpate, sometimes you can get away with a combo update.

If the disk constantly needs repair. Erase and install.
If the disk fails to repair, erase and install.

In the earlier days of mac admin. Any major OS upgrade usually meant a mass netboot erase and install. Which avoided some of these issues. But caused other issues with user data. Any time I did a mass erase and install. I would always find out there were a couple computers with bad HDs.

@tcam Yeah, so many factors that could be causing it. In my situation, no updates have been applied, disk is OK, SMART checks out although I don't trust it 100%, and I've had situations where I re-image a machine and a day later it's doing it.

Yes, likewise. We've done lots of tests, including hardware tests but unless physical issues are just not showing up in the existing tools (which is possible) it is not this. If it were, it would presumably always affect the same machines but part of the problem is that it appears to be random and re-imaged machines seem as likely to acquire the problem as existing ones. We can generally fix it, but it's the inconsistency in the method and the extra time that this then takes which is frustrating.

@chuey that's interesting to know that you're having it with iMacs as well. Don't know if it's more prevalent on machines with spinning hard drives?

@amosdeane Yes, only happening to my 21" Late 2012 iMacs with 8GB of RAM and an i5 processor, surprisingly they run like garbage with those sweet Hitatchi 1TB 5400RPM drives. I just slapped an SSD in one and have not had the issue present on it since, although it has not been getting used as much as it previously was.

What's crazier to me is I have the same image on hundreds of MacBook Airs and never seen that issue on one yet.

@Chuey interesting that you say that. We've also not been aware of people having it on MBAs.

I've been experimenting booting those 2012 iMac models off an external USB 3 drive (which even being external still improves their performance quite a bit) so I will keep an eye out to see if this occurs.

@amosdeane Yeah, eventually I'd like to replace all my late 2012 iMacs with SSDs. They already have the caddy inside, the drive is a 2.5" 1TB which is cool BUT it's 5400RPM. I'm assuming they did this because it's a lot quieter than a 7200. Just hate they make it so much harder to take front plate glass off now and you better have some VHB strips too, LAME!

I know there can be many reasons for this as suggested but this has helped me

https://www.justinsilver.com/technology/os-x-el-capitan-10-11-1-hanging-on-boot-fixed/

@BOBW Thanks for the link. I'm going to find one of the iMacs I've been having issues with and check this out.

Just wondering if other people are still having issues with this? Ours are persisting, inspite of trying the various fixes that have been suggested. We've opened a case with Apple Enterprise support and are slowly working through various diagnostics.

@amosdeane I was still having issues only with my 2012 iMac's in June. I've recreated my 10.11.5 image and also took out some applications i thought may have been causing it but I don't think so because they ran fine on my MacBook Airs all year with no problems. Really ridiculous issue when I have labs of those 2012 iMacs and that happens. 1 thing will never fix issue either, it's either reset PRAM, or boot to single user mode, or maybe it'll just work this time or re-image and even that doesn't work. I re-imaged a machine and a day later it was doing it!

Please let me know if you find out anything from Apple.

@Chuey Yes, I was hoping to be able to post something useful, but so far we haven't really learnt anything new. I will certainly post if I get anything that's conclusive.

Having the exact same issue with the same model iMac ( late 2013 ) but running the latest version of El Cap. 10.11.6. It is all 22 computers on the lab however so I'm guessing that it was most likely tied to the deployment of Office 2016 for the Mac or one of the Adobe CC Deployments. I tested all of the deployments before going all in but it didn't come up. Oh well, back to the old drawing board I guess.

@Maineboy22 Mine are also running Office 2016 with Adobe CS6 (Not CC). I imaged the machines but have not had anyone using them since summer kicked in. Man, I'm hoping this is not a problem going into this upcoming school year.

I'm having this issue too on my late 2012 iMacs in a high traffic area. They seem to do well after imaging and get worse and worse as more user accounts are created. Connected to AD. They are freezing on the loginwindow as well.

I had no issues at the beginning of the year. Yesterday I had 3 that got stuck, all 10.11.6.

I booted to single user mode > mounted the drive > and noticed 200 accounts. I trashed them, rebooted and it worked instantly on 1.

The other 2 had similar amount of users and that did not fix the problem immediately. I removed users > rebooted > reset PRAM > ran fsck -fy and then randomly got 1 more to work.

The last 1 I was not able to do anything to get it to work. Removing users, running fsck, booted into an NBI and recovery mode, nothing, I had to re-image.

Very frustrating issue. I seen this on iMac 2012's and Late 2012 Mac Minis now

On the machines that refuse to boot after resetting the PRAM, sometimes unplugging the ethernet will allow it to boot. When I use verbose boot ( cmd + v ) on the stuck machines I get this error:

kauth external resolver timed out (1 timeout(s) of 60 seconds).

I have also set and not seen a noticeable difference with the DSBindTimeout variable mentioned here.