Yosemite Macbooks stuck at 50% boot (Progress Bar)

I will add that we have been provided a test fix today from the apple rep thats working on our case. Initially after running it on an example machine that could reliably reproduce the boot hang, it looked to eliminate the issue and even make the machine boot up a bit quicker. We have now deployed the test fix to our 30 macbook test cart of 10.10 machines as well a few one off 10.10 machines we have in a library. I need to update apple on the results of the test fix as the day progresses.... Out of 4 "fixes" or workaround they had me try, this is the first that appears to be successful...

@spowell01 - Can you provide your support case number? Our engineer has still not responded and I'd love to provide him this info to see if we can get the fix as well, since and official Apple fix would be supported.

@bmwarren

Sure, our current case number is 485446. I'm not sure if apple considers this a "fix" but more of a test. If this works as we seem to be seeing, then maybe they will implement this before 10.10.2?

@spowell01 Wonderful, thanks!

I received the pre-release fix today as well. It worked on the two machines I tried it on and do agree that the machines appear to boot faster. I will install it on my primary machine to see if anything else breaks.

I don't suppose it's a set of commands we can try? I requested the fix as well in the meantime, in case it's a pkg.

We have implemented Chris' suggestion with 100% success.

I created the rc.server file in /etc and captured it with composer.

I then created it as a .pkg and deployed to our test machines, then finally our production machines.

This has been a great thread. Looking forward to movement on an official fix from Apple.

Great work everyone.

Cheers,
Gavin

Any idea if that command can be ADDED to rc.server on a 10.10 server? I've got two mini servers running yosemite that have this issue.

Hi guys, I'm having the exact same problem, I've been with OS X Yosemite for a while now, (since Christmas) and only a couple of days ago this problem occurred. I've had my MacBook Pro for almost three years now, with no problems at all. Went to Apple today and asked them about this issue and apparently my hard drive is busted and it needs to be replaced? This doesn't sound right, as you guys are having this exact problem. I'm not expert on this stuff, and would greatly appreciate if someone could take me through step by step on how to fix this problem. I read above that chris.hotte found a potential solution to this, but had no idea where to even start. I've been without a computer for three days now, getting quite annoying.
Thanks for you time,
Sam.

I heard from an Apple rep today that apparently the fix that is being circulated is included in the latest 10.10.2 beta.

Let me just say that I am not optimistic that it's in the latest beta released today. If you have access to the latest beta, check the date/strings on /usr/libexec/opendirectoryd.

Knowing Apple's typical development cycle for Yosemite updates, this patch is pretty late in that cycle for integration with 10.10.2.

Perhaps it will be released as a standalone update that will be integrated with 10.10.3.

just updated an MBA to 10.10.2 (latest beta), forced power off and it's hung

hi guys,

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

1. Log in as single-user
2. Entered the lines 'mount -uw /' and '/usr/bin/nano /etc/rc.server' (hit enter)
3. Put the below into the nano editor and save it:

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

1. Reboot.

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

We have not seen this issue and we've now rolled out to over 400 macs and counting.

Coincidence?

Cheers,
Gav

I wanted to report that installing the rc.server hack via the JSS on a 10.9.5 client (AD bound, FV2 encrypted) and then upgrading the machine to 10.10.1 (via Self Service) produced a 10.10.1 client with the rc.server file intact in /etc post-upgrade.

Ideally we will want to deploy the rc.server file to 10.9.5 clients prior to their upgrade to 10.10.1. Based on my testing it looks like this will work. Anyone else care to confirm on their end?

I can confirm, that on OS 10.10.2 / 14C106a, this issue no longer occurs. Updating from 14B25 base / clean OS X.

Forced powered down this Mac like 7 times, boots up no hangs at all.

John

Well that is certainty good news!

@johnklimeck][/url Can you confirm that you are testing with an AD bound account w/UNC path checked during account creation and an encrypted computer?

sure,

- Definitely bound to AD (via JSS Directory Binding)
- UNC path is Disabled (we do not use this derived UNC path, causes issues (question mark in dock)
- No File Vault

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.

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

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

cool, going to test this now

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.

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.