My testing with a late-2011-era MBP is that if I hard-reboot it over and over (strictly to test this issue) it will successfully boot maybe 30% of the time. With the Air that I tested with, it reboots almost all the time (maybe 1 failed boot in over 20+ attempts).
This is testing without any of the fixes.
@smitty1923 You can do this on each users' machine, or you can do this on an admin machine and follow the instructions to create a package in Composer/policy to deploy to all 10.10.x users. I would strongly suggest the latter approach.
Does the Apple Enterprise fix seem to pretty reliably fix the issue then? Do machines require rebinding to AD afterwards?
@alexforsyth Yes it appears to reliably fix the issue, no it does not require rebinding. However our support contact has no information as to when the product team will implement it. I fear it won't be until 10.10.3 which would be weeks if not months out. I am uncomfortable rolling out prerelease software that apple insists I not use in a production environment so I am reluctant to utilize it in the wild.
Does anyone have the capacity to reverse engineer the the Enterprise patch? At the very least run 'strings' on the new files. Even better is when the dev team forgets to remove the debugger info.
I was stunned to discover in 2 test cases yesterday that the verbose startup (Cmd-V) allowed Macs affected by this to boot. Might have just been quirks, but if you're in a hurry, there ya go!
Verbose mode didn't work for me. It still hung. The single user mode fix given by @Kaltsas worked for me like a charm. Props to him! Apple needs to get on this ASAP
Is anybody having issues again with Apple's 10.10.2 release? I've had Chris Hotte's solution in for a couple of weeks now on 10.10.1 and it's been a life saver. Just had a couple of users coming across again now with the same symptoms and they're running 10.10.2.
This happened on a brand new iMac binded only to Active Directory, no other software/configs installed.
Planning on testing 10.10.2, hopefully Apple has fixed this.
I am still seeing the issue on 10.10.2 bound to AD and encrypted. My own work mac Is being affected by this issue as well.
I've had the same problem with 10.10.2. But Chris's rc.server file fixes it. So I am able to deploy the upgrade as long as I put that rc.server file on the user's system. When this is fixed, I can delete that fie.
I have found that if I delete the key for the "OriginalHomeDirectory" I am able to reboot the machine, however we lose the convenience of having the homefolder shortcut in the dock. I am more annoyed that this has not been resolved since this is suppose to be a native function of the operating system. I will try Chris's rc.server file fix again. Annoyed that Apple has not produced a fix for this issue.
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?
Haven't had a problem on 10.10.2. But, judging from your responses; I'll stick to 10.9.5!
EDIT:
I take back what I said, it's even worse than before. Back to 10.9.5
@dstranathan - do you have AppleCare Enterprise? If so, open a case and get the opendirectoryd test fix.
Hey, has anyone seen an issue when after adding @chris.hotte's fix, the non-boot issues comes back after moving the Mac to a different subnet? We're getting reports from one of our remote offices that this is the case.
@RobertHammen I do not currently have AppleCare Enterprise. Sounds like Apple is testing a fix, etc?
@acdesigntech We did see situations in which unplugging physical Ethernet during the hang state allowed some 10.10.2 iMacs to continue to boot. However, Im not sure if we ever moved any Macs logically - I doubt it. I didn't witness this, but co-workers did.
We tried @chris.hotte rc.server trick. This hasn't produced a consistent fix for us. The first time we will get 50% boot, we will hard reboot again and then the system will normally boot. If we hard shut down from a full booted os, we will boot to 50% again and then have to hard boot once more to get it back to fully boot state.
@dstranathan Enterprise support is currently working with Engineering for a fix.
Just as a disclaimer for anyone working with Enterprise Support to keep interactions/patches quiet as we are all bound to an NDA.
Oh @joecurrin, that's a pity if true. Most other users on here reported consistently good results and I was rather relying on it for a suite of poorly iMacs on Monday!!
Apple's NDA on this issue is BS. There's a HUGE problem, its well documented, it's known by engineering, they even have a fix for it, and yet they're pulling this NDA crap. Just release the damn fix already.
