Interesting - i was able to get this 10.10.2 client to hang at boot even with the rc.server file when i hard powered it down while it was at the screensaver lock. A PRAM zap brought it back to functional status.

I can verify using Casper Imaging, new Config with an rc.server file installed, the boot hang is resolved (in our lab).

I cloned our production 10.10.1 Config and just added the rc.server pkg

So this would be for new Yosemite 10.10.1 images at imaging time using Casper Imaging

When the Mac boots, the progress bar goes slowly at first and looks like it's going to hang, and then zooms thru and finishes. Booted to the Yosemite Login screen

Ok, further testing, further clarification:

I decided to do further testing on the latest beta of 10.10.2 / 14C106A.

Using Casper Imaging bringing down our Prod 10.10.1 / 14B25 Config, on the iMac that I can always reproduce this progress bar hang, and then update to 10.10.2 / 14C106A, login with AD account, then force power down.

Then power up, progress bar hang.

So it seems 10.10.2 / 14C106A does not yet address / fix this hang issue.

The patch that some users (with AppleCare Enterprise cases) received was to opendirectoryd. Check the version and date of opendirectoryd on your system after installing the latest seed of 14C106A. The answer if the patch is included in the latest beta is right there ;-)

@SamBoWick If you are an end user - this thread is not intended for you. This thread is for system administrators. If you have no idea how to implement this fix from what has already been spelled out, then wait for a fix from Apple, or try following their direction.

hi guys,

I've followed Chris.Hotte's suggestion by doing the following:


dY2CGeggMetI927vYFoh

#!/bin/sh
/bin/echo BootCacheKludge Beta 1.0 - Chris Hotte 2015 - No rights/blame reserved.
/usr/sbin/BootCacheControl jettison


TlzBb9J5hT70DnM03miB

When we loaded it, the actual Mac was no longer on the domain. Is that supposed to happen if your Mac was previously on the domain?

Thanks
Yashy

Thats odd. I tested on 40+ workstations bound to AD for a week prior to full roll out on 1500...no wait. ~2K machines under our administration. We... would have noticed AD unbinding. ;-)

so for my corporation we have only a handful of macs but they are bound to AD. Ive read every post in this forum link and tried following Chris.hotte fix. Im a windows administrator with very little background on Mac. So I hold down Command-S to get into single user mode.

I can type the string below which works fine...
mount -uw /

but when I type
/usr/bin/nano /etc/rc.server
It says "Unknown special file or file system usr/bin/nano" (without quotes)

So... aparantly I must be completely in the dark on this one. Any possible help for a noob "mac" user? Thanks

We've put the BootCacheControl jettison script on several of our machines that were seeing the "hang after hard boot" issue, and they're all back to normal now. Add me to the list of people indebted to @chris.hotte !

We were also told by Apple to give the newest 10.10.2 build a shot with this issue, but we haven't seen consistent improvement with it.

FWIW: The vast majority of the machines having the issue were MacBook Airs, bound to AD, with FileVault enabled (all of our machines are bound and encrypted... it just seems like the Airs are having the toughest time with this)

I just wanted to +1 on this issue. Seeing boot hangs on clients with 10.10.1 and AD binding.

Verbose boot on these workstations randomly shows the hang to occur at something like "en2 promiscuous mode enabled" or "DSMOS has arrived".

What is very curious is that multiple reboots eventually brings the computer to the GUI, but what could differ between reboots?

I can confirm that the chris.hotte solution about adding the rc.server file has fixed this problem in my Mac lab of about 14 workstations, most of which were hanging at boot. Many, many thanks to Chris.

Apple, you've dropped the ball on us, again.

Guys it all worked. Apologies for that.

Chris.Hotte - great script. Thank you

So Chris -- you did *nothing* with the opendirectory.d patch that was indicated above? And you can force-shutdown machines over and over with just your "jettison" option?

I just heard back from Apple about this issue. They provided a patch named opendirectoryd-2015-01-19. It seemed to do the trick on the test machines. @chris.hotte script packaged up worked as well thank you for that.

@jhbush1973 How would I go about getting that patch? I tried contacting apple for it and they said I had to call enterprise support...

Thanks

The opendirectoryd patch is being provided to Applecare Enterprise OS Support customers, it is not generally available, and is intended only for testing to ensure no reoccurrence of the AD lockout issue. I'm holding out hope it will get wrapped into 10.10.2 since 10.10.2 hasn't dropped yet (however I can still recreate the AD lockout issue on the latest developer build).

@maser][/url

So Chris -- you did *nothing* with the opendirectory.d patch that was indicated above? And you can force-shutdown machines over and over with just your "jettison" option?

Yes. I don't have the patch. I didn't know Apple Enterprise support was still around.

@Kaltsas

The opendirectoryd patch is being provided to Applecare Enterprise OS Support customers, it is not generally available, and is intended only for testing to ensure no reoccurrence of the AD lockout issue. I'm holding out hope it will get wrapped into 10.10.2 since 10.10.2 hasn't dropped yet (however I can still recreate the AD lockout issue on the latest developer build).

Not to de-rail this thread - but 'ensure no reoccurrence of the AD lockout issue'... that makes me laugh. I've never not seen OSX inappropriately lock out both AD and OD accounts. Since I can't alter policy on my AD, I loop a script to unlock all accounts every minute to render our Enterprise functional. I mean, if I turn off that script - we'd have to hire a guy just to unlock accounts all day.

@Kaltsas Pretty sure that 10.10.2 is going to drop this week, if not today, and that the opendirectoryd fix isn't included. It's likely too late in the development cycle for this. I suspect it will be like the bash fix: available as a separate download from support.apple.com, not in the SUS stream, and rolled into the next major update (10.10.3).

@chris.hotte AppleCare Enterprise is busier/more popular than ever, with the increased prevalence of Macs in corporate enterprise. I work with engineers from there quite a bit at varying client sites.

@RobertHammen if it does drop this week, it's rumored to incl some thunderbolt exploit fixes, as well as fixes for some of the 0 day flaws google released...
http://appleinsider.com/articles/15/01/23/googles-project-zero-reveals-three-new-zero-day-exploits-in-apples-os-x

http://appleinsider.com/articles/15/01/26/os-x-10102-will-fix-years-old-thunderbolt-hardware-vulnerability

@jwojda Along with numerous wifi fixes. But these have all been in the works for some time. The boot hang issue/fix is pretty new and apparently, per discussion here (cough) was not in the last released seed. There is apparantly a newer seed which may or may not be the release version. Would be incredibly surprised if this fix ends up in it. Seems like a separate release is more likely...

Looks like I have the release 10.10.2 available in my App Store updates. It no longer is listed as Pre-release…

Anyone know if the fix is in 10.10.2? I have not had time to test yet. Thanks...

10.10.2 DOES NOT contain the fix that has been tested with enterprise support.

Fail fail FAIL!!! I don't know what Apple is thinking in terms of not quickly patching issues for enterprise customers. Active Directory? FileVault2? Who uses that?

A very real answer is 'relatively' few. We are small in proportion to the Candy-Eating public.