Yosemite Macbooks stuck at 50% boot (Progress Bar)

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

Looks like 10.10.2 just got released!

without a new version of opendirectoryd, though...

Highly disappointed.

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

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

We are *profoundly* disappointed here.

Somebody should badger Tim Cook. ;-)

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

SWEET! Something to test! Thanks for posting this!

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*

Thanks for the link kbach!!

@kbach, whilst love sharing solution as much as the next admin.. you post is clearly in violation of Apples NDA & I'd advise you edit it.

Highly annoyed, and users don't understand why I won't push out OS X when they are released. I was even told by my engineer that he had seen success on JAMFNation with 10.10.2 beta. I tested, nope. Problem still there. Updated to public release of 10.10.2 and now the issue shows up on my mac. How about those Apples!!!! FACE-PALM INTO BRICK WALL!!!!

Pretty normal. Don't deploy Windows until Microosft releases the first Service Pack, don't deploy OS X until Apple gets to 10.x.3. I hoped Apple would get a 10.10 release without Active Directory related bugs, but I'm not disappointed that they didn't. 10.7 had issues, worked fine in 10.7.3. 10.8 had issues, worked fine in 10.8.3. 10.9 had issues, issues resolved in 10.9.3. Hopefully 10.10.3 will be the release I can roll out.

I have this problem only with computer have HDD disk. On MacBook Pro and iMac with SSD i don't have this problem.

I have seen people have success with a solution/workaround by chris.hotte but I don't understand the solution, how we would package it and deploy it.

Could anyone throw up a step-by-step on how to do this?

1) create or edit the /etc/rc.server file
i.e. sudo vi /etc/rc.server

Insert this line in the file:
/usr/sbin/BootCacheControl jettison

Save the file. Double check the file ownership to be root:wheel, 644 permissions:
ls -al /etc/rc.server
-rw-r--r-- 1 root wheel 462 Apr 11 2013 /etc/rc.server

Open Composer, don't create a new policy.
In the Finder, click Go then select Go to Folder
type /etc into the box and hit OK.
Scroll through the list of files until you find rc.server
Drag it to Composers left sidebar, under SOURCES
You should now have a folder listing that shows /private. Expand it and it should show /etc. Expand it again and it should show only the rc.server file

Save this as a DMG or a PKG file. Upload it to your JSS using Casper Admin, then create a policy to deploy it to your 10.10.x clients. Upon a restart, assuming you edited the file correctly, it should work.

Hope this is helpful.

I got this from an Apple rep. It has worked for us so far for this same issue. We don't use FV or OD, just AD.

mount -uw /
cd /Library/Preferences
mv com.apple.loginwindow.plist com.apple.loginwindow.plist.old
reboot

Edit: Forgot to add do this in Single-User Mode

@lehmanp00, did that work?

@bentoms

Tried it on 3 Macs that wouldn't boot. Stuck at 50% or so... and yes all 3 worked fine afterwards.

@lehmanp00 nice thanks for sharing.

That is actually really helpful - Thanks for your help!

Really, thanks.

@lehmanp00][/url

Does that removal of the loginwindow.plist file fix all subsequent hard-power-down reboots? Have you tried hard-powering down about a dozen times after doing this?

This issue will only show up if an AD-connected machine is hard powered off. It usually does not show on a machine with an SSD (or fusion drive), but will almost always show on a mac with a mechanical hard drive (iMac or older MBP...)

The *real* test for any of the above workaround is -- can you hard power-it off 10-12 times and have it boot up successfully each time?

The rc.server method appears to "solve" the problem, but I can't comment (without getting in trouble) about the opendirectoryd patch success rate being similar to the rc.server method. Really, I can't.

Any other suggestions have always been one-off suggestions that have yet to stand up to multiple hard-shutdowns.

@maser

I rebooted 7x after the fix. All 3 Macs I fixed were Air's bought this summer. After 4 days so far no issues, however, I'm sure the users don't power them off much.

I did not try the rc.server fix.

@RobertHammen-Thank you for posting this! These steps are taken on the user's machine correct? I am new to JAMF/Casper and want to make sure I understand before I start poking around ;)

@lehmanp00

As I thought -- I just tried your suggestion on my MBP -- and booting into safe mode and removing the loginwindow.plist file -- did not even allow it to reboot the first time after deleting that.

That's not a viable option. I think you got randomly lucky because you are doing this on Airs where the faster SSD doesn't usually show this hang problem that often, but deleting the loginwindow.plist makes no difference.

@ maser

Absolutely could be. I honestly was skeptical at 1st because it seemed a little too easy seeing what other had to do in this post. So far I am not seeing this issue on MBPs here (cross fingers). However, I wanted to post the solution just in case it might work for others.