Yosemite Macbooks stuck at 50% boot (Progress Bar)

[ctopacio01]

Hi,

After OS Yosemite was installed in some of our MacBooks, we had some boot at 50% and it stays stuck there. The first time I saw the issue, I power cycled the MacBook and I let it sit for an hour. It was still stuck at 50%. I power cycled the machine again and left it on for the whole night (5:00pm-8:00am). As I got back to the MacBook, it was still stuck at 50%.

I did some Google searching and I read this thread here: https://discussions.apple.com/thread/6603394 and tried booting to the recovery partition (Command + R). I booted to the recovery partition, turned off Wi-Fi, then restarted the machine using the menu bar.

After doing this method, the machine successfully rebooted and finally reached the login screen. I have done the same methods for another MacBook along with one MacBook Pro and they all managed to reach the login screen after booting into the recovery partition, turning off Wi-Fi, then restarting the machine.

I don't know if this is the "right" solution for this issue, but other ways to solve this issue would be greatly appreciated as we are planning to upgrade more and more MacBooks (and Pros) to OS Yosemite.

Thank You!

[davidacland]

Thats good to hear. In most cases where we've seen this problem we've used the same configuration as @johnklimeck so its looking promising.

[johnklimeck]

Question: May have been brought up here already. Can one at Casper Imaging, simply include this rc.server file (containing the appropriate bash script), and this also work.

In other words, a sort of pre-emptive move in the interest of ensuring new Yosemite images going out will be fine, and awaiting the 10.10.2

[dgreening]

I don't see why not. I would check off the "Install on boot drive after imaging" check box in the Info - Options section for the package in Casper Admin. I'll be testing this after I do some testing on the latest beta....

[johnklimeck]

cool, going to test this now

[dgreening]

Still seeing the boot hang about 50% of the time (on a hard power down) on a 10.10.2 (14C106A) client ... AD, FV2 encrypted, mobile account no UNC path... rc.server hack still produces 100% boots on hard power down.

[johnklimeck]

Interestingly enough, just to add to this:

In my lab I can only replicate this on a 2012 iMac. Can not replicate this on a recent MBP 15" or a Mac Pro (new).

Although this is occurring in the field, across all types and years of Mac hardware.

I can consistently reproduce this issue on the 2012 iMac, so I will update that to the new 10.10.2 update and see what happens.

[dgreening]

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.

[johnklimeck]

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

[johnklimeck]

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.

[RobertHammen]

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 ;-)

[NightFlight]

@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.

[NightFlight]

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. ;-)

[qhdevon43]

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

[kirkmshaffer]

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)

[nathanzamprogno]

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?

[nathanzamprogno]

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.

[yashy99]

Guys it all worked. Apologies for that.

Chris.Hotte - great script. Thank you

[maser]

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?

[jhbush]

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.

[jperelli]

@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

[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).

[NightFlight]

@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.

[NightFlight]

@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.

[RobertHammen]

@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.

[jwojda]

@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-i...

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

[RobertHammen]

@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...

[Kevin]

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

[aamjohns]

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

[bentoms]

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

[dgreening]

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?

[NightFlight]

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

[dgreening]

Meaning "Most consumers don't use it and thats who we care about these days."

[pchang]

Looks like 10.10.2 just got released!

[maser]

without a new version of opendirectoryd, though...

Highly disappointed.

[NightFlight]

Well, I'm just happy to hear that an opendirectoryd change is in the pipe.

[maser]

Yeah, but another two months (if that) for 10.10.3.

We are *profoundly* disappointed here.

Somebody should badger Tim Cook. ;-)

[RobertHammen]

Again, my supposition is that:

a) once vetted, there will be a patch publicly available (much like the bash fix)
b) it probably won't show up in SUS
c) it'll probably be rolled into the next major OS release

To be fair, this issue and fix came into being very late into the testing cycle for 10.10.2. Apple could have rolled it in and pushed back the release date of 10.10.2, or ship 10.10.2 and make the update available separately. Apparentyl they chose the latter approach...

[dgreening]

SWEET! Something to test! Thanks for posting this!

[chrisw]

This link worked for me

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, 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*

[alexforsyth]

Thanks for the link kbach!!