Skip to main content
Jamf Nation, hosted by Jamf, is a dynamic and knowledgeable community of Apple-focused IT admins and Jamf Pro users. Join us in person, in October, for the annual Jamf Nation User Conference (JNUC) to discover new and better ways to manage Apple devices.
CCT Badge

Yosemite Macbooks stuck at 50% boot (Progress Bar)

Posted: 11/14/14 at 12:58 PM by ctopacio01


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: 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!

CCA Badge

Posted: 11/14/14 at 1:09 PM by Kmitses

I had the same problem with workstations with file vault.... looks like it is a know issue and that method is valid.... check out this article....

Posted: 11/14/14 at 1:10 PM by alexjdale

If the systems are bound to Active Directory, they are possibly trying to authenticate the user and getting stuck. Turning off wifi would force them to use cached credentials.

We just put a full stop to Yosemite deployments as a result of a few different Active Directory-related issues.

CCT Badge CMA Badge

Posted: 11/14/14 at 2:05 PM by gburgess

I've seen this issue as well on my own machine. I saw success by rebooting the machine into "Safe Boot" mode and then restarting the machine normally in case you wanted to try saving a few clicks.

CCT Badge

Posted: 11/14/14 at 2:51 PM by ctopacio01

@Kmitses We do not use FileVault on our district machines.

@alexjdale Our machines are bound to Active Directory but we cannot get to the log in screen. Just the apple logo with the progress bar.

@gburgess Will try this out with the next MacBook that has the same issue.

Posted: 11/14/14 at 4:43 PM by jon_mohar

I have had this happen twice on a 10.10 AD bound Mac Mini, no filevault, with Wifi disabled due to wired network. It hasn't done it since having the PRAM reset.

Had a similar issue when restarting a 10.10 FV enabled laptop went to black screen after the Apple boot logo disappeared. The user could see the mouse cursor, but nothing else. Using ARD to remote into the machine, the user's session was active with the "Your computer restarted because of a problem" dialog. Clicked Ok, and user could immediately see their session on their end. I restarted the machine initially via ARD as I was troubleshooting an instance where the machine restarted automatically.

Now I'm in a similar boat with Alexjdale, due to the crashing/autorestart of Yosemite.

Posted: 11/15/14 at 7:39 AM by pbenham

I've seen this 4 times in the last 2 weeks.
Rebooting into safe mode has worked for me.
Next time I see one I'm going to note the time and then go back and comb through the logs to see if anything jumps out \- or maybe reboot into verbose mode and see if that show where the machine is getting hung up.
By any chance are you all using Sophos Anti-Virus on your machines that you are seeing this with? I know our version of Sophos is not yet at 9.2.2 which they recommend for OS X 10.10 ( \- we're still on version 9.1.8. Just a hunch.

Oh and no FileVault on our machines with the issue and a mix of laptop and desktop wi-fi/ethernet.


CCA Badge

Posted: 11/15/14 at 5:07 PM by emily

I've had issues with users upgrading to Yosemite (with and without FV2) and the progress bar screen hanging. SMC and PRAM resets fix the issue for our environment.

CCA Badge

Posted: 11/16/14 at 11:18 AM by mpebley

Had similar issues and I ran into a problem with unsigned kernel extensions that were being used on 'upgraded' machines (not fresh imaged).

Run this in Terminal, will take a few mins.
system_profiler SPExtensionsDataType>~/Desktop/kexts.txt

Open the resulting txt file and locate any line where "Obtained from: Not Signed" Those resulting kext had to be removed. I found 2 old Canon BubbleJet USB drivers that was causing out problem. Once removed the hanging boots disappeared.

CCA Badge

Posted: 11/16/14 at 8:22 PM by jconte

I have had the same issue on MAC mini's without filevault. resetting the pram worked for me. WiFi off, McAfee installed, all clean images-new builds, all bound to AD.

It has been sporadic, about twice out of 15 images. If it continues to happen I will open a ticket with TAM.

CCT Badge

Posted: 11/17/14 at 1:11 PM by ctopacio01

@pbenham][/url No sophos on our machines.

Tried SMC/PRAM resets and did not fix the issue in our environment. I still have yet to try Safe Boot on one machine I am currently working on.

Anyone have the problem reoccur (hours/days) after the Safe Boot fix?

CCT Badge

Posted: 11/17/14 at 1:19 PM by ctopacio01

Something to add as well... On our machines, the background shows white with an apple logo and a progress bar stuck at 50%. Background never turns gray and cursor never shows.

Posted: 11/17/14 at 6:34 PM by cotten

+1 to this issue. We ended up wiping the machines and starting fresh. In each case they were bound to AD and were yosemite upgrades. We use a .local domain for AD which needs needs to be manually specified in the DNS search order. I noticed it was getting stripped in successful upgrades, not sure if its related to this.

CSE Badge

Posted: 11/17/14 at 6:43 PM by bmwarren

This has happened at least once with every machine I've upgraded to Yosemite in our environment. For some, it's happened multiple times.

Booting into single-user mode and running a filesystem check will usually allow the machine to boot properly on the next attempt. Sometimes, booting into safe mode then rebooting normally will allow the OS to load.

Based on other suggestions online, I've verified that each machine is not attempting to load unsigned kernel extensions.

Other notes:

  • Models: 2012 MacBook Pro, 2013 MacBook Pro, 2014 MacBook Pro, 2013 iMac, 2014 iMac
  • Bound to AD, though issue happens both on and off network
  • Waited 20-minutes to 72-hours for boot to complete normally
  • Happens on both FileVault-encrypted and unencrypted machines
  • I haven't yet received any Yosemite machines straight from Apple, so all these problems have occurred on computers upgraded from Mavericks
  • No Sophos here

I've also had to halt all additional upgrades until we can determine if this is a Yosemite bug or some other problem, only a problem when upgrading from Mavericks, or some problem with AD-bound machines.

Any additional variables we can explore?

Posted: 11/18/14 at 8:12 AM by spraguga

What I found so far, this may also apply to non-encrypted machines.

If the "Use UNC path from Active Directory to derive network home location" is checked in Directory Utility when an AD account is created then you cannot login to a Yosemite encrypted machine off network.

Uncheck that box, recreate the AD account, add the account to FV users, and you can login off network fine.

More here:

Posted: 11/27/14 at 12:27 PM by endor-moon

We are putting off our Yosemite deployment plans because of this problem. Sure wish Apple would fix bugs that affect large-scale deployment in a big hurry.

Posted: 12/4/14 at 2:23 PM by paulnz

Seeing this behaviour on 10.10.1 across iMacs and MacBook Pros. Booting into safe mode and then restarting seems to be the fix for now.

CCT Badge CCA Badge CCE Badge

Posted: 12/4/14 at 2:55 PM by chriscollins

I know some have said they tried this and it didn't work but every machine that has had this problem for us, deleting the "OriginalHomeDirectory:" attribute for the AD mobile account with dscl has resolved the issue permanently.

Posted: 12/4/14 at 3:16 PM by jtol

Hi Chris
I have a machine that I upgraded from Mavericks that has this issue. At the moment when I try and search for that attribute it says attribute not found. I am in the Directory editor looking under Viewing: Users in node /Local/Default to see if I can find the attribute to then remove with DSCL

What command did you use to remove the attributes?

Posted: 12/4/14 at 3:18 PM by jwojda

we have non-FV users experiencing this. Though we got around it by doing a cmd+v (verbose boot seemed to work).

CCA Badge

Posted: 12/4/14 at 3:20 PM by emily

I've only had one Machine (in-place upgrade from Mavericks) that was not recoverable with a PRAM reset. Apparently it was just an OS issue because when I finally sucked it up and wiped/reinstalled the OS the machine is working totally fine. Sigh.

CCT Badge CCA Badge CCE Badge

Posted: 12/4/14 at 4:11 PM by chriscollins


Usually I do this over SSH because in our case the issue is with the user's login completing but the OS is up and running even though it looks like its actually frozen because the 50% progress bar is stuck on the screen.

I run ```
dscl . -read /Users/<user> OriginalHomeDirectory
``` to verify if the user has the attribute which again in our case they always do when this issue happens because there were some machines that were manually bound a long time ago by some of the PC techs and they weren't paying attention to the checkboxes in Directory Utility so this attribute would get created.

If the attribute is there, then I run ```
'dscl -u <admin username> . -delete /Users/<user> OriginalHomeDirectory'
``` Then just tell it to reboot.

You can do this through Directory Utility I just do it this way so we don't have to boot into safe mode when I am helping another tech fix the issue.

Posted: 12/16/14 at 8:47 AM by Kaltsas

We have some departments that have purchased new mini's that require 10.10. I am starting to see this issue more frequently.

There appear to be two separate issues that present in a similar fashion.

? An encrypted macintosh that is upgraded to 10.10 may experience a hang during the boot process. Reseting the PRAM/NVRAM resolves this issue.

? A 10.10 or 10.10.1 Macintosh that is AD bound that experiences a forced shutdown or an unexpected power failure will consistently hang on boot.

I can consistently replicate (and resolve) the issue with safeboot or Single User Mode fsck. However the issue keeps reoccurring in the wild. I struggle to believe that all these systems out there are ALL experiencing improper shutdowns but I can only replicate the issue in the office by pulling the plug or a 4 second power button hold. It seems like there is some combination of sleep settings that may also cause the issue but I haven't been able to figure it out if there is. It just seems unlikely that a dozen Macs a day are seeing improper shut downs.

Posted: 12/20/14 at 4:01 AM by bigchief_ch

Same problem here on a Macbook Pro 15' mid-2012. Boot stuck at 50%, impossible to boot in safe mode, checked hdd, reset pram, everything but no luck. It was working again only after reinstalling the system (whithout erasing data).

I did some tests and found that the problem on my Macbook is due to the update called "Canon inkjet printer software update" version 3.1

As soon as this update is installed the Mac refuse to boot.

Note that this Mac is part of an Active Directory domain and the HDD is not encrypted.

Hope it will help somebody.

Posted: 12/30/14 at 11:43 AM by csheridan

I've been following about this same issue. In our environment it's been units logged in to AD accounts (local homes, not roaming) that have lost power (intentionally and unintentionally). Mostly users staying logged in to AD bound machines and the machines going to screen saver with the "Require Password" option set, thus requiring a hard power down of the machine for the next user.

I've taken steps to make sure the "Require Password" option is disabled, and am watching the above apple discussion.

CCA Badge CCE Badge

Posted: 1/8/15 at 7:06 PM by rhysforrester

Chiming in; 10.10.x labs (machines bought with Yosemite on them), bound to AD, no wifi on, accounts deleted at logoff, no UNC path set.

If an AD user is logged in, and a machine is hard powered off it will stick at \~50%. If verbose mode is used it will show that after getting an IP address the freeze is happening immediately prior to en2/en3 entering promiscuous mode.

If the machines are hard powered off when not bound to AD, or are bound and a local user has logged in, then there is no issue.

I've seen a mixed bag of results with single user mode, pram resets etc. Currently I have 3 machines that I locked up last night and none of the suggested fixes have managed to pull them out of their boot lock state.

For our area at least, I think we can safely assume this problem exists around AD and mobile accounts. I am however more than a little curious about the implementation of Samba3 with Yosemite, when Samba2 hit us it caused no end of issues around network drive mounts and network printers.

CCA Badge CCE Badge

Posted: 1/9/15 at 12:53 AM by rhysforrester

Thankfully i'm able to move my labs back to 10.9.5 (late-2013 iMacs), tried all the same lockup methods and no issue.

Unfortunately(?) we'll be staying with Mavericks until such time as the AD issues surrounding Yosemite have been corrected.

CCT Badge CCA Badge CCE Badge CJA Badge CMA Badge Integrator Badge

Posted: 1/9/15 at 3:11 AM by daz_wallace

One possibility to add weight to the built in plugin being the issue. We are not having this issue at all when using the Centrify Express free AD plugin.

Hope that might help some of you guys out if you need 10.10

Posted: 1/9/15 at 6:07 AM by benshawuk

Just to chime in here as I've been extensively testing this in our environment, in case it helps anyone:

We run a .local domain (legacy reasons) and use the Apple AD plugin for binding (with mobile accounts).
In this scenario, an unclean shutdown causes the boot issue every single time without fail.
The single user mode "rm -rf /Library/Preferences/OpenDirectory/" fix resolves the problem every time.

As soon as the machines are unbound from AD (and the settings/prefs trashed etc.) I cannot reproduce the problem on forcing an unclean shutdown.
I'm also now having success with the Centrify Express plugin (cannot reproduce the issue following an unclean shutdown).

(I should have learnt my lesson really: this must be about the 6th OS X release that has introduced problems with .local AD domains and the Apple AD plugin. I naively thought that from 10.6 onwards .local AD plugin problems were ironed out!)

CCT Badge CCA Badge CCE Badge CJA Badge CMA Badge Integrator Badge

Posted: 1/9/15 at 8:08 AM by daz_wallace

One other thing I have yet to try, as suggested as a possible cause by @bentoms (thread is disabling core storage and see if this affects the replication of the issue.

This can be done without reimaging the mac using 'diskutil cs revert [Core Storage UUID]'.


Posted: 1/9/15 at 8:37 AM by Kaltsas

I have an open ticket with Applecare Enterprise Support. It is a known issue that has been reported to the product development team with no ETA for a fix. The procedure that has worked every time for us and has been the recommended procedure for temporary resolution is as follows in Single User Mode.

/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm /private/var/db/BootCache.playlist

Honestly, I don't expect a fix until 10.11. Maybe Apple will surprise me but the lack of movement on our open case doesn't fill me with cupcakes and kittens.

CCT Badge CCA Badge CCE Badge CJA Badge CMA Badge Integrator Badge

Posted: 1/9/15 at 8:39 AM by daz_wallace

Thanks for the info @Kaltsas

I'm guessing by the use of 'temporary resolution' in your post, a killing of the power brings the fault right back?


Posted: 1/9/15 at 8:47 AM by Kaltsas

That is correct you can easily recreate the problem. The first boot after the reboot command in SU takes a while but they consistently boot.

The Support Engineer I spoke with indicated they believed something in BootCache.playlist is getting corrupt in this scenario on a directory bound macintosh but was unable to provide further details. We gave them an estimated count of potentially affected machines, which I believe gets sent to the product team to help them prioritize internally. This is why I don't believe we will see a fix anytime soon. There are other bugs that affect way more systems *cough wifi*.

I think I have some users that are 4 second smothering their mac at the first sign of trouble and giving themselves grief. We also have several conference rooms that we just unbound because the issue kept reoccurring, I think there is some sort of power issue in those rooms but I couldn't sus out what it could be. The only repeatable trigger is force it off/pull the plug.

CSE Badge

Posted: 1/9/15 at 8:52 AM by bmwarren

@Kaltsas Would you be willing to share the enterprise case number with me? I do not have enterprise support, but my regional engineer (who claims this problem doesn't exist and is unreported) wanted to reference a case number so he could "add impact" to the case priority. I can't speak for him, but he may be able to add impact or at least a comment of "I have a customer with another 50 machines affected by this" if you can provide the case number. Thanks!

Posted: 1/9/15 at 8:55 AM by chrisw

Just my 2 cents...we had the same issue. A couple with in place upgrades from Maverick and even a brand new Macbook purchased with 10.10. Resetting Pram (as recommended by the Apple Genius) worked but not consistently. I ended up reseating my member and that seemed to resolve the issue for now.

Posted: 1/9/15 at 9:49 AM by jasonh

Since it's only a corrupt cache causing the problem, would disabling this kext prevent the creation of the cache and prevent the problem from recurring?


Not in a position to test this right now but curious if anyone has any luck with it.

CCA Badge

Posted: 1/9/15 at 11:00 AM by mpebley

I have had luck with the upcoming 10.10.2 builds fixing this issue for us. Hopefully it will be released soonish.

Posted: 1/9/15 at 11:11 AM by Kaltsas

@bmwarren][/url][/url I'm not at my desk but I will get you our case number as soon as I can.


Case number should be 490421.

We actually purchased an enterprise contract because of this issue. I had been pressuring my boss for a support contract for a while but having an actual game breaking issue that needed resolved greased the wheels as they say.

Posted: 1/9/15 at 11:12 AM by csheridan

@Kaltsas \- Awesome! Thank you. My most consistent fix so far has been single user removal of caches, but I wasn't even thinking of bootcache.playlist. Here's to hoping for a fix soon!

CCA Badge CMA Badge

Posted: 1/9/15 at 12:21 PM by spowell01

We also purchased an enterprise contract with apple for this specific issue. Our case \# is 485446, and their last suggestion was,

Thanks for the update. We do have another workaround available that I would like for you to try. However, please be advised that the argument is the time to wait for the Directory Server to bind before continuing login. The default is 60 seconds. So if you entered 10, the delay would be at most 10 seconds. You may run into problems where you don't get password expiration because you aren't allowing enough time for the system to connect to the AD server before continuing the log in.

1) Launch Terminal

2) Execute the following command:

sudo defaults write /Library/Preferences/ DSBindTimeout -int <seconds>

That had no change in the 50% boot issue we are seeing, so i then tried to unload the boot cache.kext as well as totally remove the kext file and reboot. Still able to get stuck at 50% if i force the machine off.

CCT Badge CCA Badge CCE Badge CJA Badge Integrator Badge

Posted: 1/9/15 at 12:56 PM by davidacland

@mpebley we've seen it with the following configuration:

  • 10.10.1
  • FileVault switched off
  • CoreStorage enabled
  • Joined to AD

Is that the same as your 10.10.2 setup?

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/9/15 at 1:08 PM by bentoms

@davidacland, we can't recreate it. Difference is we're reverting to the standard volume format & partition.

@chrisw, you do what?

CCT Badge CCA Badge CCE Badge CJA Badge Integrator Badge

Posted: 1/9/15 at 1:17 PM by davidacland

Certainly sounds like the core storage option might be a culprit (not much help for FV2 users). I'm wondering whether 10.10.2 is going to resolve the problem. The note from @mpebley would indicate that it might.

I'm assuming a typo from @chrisw. Made me chuckle though!

Posted: 1/9/15 at 1:34 PM by jwojda

what about if you do a cmd+option+shift+esc?

Posted: 1/9/15 at 2:33 PM by chrisw

Oopppsss...I meant "memory". I am used to texting and it fixing my mistakes...

Thanks for all the posts regarding this topic. I didn't really know where to turn if the Apple Genius's don't even know.

Posted: 1/9/15 at 5:22 PM by jasonh


That had no change in the 50% boot issue we are seeing, so i then tried to unload the boot cache.kext as well as totally remove the kext file and reboot. Still able to get stuck at 50% if i force the machine off.

Does that mean you got it to behave by unloading then deleting BootCache.kext, but the stall would come back after a hard shutdown?

CCA Badge CMA Badge

Posted: 1/9/15 at 5:44 PM by spowell01

We have not had any luck getting the machine to behave. I ran the command to unload the KEXT file and then immediately deleted the KEXT file itself. As soon as i deleted the file, the screen on the macbook flickered briefly and then went to a black screen with only the current users login image(an eagle) displayed. I had to hard power the machine off at that point, and it got stuck at 50%. After multiple reboot attempts it finally made it to the OS, and i was able to reproduce the 50% hang by just forcing the power off again. I relayed this information to our apple rep and he informed me that they are fully aware of this issue, and on a weekly basis are pushing the issue with engineers in cupertino....I'm really hoping they can get a fix implemented before the public release of 10.10.2, but unfortunately I'm not expecting much.

It puts us in a tough situation, since we have moved away from overhead projectors to flat screen TV's in classrooms in conjunction with Apple TV's. The airplay connectivity improvements in Yosemite are what we really need to make our new solution work, but with the lingering boot issue there is no way we can upgrade our teachers yet. Currently they are sticking with Mavericks and utilizing splashtop with their ipads & macbooks since the ipads are able to maintain a better connetion than the macbooks.

Posted: 1/9/15 at 6:36 PM by Joyia

I too am stuck at 50% of the boot loading bar. After installation of Yosemity, my 2009 MacBook Pro got stuck at 50% on the progress bar during the subsequent first automatic reboot. I haven't been able to make it to the login screen once since the 'upgrade'.

I have tried all the suggested fixes, incl. SMC & NVRAM & PRAM reset, booting into recovery mode, turning off Wifi, repairing permissions, checking & "repairing" the disk (although no errors were found), yet \- upon rebooting via "restart" from the menue, (as well as warm start), still the same issue: stuck at 50%. I am uable to enter safe mode, since it also only leads to progress bar reappearing and getting stuck...

I eventually reinstalled OS X via disk utility from recovery mode, wich went through fine, but upon restart \- same issue: stuck at 50%.

The only way I have been able to access the system since the 'update' has been via recovery mode (command \+ R).

\- My MacBook is not part of a network, \- so no likelihood for AD issues.
\- The screen that gets stuck is not black with white apple but the light grey (pre-login) one with black apple and progress bar.
\- I didn't have Mc Afee or any other AV prog. installed.
\- There was no Homebrew or any of the other notorious culprits for endless installation lags installed.

I have an idea for possible reasons but am not command line savvy enough to resolve them from recovery mode:
\- I have had a canon inkjet printer installed, the extensions for which had been mentioned as one reason for continuous stalls upon boot up.

\- My 1TB hdd was partitioned into two partitions, which made it necessary to install Yosemity without FV.

\- I did have quite a bit of content manually placed outside "users".

Any thoughts on it or suggestions how to deal with it from recovery mode \- aside from a complete wipe and clean install \- are greatly appreciated!!

Posted: 1/9/15 at 6:54 PM by Joyia

Reinstalled OS X another two times from recovery mode, which seemed to go through fine, shut off Wifi before final restart, \- same result boot hanging at 50%.

I am out of ideas. ...and in a bad pinch: not been able to use my computer since three days! ..with only an iPod left to communicate.

Any hint of an idea is greatly welcome!

CCT Badge CCA Badge CJA Badge Integrator Badge

Posted: 1/12/15 at 5:21 AM by james_ridsdale

@Kaltsas Your workflow worked for me...

/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm /private/var/db/BootCache.playlist

Thanks \- I'll look to add this to our environments.

CCA Badge

Posted: 1/12/15 at 4:00 PM by emily

Wow, that workflow from @Kaltsas totally worked for me too. On a machine that was the biggest thorn in my side for over a week (it was fine until FV2 was enabled, then it refused to boot).

external image link

Posted: 1/13/15 at 7:22 AM by Kaltsas

@emilykausalik The Applecare Support Engineer I have been working with indicated the issue appears to be more prevalent with FV2 encrypted Macs but I have had no issues replicating the issue on Non-FV2 encrypted systems. Most of our reports in the wild have been from unencrypted desktops (most of our laptops are encrypted). I suspect this is because desktops are more likely to experience a power failure than laptops.

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/13/15 at 7:47 AM by bentoms

Hi All,

Just an idea, but when writing AutoCasperNBI myself & @neil.martin83 kept seeing a hang on restart until i deleted the below:


If you have Macs that you can test & recreate this on, can someone try deleting that file & then breaking the Mac again.

This is just a theory, so please don't do it in prod!

CCA Badge

Posted: 1/13/15 at 10:31 AM by emily

Okay, so it worked once on one computer but now that one isn't working again. And another user is having the same issue and that fix didn't help. I tried @bentoms suggestion but didn't notice any change. I can boot into Safe Mode but can't get the OS to load otherwise. Super frustrating.

Posted: 1/13/15 at 10:41 AM by Kaltsas

With the steps I outlined after hitting reboot in SU the initial boot will take 3-5 minutes in my experience but it will boot. Tech Ops also reported one system to me that the outlined procedure would not resolve the issue yesterday. However they formatted the system before I was back in the office today, I would have liked to have access to the "broken" system to work with our support contact on it but it is what it is. I have not been able to replicate, following the procedure to delete in SU mode works every time on my test systems.

CCA Badge

Posted: 1/13/15 at 10:45 AM by emily

Interestingly I just tried the "turn off Wifi in Recovery Mode" and that did work, so I'm starting to wonder if there's some kind of issue with FV2-enabled Yosemite Macs talking to the directory service while loading the OS/mobile profile. Since it bypasses (well, more hands-off than bypasses) the regular login screen I'm wondering if the sequence of events to check with the directory and load the mobile profile is busted somehow.

Posted: 1/13/15 at 10:49 AM by spraguga

@emilykausalik][/url Yes, this has already been confirmed further up this thread, see my post.

And this thread:

Posted: 1/13/15 at 2:45 PM by NightFlight

I'm not alone!!!

Sporadically over our 1500+ systems on 10.10.1 loosing power at one site or the other would result in \~%25 machines not able to boot \- stuck at %50. Annoying \- for me. Costly for our business. Yikes!

I've isolated down to the Apple AD plug-in being enabled. Solid troubleshooting over the last couple days \- using 3 iMacs on a power bar and hundreds of reboots later and many many many clean installs later, I know the following.

Clean install of 10.10.1 with nothing else.
Enable active directory and bind it.
Boots to %50 and hangs following a forced power failure.

CCA Badge CMA Badge

Posted: 1/13/15 at 3:08 PM by dgreening

Has there been any response from Apple on this? Does anyone have access to the betas of 10.10.2 to see if this is still an issue? I am aware that NDA prevents discussion of specifics, I am just wondering if anyone is testing this. We have not seen a single occurrence in our testing (AD 2008). Granted we have mostly portables...

CCA Badge

Posted: 1/13/15 at 4:59 PM by mkremic

Same thing happening in our environment with \~600 Macs joined to Active Directory. Can reproduce the 50% hang with a forced power off consistently.

99% of our Apple devices are laptops with AD auth and FV2 enabled. We've recently gone through a domain migration and of the few machines left over to migrate we haven't seen this issue with the Macs that aren't using the AD plugin to talk to the domain.

Tested following fixes to no avail:
\- Changing AD authentication timeout values to low numbers (even 0) \- as in this terminal line: sudo defaults write /Library/Preferences/ DSBindTimeout -int <seconds>
\- Unckecking the "Use UNC path from Active Directory to derive network home location"
\- Installing 10.10.2 beta release on a Mid 2012 MBP made no noticeable difference unfortunately. A hard power off resulted in the same stuck loading bar.

Kudos to @Kaltsas, I tested your workaround to get a mac up and running again by booting into single user mode and it booted perfectly! Took a good couple of minutes but it came right. Good to have a consistent workaround until Apple get this sorted!

I'll keep searching the interwebs like we all are for possible workarounds. Hopefully something will come soon!

Hang in there people... we're all feeling the pain!

CCT Badge CCA Badge

Posted: 1/14/15 at 2:57 AM by andysemak

Just wanted to add my thanks for @Kaltsas workaround.

I raised a bug report with Apple with both the startup hang and the hang after login on a FV2 Mac

The bug for the startup hang was closed as a duplicate around a week ago but so far nothing for the FV2 bug.

Posted: 1/14/15 at 8:38 AM by NightFlight

Can the boot scripts be edited to include clearing the boot cache playlist? It would slow the boot process down I suppose, but it would possibly kludge this as a fix.

Posted: 1/14/15 at 11:59 AM by NightFlight

I've tried all of the above suggestions which did not provide a consistent fix. But this does.

On the client only, you may hijack the unused /etc/rc.server bash hook, eg single user boot:

bash-3.2# mount -uw /
bash-3.2# /usr/bin/nano /etc/rc.server

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

Boots are now completing %100 of the time.

Edit: We are now beta testing this workaround on \~50 machines.


CCA Badge

Posted: 1/14/15 at 5:43 PM by mkremic

@chris.hotte we're trialling your fix on a few machines and it's looking very positive. We've had 3 so far that were refusing to boot and after going into single user mode and editing rc.server they've booted first go. I've got one test MacBook Pro by my side and can now consistently hard power it off and boot back up without it getting stuck at 50%!

Great work! Will continue to trial and post results.

Posted: 1/14/15 at 8:38 PM by timotei

@Kaltsas booting into single user mode and using fsck fixed it for me. Is there anything in particular that leads you to believe it is an issue with being bound to AD after forced shutdown?

CCA Badge CCE Badge CMA Badge

Posted: 1/14/15 at 9:38 PM by dlondon


So I guess the question to Chris Hotte and mkremic is whether you ran fsck when you were in single user mode to do the rc.server hack. If so can you see if it was simply the fsck that fixed the issue as it was for Tim?



CCA Badge

Posted: 1/14/15 at 11:29 PM by mkremic

@dlondon, nope there was no need to run fsck to do the rc.server hack.

One of our users had told us he had hard powered off before seeing the loading bar issue initially as well which is what we had suspected. The handful of Macs we've tested on today have booted first go after applying this hack.


CCA Badge

Posted: 1/14/15 at 11:42 PM by mkremic

Also I can safely delete the rc.server file when logged in the OS, and if I hard power off the Mac again it freezes at 50%. Just FYI in case anyone else is keen on testing this in their environments.

Posted: 1/15/15 at 4:43 AM by benshawuk

Wow, top marks to Chris Hotte: I can confirm that fix is working perfectly in my environment.
I'm going to be deploying this to 50+ macs also over the next few days.

CCA Badge

Posted: 1/15/15 at 6:58 AM by EliasG

@chris.hotte so what would the script be to get this fixed? I am running into issues at our place. Also would this be a login script?


Posted: 1/15/15 at 8:36 AM by jwojda

I'm trying to write up a doc for our support guys around the country in case they run into this, but it still seems there's a fairly large discrepancy as to the actual cause \- some say it's AD, some say FV2, I thought I saw somewhere that it has to do with the machine's having power failure, others mention Sophos...

I've seen a handful of these, but we don't use FV2 or Sophos, a power failure is possible but on laptops unlikely. We do use AD, but i've got a about 150 10.10.x machines on AD and I've only seen this 3 or 4 times.

Can someone summarize the issue and workaround?

Posted: 1/15/15 at 8:44 AM by rtrouton

The best summary I've seen so far was posted yesterday by @Banks at

Posted: 1/15/15 at 8:59 AM by Kaltsas

@dlondon Consistently in house I can replicate with the tried and true rtrouton method

Setup 10.10
Bind to AD
Login and pull power
Boot and it's hung.

No Casper agent, AV, no extras. It's an OS issue, confirmed and replicated by Applecare Enterprise Support. Sometimes rebooting a few times, zapping PRAM, fsck, and other diagnostic processes will cajole a system back to life. But that resolution is inconsistent.

Consistently the following procedure will fix an affected machine. This has also been confirmed and replicated by Applecare

/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm /private/var/db/BootCache.playlist

I have had one report from tech ops that this procedure did not work on a system but they formatted it before I was able to look at it. I suspect one of the techs did not follow the procedure exactly and it was not mounted as read/write.

I am going to be testing the @chris.hotte process and inform our Apple support contact of the effort.

Posted: 1/15/15 at 9:02 AM by NightFlight

Hi, So I guess the question to Chris Hotte and mkremic is whether you ran fsck when you were in single user mode to do the rc.server hack. If so can you see if it was simply the fsck that fixed the issue as it was for Tim? Regards, David

I'm not running fsck during my tests. It will run on its own when the disk is marked dirty, or rather \- not clean. Given that its run automatically after a forced power down when the file system is not clean \- we can safely rule out fsck as a fix. You can confirm fsck runs when the file system is dirty with verbose boot.

Posted: 1/15/15 at 9:16 AM by NightFlight

@chris.hotte so what would the script be to get this fixed? I am running into issues at our place. Also would this be a login script? Thanks

Are you asking how to distribute a copy of /etc/rc.server?

We don't yet have casper licenses for our workstations, so we don't use it to roll out fixes. Currently I use a daemonized rsync server configured with anonymous modules. See the rsyncd.conf man page. This distribution tool has worked for us for years without hiccup. So treating the rsync deamon as a repository we just sync whats needed for example on a login hook script as you suggested.

Ultimately, it doesn't matter how you distribute this command into /etc/rc.server. So long as you don't overwrite the file on 10.10 server. ;-) Note that you don't even have to mark it executable since its called by bash. I only noticed it yesterday because bash was throwing an error in verbose mode. Same goes for BootCacheControl. I guess that's what happens when you stare at an issue for a few days in a row.

Posted: 1/15/15 at 9:52 AM by joaquim

Adding my two cents and what worked for me:

Even after following all the suggested fixes above, the issue still persisted for me. I looked at the syslog once again but this time noticed a whole bunch of errors stating that it could not create var/folders. So I took the advice posted on an older Apple Support forum and created /var/folders manually. After reboot, system launched successfully!

Under single-user mode:

mount /sbin/mount -uw /
cd /Volumes/Macintosh\ HD/
mkdir var/folders
mkdir var/folders/zz

Link to forum post:

Posted: 1/15/15 at 10:55 AM by NightFlight

Sounds like a separate issue. I'm not encountering that. Maybe check your base image?

CCT Badge

Posted: 1/15/15 at 1:02 PM by tnielsen

Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.

Posted: 1/15/15 at 1:06 PM by spraguga

@tnielsen +1

Posted: 1/15/15 at 1:19 PM by cscsit

@chris.hotte I guess I'm not following your solution. Are you saying to boot to single user mode and perform the commands written in your original response? If I have a Mac thats already not booting I can't push commands to it, even with a login script because its not getting that far.

I'm confident it will work, I just need to better understand how to implement it.


CCT Badge CCA Badge CCE Badge

Posted: 1/15/15 at 1:35 PM by chriscollins

Hey @mklos look at @chris.hotte's post again above the code block. He boots into single user mode then uses nano to create a rc.server file at /etc/ and then puts the script in that code block in and saves it.

Posted: 1/15/15 at 2:30 PM by NightFlight

Hey @mklos look at @chris.hotte's post again above the code block. He boots into single user mode then uses nano to create a rc.server file at /etc/ and then puts the script in that code block in and saves it.

That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun \- but something in there helps to identify the code is executing during a verbose boot.

You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point.

Not much else for it.

Posted: 1/15/15 at 2:30 PM by cscsit

@chriscollins Okay I guess I did do it right but sometimes it boots and other times it doesn't. This only seems to be an issue if someone just holds the power button down instead of shutting it down naturally. I'll keep monitoring it. Hopefully 10.10.2 fixes the issue.

Posted: 1/15/15 at 2:34 PM by NightFlight


Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.

Business requirements...

That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever! But to be fair most releases get pretty good around X.X.8. Then its time for the next one. *sigh*

Posted: 1/15/15 at 2:40 PM by cscsit


That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun \- but something in there helps to identify the code is executing during a verbose boot. You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point. Not much else for it.

Okay I'll just keep an eye on I said hopefully Apple fixes this issue in 10.10.2. It sounds like their well aware of the issue from reading around support forums.

That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever!

If I remember correctly, wasn't 10.6 mostly an under the hood OS update? Not many new improvements/features but just code cleanups, fixing issues with the OS, etc. Basically setting the OS up for future updates and squashing all the little bugs that annoy us users. Maybe Apple needs to do this again. They could stand doing the same thing with iOS but thats a different topic for a different time.

CCA Badge

Posted: 1/15/15 at 3:28 PM by emily

Used @chris.hotte's suggestion and it totally fixed a Mac I thought was a goner.

external image link

CCT Badge

Posted: 1/16/15 at 9:48 AM by tnielsen

I understand @chris.hotte. We do a thin image on hardware that only works with Yosemite... there will be no upgrading to it in any way, however.

For the record, I really like 10.9.5. 10.7.5 was my previous favorite. The almighty 10.6.8 as well, for SMB connections only.

CCA Badge

Posted: 1/16/15 at 12:39 PM by roiegat

We just had a good success with @chris.hotte suggestion.

So would adding that rc.server script to all yosemite machines in /etc resolve the issue? Thinking about how to apply this widespread to prevent further issues.

Posted: 1/16/15 at 12:46 PM by WatchtowerCasper

Safe Mode, Resetting PRAM, or fixing Disk Permissions does not fix the issue.

chris.hotte 's fix works great \- /usr/sbin/BootCacheControl jettison

Posted: 1/16/15 at 6:32 PM by jperelli

@chris.hotte Could you tell me the exact steps you took. ie how to get into single user mode and what are the exact commands you ran in the terminal.

Sorry I am not very familair with osx and all of our AD bound macs have this issue.

CCA Badge CCE Badge

Posted: 1/17/15 at 11:44 PM by frank

@chris.hotte thanks for posting about /usr/sbin/BootCacheControl jettison command.

Can this be setup to run as a logout hook? As that would be ideal as it could be turned off in future from the JSS as a policy if 10.10.2 fixes these startup issues with our Yosemite users.

Unless this is a permanent command that has another command to turn it off?

CCT Badge CCA Badge CCE Badge

Posted: 1/18/15 at 9:57 AM by chriscollins

@frank I think the issue with that idea is that this happens because of a sudden power loss or a user purposefully doing a hard shut down which corrupts the cache. The chances of a user logging out THEN hard powering down or losing power is minuscule.

CCA Badge CCE Badge

Posted: 1/18/15 at 4:03 PM by frank

@chriscollins good point, so setting up a policy to run this command once a day at startup, login and check-in should cover any sudden loss of power from the client.

This way it's easy to remove this command from clients once (and hopefully) 10.10.2 addresses this bug.

What does everyone think?

CCA Badge

Posted: 1/18/15 at 4:25 PM by mkremic

@frank if you're using the rc.server workaround with the BootCacheControl jettison command then there's no need to anything else for now. Regardless of whether the Mac is cleanly powered down or hard powered off that command will be called every time the laptop boots! That's why it's a good workaround/fix until Apple get their stuff sorted.

Once Apple come out with a correct fix for this issue you should be able to safely remove the /etc/rc.server file from your client Macs (not Mac OS X Server) without any harm and they will revert to their standard boot process. In our environment i've used Composer to take a copy of the rc.server file (created with nano) and package it in the correct location. We've pushed it out to our Macs as a "once per computer" deployment \- Make sure you do your testing first of course though!

Once Apple do their fix we'll likely remove it with a simple script similar to:

rm -f /etc/rc.server

Hope that helps!


Posted: 1/19/15 at 9:48 AM by NightFlight


What @mkremic][/url said.

In regards to the testing. Be thorough! If you were to mass deploy and somehow manage to trigger a freeze during boot in the /etc/rc.server script (I don't know how... but if you did) it will lock boot on every machine with no hook for recovery. Meaning you would have to manually touch every machine and boot into single user mode to undo.

I call that sort of error a bad day.

Posted: 1/19/15 at 10:46 AM by pdpk

i used @chris.hotte][/url 's method, tested it many times and it worked well.

thanks for your workaround mate!

We'Re using Deploystudio/munki in our company, so i created the rc.server file on my local mac and created a dmg file with the command munkiitem from munkitools.

i mass-deployed the dmg with munki on every mac here.

worked without problems and the problem seems solved.

if apple do their fix i will just deploy a script like @mkremic][/url said.


CCA Badge

Posted: 1/19/15 at 3:43 PM by joecurrin

Our configuration is 10.10.1 AutoDMG package
FV2 Enabled
AD Bound

We are seeing the issue and resetting PRAM/logging into single-user mode fixed it for us.

CCA Badge CCE Badge

Posted: 1/19/15 at 11:55 PM by rhysforrester

A colleague and I have spent this afternoon in my labs recreating the issue (bound to AD, 10.10.x, hard power off) and have had 100% success on over 40 cumulative hard power offs using @chris.hotte 's suggestion.

This has definitely saved our bacon in the staff environment, the labs however i'm lucky enough to have hardware that will still take 10.9.5 so i'm going that route for the time being.

One thing however, I had 0% success when using single user mode and running the command manually \- it would only work when inserted into an /etc/rc.server file \- which I find a bit odd. Cheers again.

Posted: 1/20/15 at 11:41 AM by NightFlight

Great to hear.

As for the single user boot reason... I'm not certain \- could be a timing/sequence of events issue.

CCA Badge

Posted: 1/20/15 at 1:15 PM by jhalvorson

If you have access to AppleCare OS support or a TAM, be sure to open a case with them.

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/20/15 at 2:26 PM by bentoms

I've seen reports of a supplied fix from Apple to some customers.

No idea if it'll be in 10.10.2 yet, & neither do I have the "fix" myself.

Just wanted to say, it appears to be coming.

CCA Badge CMA Badge

Posted: 1/20/15 at 2:44 PM by spowell01

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

CSE Badge

Posted: 1/20/15 at 3:24 PM by bmwarren

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

CCA Badge CMA Badge

Posted: 1/20/15 at 3:28 PM by spowell01


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?

CSE Badge

Posted: 1/20/15 at 3:41 PM by bmwarren

@spowell01 Wonderful, thanks!

CCA Badge

Posted: 1/20/15 at 4:54 PM by jconte

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.

Posted: 1/20/15 at 5:01 PM by jasonh

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.

Posted: 1/21/15 at 1:58 AM by Kennedy

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.


Posted: 1/21/15 at 2:29 AM by acdesigntech

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.

Posted: 1/21/15 at 1:08 PM by SamBoWick

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,

CCT Badge CCA Badge CCE Badge

Posted: 1/21/15 at 4:04 PM by chriscollins

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

CCA Badge CCE Badge CJA Badge

Posted: 1/21/15 at 10:58 PM by RobertHammen

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.

CCT Badge CCA Badge

Posted: 1/22/15 at 5:06 AM by andysemak

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

Posted: 1/22/15 at 6:08 AM by yashy99

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/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?


Posted: 1/22/15 at 6:52 AM by Kennedy

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



CCA Badge CMA Badge

Posted: 1/22/15 at 9:52 AM by dgreening

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?

CCA Badge

Posted: 1/22/15 at 10:19 AM by johnklimeck

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.


CCA Badge CMA Badge

Posted: 1/22/15 at 10:29 AM by dgreening

Well that is certainty good news!

Posted: 1/22/15 at 10:35 AM by spraguga

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

CCA Badge

Posted: 1/22/15 at 10:50 AM by johnklimeck


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

CCT Badge CCA Badge CCE Badge CJA Badge Integrator Badge

Posted: 1/22/15 at 11:07 AM by 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.

CCA Badge

Posted: 1/22/15 at 11:50 AM by 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

CCA Badge CMA Badge

Posted: 1/22/15 at 11:53 AM by 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....

CCA Badge

Posted: 1/22/15 at 11:54 AM by johnklimeck

cool, going to test this now

CCA Badge CMA Badge

Posted: 1/22/15 at 12:36 PM by 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.

CCA Badge

Posted: 1/22/15 at 1:08 PM by 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.

CCA Badge CMA Badge

Posted: 1/22/15 at 1:28 PM by 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.

CCA Badge

Posted: 1/22/15 at 1:33 PM by 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

CCA Badge

Posted: 1/22/15 at 2:27 PM by 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.

CCA Badge CCE Badge CJA Badge

Posted: 1/22/15 at 5:57 PM by 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 ;-)

Posted: 1/22/15 at 11:04 PM by 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.

Posted: 1/22/15 at 11:10 PM by NightFlight

hi guys, I've followed Chris.Hotte's suggestion by doing the following: 5NIwHpBhoUZNLYLfrM9c #!/bin/sh /bin/echo BootCacheKludge Beta 1.0 \- Chris Hotte 2015 \- No rights/blame reserved. /usr/sbin/BootCacheControl jettison Pr0ZPCzjLbkYMxq7OYKt 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 wait. \~2K machines under our administration. We... would have noticed AD unbinding. ;-)

Posted: 1/23/15 at 6:23 PM by 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

CCA Badge CJA Badge

Posted: 1/23/15 at 7:41 PM by 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)

Posted: 1/24/15 at 7:26 AM by 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?

Posted: 1/25/15 at 9:05 AM by 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.

Posted: 1/26/15 at 7:03 AM by yashy99

Guys it all worked. Apologies for that.

Chris.Hotte \- great script. Thank you

Posted: 1/26/15 at 2:23 PM by 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?

CCA Badge CCE Badge CJA Badge CMA Badge

Posted: 1/26/15 at 5:11 PM by jhbush1973

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.

Posted: 1/27/15 at 8:00 AM by 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...


Posted: 1/27/15 at 8:16 AM by 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).

Posted: 1/27/15 at 9:10 AM by NightFlight


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.

Posted: 1/27/15 at 9:28 AM by NightFlight


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.

CCA Badge CCE Badge CJA Badge

Posted: 1/27/15 at 9:42 AM by 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, 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.

Posted: 1/27/15 at 9:48 AM by 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...

CCA Badge CCE Badge CJA Badge

Posted: 1/27/15 at 11:24 AM by 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...

CCA Badge

Posted: 1/27/15 at 12:06 PM by Kevin

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

CCA Badge CCE Badge CMA Badge

Posted: 1/27/15 at 12:09 PM by aamjohns

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

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/27/15 at 12:14 PM by bentoms

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

CCA Badge CMA Badge

Posted: 1/27/15 at 12:14 PM by 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?

Posted: 1/27/15 at 12:31 PM by NightFlight

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

CCA Badge CMA Badge

Posted: 1/27/15 at 12:33 PM by dgreening

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

Posted: 1/27/15 at 12:33 PM by pchang

Looks like 10.10.2 just got released!

Posted: 1/27/15 at 12:34 PM by maser

without a new version of opendirectoryd, though...

Highly disappointed.

Posted: 1/27/15 at 1:29 PM by NightFlight

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

Posted: 1/27/15 at 1:35 PM by maser

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

We are *profoundly* disappointed here.

Somebody should badger Tim Cook. ;-)

CCA Badge CCE Badge CJA Badge

Posted: 1/27/15 at 2:44 PM by 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...

CCA Badge CMA Badge

Posted: 1/28/15 at 10:15 AM by dgreening

SWEET! Something to test! Thanks for posting this!

Posted: 1/28/15 at 11:07 AM by chrisw

This link worked for me

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

Posted: 1/28/15 at 12:42 PM by alexforsyth

Thanks for the link kbach!!

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/28/15 at 3:13 PM by bentoms

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

CCT Badge

Posted: 1/28/15 at 7:34 PM by WUSLS

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

Posted: 1/28/15 at 8:03 PM by azbikowski

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.

Posted: 1/29/15 at 5:11 AM by hmghmg

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

Posted: 1/29/15 at 5:39 AM by jcb

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?

CCA Badge CCE Badge CJA Badge

Posted: 1/29/15 at 7:03 AM by RobertHammen

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.

Posted: 1/29/15 at 7:25 AM by lehmanp00

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

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

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/29/15 at 7:33 AM by bentoms

@lehmanp00, did that work?

Posted: 1/29/15 at 7:36 AM by lehmanp00


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

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 1/29/15 at 7:40 AM by bentoms

@lehmanp00 nice thanks for sharing.

Posted: 1/29/15 at 7:48 AM by jcb

That is actually really helpful \- Thanks for your help!

Really, thanks.

Posted: 1/29/15 at 8:58 AM by maser


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.

Posted: 1/29/15 at 9:04 AM by lehmanp00


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.

Posted: 1/29/15 at 9:28 AM by smitty1923

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

Posted: 1/29/15 at 9:42 AM by maser


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.

Posted: 1/29/15 at 9:47 AM by lehmanp00

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

Posted: 1/29/15 at 10:07 AM by maser

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.

CCA Badge CCE Badge CJA Badge

Posted: 1/29/15 at 12:53 PM by RobertHammen

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

Posted: 1/30/15 at 9:58 AM by alexforsyth

Does the Apple Enterprise fix seem to pretty reliably fix the issue then? Do machines require rebinding to AD afterwards?

Posted: 1/30/15 at 10:04 AM by Kaltsas

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

Posted: 1/30/15 at 10:23 AM by NightFlight

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.

Posted: 1/30/15 at 11:44 AM by alexforsyth

Thanks @Kaltsas and fully understood!

Posted: 1/30/15 at 11:45 AM by SGill

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!

CCA Badge CMA Badge

Posted: 1/30/15 at 11:58 AM by Kyuubi

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

CCA Badge

Posted: 2/1/15 at 5:11 PM by mkremic

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.

CCT Badge CCA Badge

Posted: 2/1/15 at 8:47 PM by Abdi

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.

CCT Badge

Posted: 2/2/15 at 7:36 AM by WUSLS

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.

CCA Badge CCE Badge CMA Badge

Posted: 2/2/15 at 7:38 AM by aamjohns

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.

CCT Badge

Posted: 2/2/15 at 9:43 AM by WUSLS

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.

Posted: 2/2/15 at 9:48 AM by spraguga

@WUSLS Yes, we have already confirmed the OrginalHomeDir issue in this thread and this one:

You can also create a new account without the UNC path to get around this.


CCT Badge

Posted: 2/2/15 at 2:25 PM by dstranathan

Just wanted to chime-in with my observations, too.

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.


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

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


He optionally mentions running this too:

defaults write /Volumes/Macintosh\ HD/Library/Preferences/ 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?

CCT Badge CCA Badge

Posted: 2/2/15 at 10:34 PM by Abdi

Haven't had a problem on 10.10.2. But, judging from your responses; I'll stick to 10.9.5!


I take back what I said, it's even worse than before. Back to 10.9.5

CCA Badge CCE Badge CJA Badge

Posted: 2/3/15 at 8:34 PM by RobertHammen

@dstranathan \- do you have AppleCare Enterprise? If so, open a case and get the opendirectoryd test fix.

Posted: 2/4/15 at 7:15 AM by acdesigntech

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.

CCT Badge

Posted: 2/4/15 at 8:13 AM by dstranathan

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

CCA Badge

Posted: 2/5/15 at 10:09 AM by joecurrin

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.

CCA Badge

Posted: 2/5/15 at 10:11 AM by joecurrin

@acdesigntech we are still consistently seeing the issue with @chris.hotte's fix

CCA Badge

Posted: 2/5/15 at 10:15 AM by joecurrin

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

CCT Badge

Posted: 2/5/15 at 10:20 AM by dstranathan

Thanks @joecurrin

Posted: 2/5/15 at 10:53 AM by alexforsyth

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

Posted: 2/5/15 at 11:51 AM by acdesigntech

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.

Posted: 2/5/15 at 11:54 AM by acdesigntech

also, @joecurrin, thanks for the heads up that you are still seeing the issue even after applying the rc.server fix. We have not seen this issue here at our HQ, but in one of our remote offices that has statically assigned IPs for all macs (except on the imaging subnet, that's DHCP), they are seeing this issue consistently when moving a newly imaged Mac off the imaging subnet to a production network.

CCA Badge CJA Badge

Posted: 2/5/15 at 1:42 PM by kirkmshaffer

re: NDA \- is there a parallel thread on the developer forums that anyone is using? I know it's not a great solution for here, but if we can do something there, maybe here gets the benefits.

CCT Badge CCA Badge

Posted: 2/5/15 at 6:49 PM by Abdi

So.. Who wants to test OS X 10.10.3 beta to see if it fixed this?

CCT Badge CCA Badge

Posted: 2/6/15 at 3:10 AM by andysemak


Posted: 2/6/15 at 3:18 AM by khurram

while restarting keep pressing the Option key

Posted: 2/6/15 at 7:45 AM by womby

We're getting multiple issues here on several 10.10, .1 and .2 machines. Interestingly only the machines that have been imaged via Casper seem to be exhibiting this problem. Currently testing @chris.hotte's fix, and the safe boot/restart method. Looking through the 10.10.3 seed notes, it's all about the new Photo's app, nothing mentioning this issue.

CCA Badge

Posted: 2/6/15 at 7:50 AM by johnklimeck

I can no longer reproduce this boot hang on my lab iMac that I can always reproduce it on.

10.10.2, with no rc.server file. Force powered down and powered up multiple times and it always boots to the login screen, after installing a certain "10.10.x" (update) that we are not supposed to comment on.

Looks like it is addressed / fixed

Posted: 2/6/15 at 11:49 AM by NightFlight


Can you post here or PM me a copy and paste of your /etc/rc.server?

When I was originally testing I had three iMacs on a power bar with no less than 15 forced power downs (x3=45) in a row with successful restarts constituting what I believed to be a working fix before I posted it here. We now have deployed to nearly 2K 10.10.2 machines with only the occasional continuance resolving into where the Kludge was not applied or removed for some reason. I currently have it added to my deploy studio workflow and scripts which execute when the login window comes up.

Besides, its a Kluge. No guarantee it will work for everyone. Just something to try and no support! :) That being said, I'd like to know why it may not be working for you.

Please issue the command: md5 /usr/libexec/opendirectoryd and post the return value here. There may have been a silent release.

CCA Badge

Posted: 2/6/15 at 12:12 PM by johnklimeck

Sure thing,

MD5 (/usr/libexec/opendirectoryd) = 48e66dd75000feb31d66e889870fb9ee

Posted: 2/9/15 at 6:05 AM by Aristotlejones

@johnklimeck so should I open an enterprise support case referencing the tickets here and get on the "NDA" bandwagon? I'm going to try Chris's fix on some machines this morning.

CCT Badge CCA Badge CCE Badge

Posted: 2/9/15 at 7:22 AM by mlaundrie

A little trick I used to get into a stuck machine was to boot into Single User mode, delete the .AppleSetupDone file, and reboot. On the reboot, the New User Assist starts, and it creates a non-AD account that I can use to boot the machine. Not the most convenient method, but one that was worked without issue for a week.

CCA Badge

Posted: 2/9/15 at 8:28 AM by johnklimeck

10.10.3 = :)

CCA Badge

Posted: 2/9/15 at 8:59 AM by joecurrin


This is what our file looks like: Nothing special.

# Credit to chris.hotte from jamfnation
/usr/sbin/BootCacheControl jettison

Posted: 2/10/15 at 12:04 PM by Kaltsas

The MD5 hash of opendirectoryd in 10.10.3 dev preview matches what was in 10.10.1 and 10.10.2 (48e66dd75000feb31d66e889870fb9ee) and not the test version of opendirectoryd I was supplied by applecare engineering support. The replacement opendirectoryd completely fixes the issue in all testing I have performed. However the support contact is adamant it shouldn’t be used in production (and I honestly don’t know how it would shake out if I pushed it out, then Apple released the fixed version in an OS update)

I can still recreate the issue on 10.10.3 dev preview with the usual improper shutdown on an AD bound system. I have not noticed the behavior being any more “graceful” in the 10.10.3 preview. After triggering the bootlock issue I can delete the caches and cajole the system back to life.

Our Applecare contact does not know when/if the opendirectoryd fix that appears to be a permanent, Apple provided solution will be implemented.

CCA Badge CMA Badge

Posted: 2/10/15 at 12:09 PM by bwiessner


Are you using this as a startup script or how are you deploying this?

Posted Yesterday at 8:59 AM by joecurrin

This is what our file looks like: Nothing special.

\# Credit to chris.hotte from jamfnation
/usr/sbin/BootCacheControl jettison

CCA Badge

Posted: 2/10/15 at 1:03 PM by joecurrin

@bwiessne I installed as part of our imaging configuration. So this file would be installed long before we encrypted. I also tried it to a system that was already encrypted as well. Both situations produce the same results. I didn't see anything within the forum stating this file needs to be activated or called upon. It was my assumption the OS automatically calls upon it. Correct me if I am wrong...

CCA Badge CMA Badge

Posted: 2/10/15 at 3:02 PM by dgreening

Did you create the file under single user mode using the directions and then go into /etc and capture it with Composer? You should not have to tweak the permissions in Composer, as the correct permissions are set when you create the file in single user mode. Thats what I did and it has worked well for me.

CCT Badge

Posted: 2/10/15 at 3:56 PM by WUSLS

I am in the same situation as @joecurrin][/url. Does the file need to be called upon, or activated somehow?? If so, please share the details! Clarification is needed before I send a scathing email to AES.

CCA Badge

Posted: 2/10/15 at 4:18 PM by joecurrin

@dgreening yes the file was created in Single User Mode. I then captured it with composer and doubled checked the permissions.

Posted: 2/11/15 at 8:13 AM by maser

Weird -- I've tested this here and the presence of it on a laptop that will hang at hard boot will successfully boot every time (opendirectoryd patch not being in the discussion...)

@joecurrin][/url \- what hardware are you testing against?

CCA Badge

Posted: 2/11/15 at 8:20 AM by joecurrin

@maser I personally have tested the 2013 MacBook Air 13, 2013 MBPr 13. I am having techs test the other equipment for me. Oddly enough our 2013 MBPr 15 has acted fine. We install each OS on each machine and thoroughly test. Across the board we have been able to easily reproduce the issue with the patch.

Posted: 2/11/15 at 8:44 AM by NightFlight


Nope, you got it. Its a bash hook (I assume, since you don't even have to chmod the /etc/rc.server file) that's called by the system to fire up the server scripts. Since its not used by the client it was just a very handy install point. There is also /etc/rc.installcleanup (or similar) I see barking out during every verbose boot and it likely could be used as well. However I suspect the latter script would be wiped by an update.

CCT Badge

Posted: 2/11/15 at 9:01 AM by WUSLS

Hi All,

I am having this issue as well. I have tested on physical machines, and i am now testing it via a VM. I added the VM Mac OS X 10.10.2 to AD, enabled HomeFolder mount, and logged in as an AD user. Initial login had no issues seeing the home folder and was able to login without issue. Once I enabled FV2, rebooted, disconnected the network, I ran in the subject of this thread. I have tested @chris.hotte's /etc/rc.server on this VM with the same results I have gotten on physical machines. Nothing changed. Am I missing something in getting this file to be read/activated by the OS upon login???

Am I missing something in this picture? :-/

Posted: 2/11/15 at 10:19 AM by NightFlight

None of my tests include FV2 or FV as its not something we implement.

CCA Badge CMA Badge

Posted: 2/11/15 at 10:31 AM by dgreening

In my case (which is that this is working fine) we use FV2, AD, but with no UNC path enabled.

CCT Badge

Posted: 2/11/15 at 10:35 AM by spalmer

I am testing the Bootcache jettison fix posted by @chris.hotte][/url as well and I am seeing the same results as @joecurrin][/url. After forcing a power down it initially hangs at boot but after rebooting again it boots fine. I tested with both 10.10.2 and the 10.10.3 beta.

Other than the fact that I have installed a beta this is a fairly "clean" setup in that I installed only a base OS just for the purpose of testing this issue. There is no third party software and no extensive customizations other then to enable the Remote Desktop client and bind to Active Directory using our standard binding script. Contrary to other reports I can consistently reproduce this issue on a year old MacBook Pro with an SSD drive.

Edit: I should have mentioned that I do not have FV enabled on this MacBook Pro used for testing.

Posted: 2/11/15 at 11:13 AM by NightFlight

My distribution method is to copy a file that I get onto the client computer in user space via a centralized rsync server repository that updates every boot. The script is copied by a daemon that I trigger from the login window using a customize version of DeployStudio's

The method really doesn't matter so long the file you get in there is clean. Best to test and debug it prior to deployment. If its not executing properly, sometimes adding -x to bash can sometimes shed some light.

Example bash script:

#!/bin/bash -x
bash commands
bash commands
bash commands

CCA Badge

Posted: 2/11/15 at 11:13 AM by joecurrin


Also, tried configuring /etc/rc.installcleanup with no success.

CCT Badge

Posted: 2/11/15 at 11:46 AM by dstranathan


I can't find any trace of the rc.server executing. I can't tell if its working.

For troubleshooting & QA purposes, shouldn't the output and comments contained in the rc.server script be displayed when booting into Verbose mode?

Likewise, shouldn't the standard output generated by OS X at boot also be written to a system log in /var?

#!/bin/bash -x
/bin/echo **
/bin/echo BootCacheKludge Beta 1.0 \- Chris Hotte 2015 \- No rights/blame reserved.
/bin/echo Dan added this for testing the OS X Yosemite boot hang issue on 02-11-15.
/bin/echo Remove rc.server once this issue is resolved by Apple Inc.
/bin/echo See JAMFNation forums for more info. /usr/sbin/BootCacheControl jettison
/bin/echo *

My environment: We do not use FV2. All Macs are bound to AD \- but with no UNC homedir paths are enabled.

Posted: 2/11/15 at 12:00 PM by NightFlight

You know, I've not been able to locate the console logs, either from single user or loginwindow \- etc for quite some time. I'm guessing its not been properly enabled in syslog-ng or whatever apple has elected to use these days. For things like that I really do prefer a good linux distro for the package management, documentation and source code. *sigh*

But you should be seeing your echo'ed output verbose boot console. Hold cmd-v on startup for verbose or issue:

nvram boot-args='-v'

Oops, don't forget sudo. Pardon me, I live in root.

Posted: 2/12/15 at 8:07 AM by lehmanp00

Would the rc.server fix cause "1st-boot actions" to fail because the fix is blowing away any data in the BootControlCache?

Like say...DeployStudio workflow data that is postponed until 1st boot?

Posted: 2/12/15 at 1:46 PM by maser

So, FWIW, I tried this again because I was curious.

I took an OS-only, clean install 10.10.2 system. All I did was bind it to our AD (well and I configured it as an ARD client and enabled root...). 6 hard reboots -- 6 failures to boot.

Using ARD, I pushed an /etc/rc.server file to that computer.

These permissions:
-rw-r--r-- 1 root wheel 129 Feb 12 14:18 rc.server

These contents:
host-143:etc root# cat rc.server
/bin/echo BootCacheKludge Beta 1.0 \- Chris Hotte 2015 \- No rights/blame reserved.
/usr/sbin/BootCacheControl jettison

host-143:etc root#

And 6 out of 6 *subsequent* hard reboots -- the system boots up.

This is on an older MacBookPro6,2 (8G RAM 2.5Ghz i5). I guess YMMV. But for me, it's night-and-day -- *especially* on old computers.

Posted: 2/13/15 at 7:47 AM by maser

For those of you who say this isn't working: Are you giving it enough time to reboot?

There's a difference in *not* having this kludge -- where it never boots up -- vs having the /etc/rc.server file where it can seem like it might still be stuck -- but will eventually kick through and boot up.

CCT Badge

Posted: 2/13/15 at 9:55 AM by spalmer

@maser Yes, I just tried again and the progress bar stays at about 25% for 30 seconds to a minute then slowly proceeds to 50%. After an hour at 50% I think I have given it plenty of time to boot. :-)

After I do another force power down and reboot again it boots fine. The properties and contents of my file are below:

tesmac:~ testadmin$ ls -la /etc/rc.server 
-rwxr-xr-x  1 root  wheel  168 Jan 30 15:39 /etc/rc.server
testmac:~ testadmin$ cat /etc/rc.server 

# This file was created by IT Services to prevent the OS X 10.0 Yosemite hang at startup on Active Directory bound Macs.
/usr/sbin/BootCacheControl jettison

Posted: 2/13/15 at 10:06 AM by maser

Permissions are slightly different on the file, but maybe put a blank line *after* jettison?

I dunno. I was skeptical, but it works here.

CCA Badge CCE Badge CJA Badge

Posted: 2/13/15 at 1:18 PM by RobertHammen

For those having issues with packaging it up, I've put a signed installer PKG here:

The PKG (which you can decontstruct/inspect with Composer) just creates the /private/etc/rc.server file with the BootCacheControl jettison command in it.

If included as part of an imaging configuration, you may want to ensure you've selected the checkbox to "Install on boot drive after imaging" in the Options tab of the Info tab for the package inside Casper Admin.

When Apple releases a fix, you should be sure to remove this file from any 10.10.x system that has it installed.

Posted: 2/13/15 at 1:19 PM by Account deleted

@ johnklimeck

Has 10.10.3 fix this issue? I've been putting off the upgrade for the time being.

Posted: 2/13/15 at 2:19 PM by NightFlight

NDA says you can't talk about pre-releases. However given that I personally have not downloaded or viewed any part of it in any form \- I can state that the consensus thus far stated in this thread has been an equivocal NO. As of yet, it does not.

CCT Badge

Posted: 2/13/15 at 5:14 PM by spalmer

@maser Tried the exact same permissions and a blank line at the end for the heck of it. I even added an echo command and I am still not getting the same results as you.

So rather than being anecdotal about it, as with my previous testing, I did 15 tests each of logging into a local admin account (while the Mac was bound to AD) and logging into an Active Directory account. I thought I would try both types of accounts just to see if there was a difference in behavior. Also, since this MacBook Pro normally takes about 10 seconds to boot successfully I only waited about a minute which gave it plenty of time get to the 50% mark and hang.

I also noticed another clue in that when it boots successfully the mouse cursor shows up in the upper lefthand corner right after the progress bar hits about 10% but when it does not successfully boot the mouse cursor never shows up.

I did not find any difference between logging in with the two types of accounts. Each failed 46% of the time. I also noticed that 13% of the time it hung for more than one reboot before it would finally boot successfully, and in one case it hung for a total of four reboots.

I also tried modifying my rc.server file as follows to see if I could log whether or not the BootCacheControl jettison command was happening every time.


# This file was created by IT Services to prevent the OS X 10.0 Yosemite hang at startup on Active Directory bound Macs.

/bin/echo "IT_Services_BootCacheJettison"
/usr/bin/logger -t "IT_Services_BootCacheJettison" "Jettisoning the BootCache..."
/usr/sbin/BootCacheControl -vvv jettison | /usr/bin/logger -t "IT_Services_BootCacheJettison"

Unfortunately nothing showed up in system.log so this may be happening too early in the boot process for logging services.

Posted: 2/13/15 at 5:19 PM by NightFlight

I would say that its way to early for logging.

When debugging weirdness I use

echo This is a test &>/private/tmp/testoutput.txt

Posted: 2/16/15 at 2:50 AM by benshawuk

I can confirm that the Chris Hotte fix worked on 10.10.1 macs but is now back again and affecting macs running 10.10.2 :(

Posted: 2/18/15 at 10:58 AM by NightFlight

Did you re-apply the kludge/patch of /etc/rc.server? The update may have pulled it.

CCA Badge CMA Badge

Posted: 2/18/15 at 12:42 PM by dgreening

The 10.10.2 update does indeed pave over the rc.server file (in that it removes it). I made an extension attribute to check on it's existence (or lack thereof) so that I can target those machines for re-application. Here it is:


if [ -e /etc/rc.server ]; then echo "<result>Exists</result>"
else echo "<result>Does Not Exist</result>"

CCT Badge CCA Badge CCE Badge CJA Badge Integrator Badge

Posted: 2/18/15 at 12:47 PM by davidacland

It would be nice if the update had fixed the problem rather than trash the workarounds people have been using!

CCA Badge CMA Badge

Posted: 2/18/15 at 12:51 PM by dgreening

Yeah, I hear that! Bet they will drag their heels on the opendirectoryd update until 10.10.3 too!

Posted: 2/19/15 at 3:03 AM by benshawuk

Chris Hotte: Yes, my management software automatically pushes the file out so it's definitely still there.
In fact I think I've resolved the problem: After an unclean shutdown the 10.10.2 macs do actually boot, but take quite a bit longer with the progress bar stuck around the middle (a few minutes or so). I think I was just being impatient and incorrectly assumed that "the boot problem" was happening again.

One other thing I noticed that I'm not sure has been mentioned here: The macs appear to need a reboot after the file has been deployed, before it takes effect. This is another reason why I've spotted some machines exhibiting the problem, despite having the rc.server fix applied to them (some of our users don't reboot for weeks on end).

Sorry for the "false alarm".

Posted: 2/23/15 at 4:07 PM by mwmc

Great thread!


What hardware have you ran your fix on? We haven't had any success with our Yosemite shipped Air's and Mini's.

Posted: 2/23/15 at 5:06 PM by NightFlight


Older Mini's, older iMacs. A batch of Yosemite shipped iMacs and a couple Yosemite shipped MBP retinas. I've tested success on the Yosemite Shipped MBPs. I don't have any Yosemite shipped MB Air's or Mini's.

Posted: 2/23/15 at 5:17 PM by calumhunter

FWIW 14D87h
MD5 (/usr/libexec/opendirectoryd) = 48e66dd75000feb31d66e889870fb9ee

But hey check out the new Photos app.............

Posted: 2/23/15 at 11:31 PM by Aaron

So I came across this today, even though we don't use FileVault by default, we had a new user with a pre-existing Yosemite Macbook with FileVault enabled. I didn't realise until the first reboot after setting it up.

Booting in single user mode and jettisoning the boot cache did nothing. Tried booting into recovery mode, and turning off encryption through Disk Utility, but even though the conversion status was "Converting" the conversion direction remained at "none". Tried booting it to target disk mode and plugging it into my 2013 Macbook running Mavericks, but it would crash my Macbook when I went to unlock the volume.

In the end, I plugged it into my test Macbook (2012 model running Yosemite) and did it through that. Conversion direction is showing as "backwards" and the progress percentage is going up. So I'll call that a tentative success for now.

What a mess.

Edit: Disabled FileVault successfully, but still had the same issue of getting stuck at 50%. Putting in the rc.server workaround fixed it this time (which didn't fix it when I had Filvault enabled).

Thanks for your suggestions, it saved me.

Posted: 2/24/15 at 6:10 PM by rstansifer

I've been skimming this thread for months. We have about 120 Macs running off of Active Directory. No FileVault (I loathe FileVault...working for Apple Retail made me hate that system with a passion) and running ESET Antivirus. However, our oddity is that the hang does not occur consistently. I've seen Macs that have yet to hang others that have already hanged.

For a time, I was able to CMD-V Verbose Boot and for some reason I couldn't figure out, that seemed to solve the problem. It didn't make any sense to me. I had stumbled upon it when trying to troubleshoot the issue.

Afterwards, I found that a Safe Boot and a Restart would solve about 98% of the issues and we never had a reoccurrence. Still, it's frustrating to have to deal with this issue at all.

So fsck is run during a Safe Boot...but my question is why would that be solving the problem?

Posted: 2/24/15 at 6:44 PM by calumhunter

@Aaron @rstansifer
FV isn't needed to produce the hang.
10.10+AD bind +hard power off = hang
very easily reproducible, with the exception that "some" new machines with fast SSD's don't always exhibit the problem

I would hazard a guess that fsck, safeboot and verbose mode are not doing anything to solve the issue and that the issue still exists, you just are not seeing the symptoms (ie the hang) on the hardware you have.

Posted: 2/24/15 at 7:03 PM by htse


I have a vague recollection from OS X recert materials that Safe Boot flushes the boot caches, of course my memory could be at fault.

I've started seeing this issue appear in the last week, or at least similar symptoms, thought it seems to be further along in the startup process. The logs are giving me precious little to work with. I've tried the BootCacheControl jettison but didn't seem to have the desired outcome.

Posted: 2/25/15 at 5:48 PM by tunecorpit

@rstansifer @calumhunter

We have been experiencing the same issue. We have 180+ macbook Pro devices in our environment. So far it doesn't matter if the devices have SSDs or not, but it does require a hard power off or loss of power to cause the issue. A normal reboot will work most of the time until a hard power is done. Once the issue happens, even if you are able to recover it, it will continue to happen on every reboot. Wiping and reinstalling so far has been the only thing that fixes it completely (until another hard boot)

Posted: 2/25/15 at 6:00 PM by calumhunter

@tunecorpit, have you tried setting up the rc.server script as mentioned above on a machine *before* you hard power it off? For me this has resolved the issue

I'm aware of sites with 100 times your number of machines being affected. Apple's response to this is pretty appalling. I know they've been discouraging AD use for some time but come on guys

Posted: 2/25/15 at 6:28 PM by acdesigntech

Discourage AD, in an enterprise... HA! best thing i've heard all night

CCA Badge CCE Badge CJA Badge

Posted: 2/25/15 at 6:36 PM by RobertHammen

If you have AppleCare Enterprise and have experienced this, by all means open a case. Apple fixes bugs based on number of affected users. I'm sure it appears that the number of affected users is low...

Posted: 2/25/15 at 7:39 PM by calumhunter

no enterprise support contract here :(

Posted: 2/26/15 at 6:39 AM by acdesigntech

we do have an enterprise contract. I opened a case. Biggest waste of time ever...

The engineer had absolutely no clue about anything named opendirectoryd or anything even resembling that, or at least he claimed not to. But he WAS able to assure me this was their top priority. Yeah, right. If that was so then 10.10.3 would have been out weeks ago and this issue would be FIXED. But I'm sure Photos makes up for it.

That company's such a joke.

CCA Badge CCE Badge CJA Badge

Posted: 2/26/15 at 7:59 AM by RobertHammen

Apple schedules their OS and patch releases and does not deviate. The .1 will typically ship a month after the OS releases, the .2 update ships 2 months after that, ad infinitum.

What we should have seen was a separate standalone update (like the bash fix or NTP) that was eventually rolled into a future OS update. Not sure if the rumored opendirectoryd patch addresses the issue, or why it hasn't been released yet, but there must be a reason...

CCT Badge

Posted: 2/26/15 at 8:33 AM by dstranathan


Apple is pretty good with metrics and customer numbers in general.

I'm sure Apple can extrapolate the number of Enterprise customers (or even SMB customers who have even the most basic AD infrastructure) and therefore come up with a ballpark estimate of how many Macs are currently unable to boot. Its got to be hundreds of thousands or possibly millions or Macs world-wide.

My stomach turns when I say the words "Unable. To. Boot." Kinda a big problem.

By the looks of Tim Cook's comments and publicized plans on Enterprise customers (including the IBM partnership etc), Id say Apple might be on the right track \- at least compared to Steve Jobs leadership. I'm am cautiously optimistic.

At least I don't have to worry about bind my Apple Watch to Directory Services. Wait...Proximity-based Kerberos ticket granting via Apple Watch perhaps? Never mind.

For the record, the /etc/rc.server workaround has been working for me thus far.

CCA Badge CCE Badge CJA Badge

Posted: 2/26/15 at 8:50 AM by RobertHammen

If anyone has ever worked with AppleCare Enterprise, one of their standard questions is the number of systems affected.

This is a factor on how timely bugs are addressed and they do_not extrapolate the data.

So if only a handful of people report it, it remains unaddressed. Seem like a weak system? Yeah. But that's the way it presently is.

If you don't have AppleCare Enterprise, talk to your SE's or Sales reps. Tell them how you are not adopting Yosemite and/or not purchasing new systems until this is addressed.

Agree Apple under Tim Cook sees the enterprise as more of an opportunity (moreso than Jobs' "Eff these guys" attitude). But they aren't there yet and this is one of their Achilles heels. But we've drifted off-topic... I have implemented the rc.server workaround and it seems to work fine at multiple clients. No idea why it doesn't everywhere, but...

CCA Badge CCE Badge CJA Badge CMA Badge

Posted: 2/26/15 at 8:50 AM by mzago

For those using /etc/rc.server workarounds... make sure you append /usr/sbin/BootCacheControl jettison to the file if it exists. Most clients will not have it, but anyone that is using OS X will already have an /etc/rc.server with server tweaks.

Posted: 2/26/15 at 10:33 AM by jarednichols

@RobertHammen][/url is correct.

Radar, radar, radar.

Currently we prioritize fixes by knowing how many customers are effected. If you've not alerted us to your situation, file a Radar and ensure your SE knows so we can increase the impact scores of bugs.

Posted: 2/26/15 at 2:44 PM by casper100

I rarely post unless I have some useful input and I have experienced this on such a small level, I haven't input anything prior to now. I hesitate even now, as it may seem like a red herring but.....
I have only 2 machines running 10.10.x, a test bench machine (iMac 21.5, mid-2011) for testing against internal systems and software (will NOT take 10.10 into production until .3 \- or later) and my own personal MacBook Pro. Both have FV2 enabled.
The iMac is bound to AD and I have never had the issue-but have never had to hard reboot and haven't forced it for kicks.
My personal MBP (2 local accounts) is not, and never has been, bound to ANY directory service and I experienced this DAILY.
The cause of the "KP/shutdown/hang requiring hard reboot" was \- every single time \- accessing something that used Flash in a Chrome browsing session.
Logging into and out of another local account with FV2 rights would fix it until the next crash. Flash and Chrome have since updated and I have used an *ahem* unauthorized opendirectoryd fix and have not had a login hang since \- even after forced reboots.

Posted: 2/26/15 at 8:12 PM by calumhunter

@casper100 I think your issue is a different problem to what this thread is reporting.
The problem i think the majority of this thread are reporting is very easily reproduceable
1. install 10.10
2. bind to ad
3. hard power off
4. reboot = 50% progress and machine is hung will not boot further.

I suspect that the fixed/patched opendirectoryd that you have also resolves other reported dns-related issues which i think is more the case your seeing where you are getting KP/system freezes ect ect

CCA Badge

Posted: 2/27/15 at 3:27 PM by mm2270

Hi all. I haven't chimed in on this thread yet, but since we started rolling out Yosemite in our environment over the last couple of weeks, we've been hit sporadically with this issue as well.
At first, we started implementing the rc.server fix posted by Chris Hotte above. In many cases this did seem to resolve the issue on our affected Macs, but not in all. We were still seeing cases of either total hangs (like leaving it for days at the 50% mark and never progressing) or very very long boot/login times.

Just today after doing some more testing we revealed something that I believe was mentioned either in this thread or another one here on JN. I can't take credit for discovering this since I recalled reading a post by someone that the theory was a hidden dialog is causing the hang to happen. (Edit: found the original post with this information: There is in fact a hidden dialog popping up that is causing many of our Macs to get stuck when the user logs in off the LAN. In our tests, we saw that being connected (wired) to the LAN bypassed the issue. Only when off the network was when we saw it 100% of the time.
We have FileVault 2 enabled on our imaged Macs and what's happening is, OS X Yosemite is NOT respecting the Mount Home share and Use UNC Path settings that are both Disabled. It is still attempting to connect to our AD user's home share points when off the network and coming up with an error dialog. Problem is, this can't be seen normally when FV2 is enabled.
However, here's what we did to reveal it.

After getting into an affected Mac, we ran:

sudo defaults write /Library/Preferences/ DisableFDEAutoLogin -bool YES

This forces the regular username & password fields to appear after unlocking the drive at the FV2 login screen. Once we did that we rebooted the Mac and kept it off the wired network and finally saw the dialog which stated something along these lines:

There was a problem connecting to the server "servername" The server may not exist or it is unavailable at this time. Etc, etc.

with an OK button. Important note here is that the dialog appears BEFORE the desktop appears, not after. So until that button is clicked, the login will not proceed into the user's Desktop. This same dialog is coming up when the DisableFDEAutoLogin is set to False as well but it doesn't show up, which causes it to hang at 50% indefinitely. Pressing the Return key once the hang happens allows the Macs without that FDE setting turned on to continue the login.

I'd love to hear from others also seeing this if they can run the defaults command above and see if they reveal the same error pop up after turning that setting on. As I said, although the rc.server BootCacheControl command has fixed many cases, it isn't working all the time, and we think this is why.

CCA Badge CCE Badge CUG Badge Integrator Badge

Posted: 2/28/15 at 3:45 AM by bentoms

Just to add, we updated our Casper DP's.. 1st restart post update was fine. Some hung on the 2nd or later restarts.

Deploying a modified rc.server file as per @chris.hotte's directions seems to have worked.

We took a DMG of the original, then made the changes to the original & deployed that. The copy of the original DMG wil be redeployed to these servers once YoYo is not a nogo.

Posted: 3/2/15 at 1:07 PM by jasonh

Has anyone been able to confirm or deny opendirectoryd love in 14D87p? (Public Beta, no NDA)

CCA Badge CMA Badge

Posted: 3/2/15 at 2:25 PM by dgreening

opendirectoryd is still at build 382.0 on 10.10.3 Public Beta. <sigh> apple...

Posted: 3/2/15 at 3:03 PM by jasonh

I'm sure that having access to diverse emoji affects a far greater number of people, but come on. Fatal showstoppers like this have to qualitatively jump to the front of the line, or what is it exactly that we are all sitting around doing with our professional lives? They even have a patch for it already! Pretty deplorable and sadly confirms the worst biases against Macs in the enterprise.

CCA Badge

Posted: 3/2/15 at 5:36 PM by nessts

Why, as Spock once said "the needs of the many outweigh the needs of the few (or the one)", And Apple needs Many dollars more than they needs a few. They are probably all rolling around in shock trying to figure out how Microsoft released the tablet/keyboard surface thing that snaps together and runs a real OS with normal Apps for about the same price as an iPad and trying to figure out how to release a touch screen computer without looking like windows copycats to worry about a few enterprises or schools authentication issues. Lets complain about the cheap wifi chipset they use in these computers so that if you use bluetooth and wifi in an office environment with multiple Access points your computer spends its whole day trying to figure out what 2.4GHz AP to connect to, or no more locking port for an office environment on your laptops, while we are at the complaint game. Again the normal average 99% of the users wont notice or complain or leave for anything better so Apple still wont care.
They have slowed down the hardware, dumbed down the OS so it looks faster on slower hardware, while trying to add so many cool new features what do you expect

Posted: 3/5/15 at 12:06 PM by salrin_michael

I am seeing build version 381 for < 10.10.2 or lower \- the Beta Build is showing version 382. I am currently testing with 10.10.3 bound to AD. I will keep the thread posted to the results.

Posted: 3/5/15 at 12:31 PM by salrin_michael

quick test \- \- -10.10.3 fails......

Posted: 3/9/15 at 3:16 PM by arosario

For those with profiles using AD credentials go ahead and try this:

Go to system settings>>users>>Unlock>>Click the account you have issues with>>Network account server, delete the current network account server

We disconnected the user from the domain, made a new user name called test admin, rebooted and was able to login (only have to do this if you are remote)

Once you are in the profile, re add the user to the domain, reboot and it should work.

That is what we figured out was going on for some reason when they moved to crazy networks at hotels and such their mac would never boot, only into safe mode.

Try it out and see how it goes.

CCT Badge

Posted: 3/11/15 at 8:08 AM by dstranathan

So far, the /etc/rc.server workaround has been working for my Macs...until yesterday.

My Desktop techs had a support call for MacBook Air that had succumb to the boot hang issue. After further inspection, I determined that the /etc/rc.server file was in place. The fix/triage consisted of the usual voodoo: PRAM zap, boot into Recovery Mode, repair disk permissions, etc.

CCA Badge CSE Badge CMA Badge

Posted: 3/11/15 at 9:58 AM by rlincoln

My environment consists of about 75 Macbook Pro retinas and Macbook Airs that are:
-ad bound
-FileVault -Hangs at login

Booting to single user mode and running a fsck only fixes it temporarily in my experience. All of the other usual "voodoo" works for a while then back to square one as well.

Running a machine with 10.10.3 beta and it seems to be better, but no guarantees.
unbinding from AD seems to have fixed it. After I rebound it to AD the problem came back....Hope this helps some.

CCA Badge

Posted: 3/11/15 at 2:35 PM by emily

If only they would let me deploy Macs not bound to AD. It's my dream. Someday… someday……

Posted: 3/11/15 at 3:03 PM by Hikaru

I have a macbook pro.
I have tried the Pram Nvram Smc resets. No luck
I also did the disk utility verify and repair. no luck on that
I tried the sin-user mode I tried the fsck and mount tricks. no luck
I even tried the turn off wifi and reboot. no luck
Can anyone come up with any ideas.
This happened to me last night actually.
If it helps I did delete the IPMonitor in usr/library/systemconfig by accident
and I DO have sophos .
I did not backup so wiping clean would be harsh on me

Posted: 3/11/15 at 3:39 PM by Hikaru

When I went into disk utility and selected my MAC HD drive. I put in the password. I selected verify disk permissions I got this:
User differes on "private/var/db/displaypolicyd"; should be 0; user is 244
Group differs on "private/var/db/displaypolicyd"; should be 0; group is 244

When I repair permissions says same as above plus:
Repaired "private/var/db/displaypolicyd"

Posted: 3/11/15 at 3:52 PM by spotter

@Hikaru I was in the same boot nothing worked except for @mm2270 recommendation which is stated in this thread...

sudo defaults write /Library/Preferences/ DisableFDEAutoLogin -bool YES

after running that I saw the error he described, the device was trying to connect to a network resource.

Posted: 3/11/15 at 3:57 PM by Hikaru

What are sudo defaults? @Potter and Do i go into single user mode or do i go into disk utility then bring up mobile terminal?

I entered this into Single-User mode:
sudo /Library/Preferences/ DisableFDEAutoLogin -bool YES
it responds with:
sudo /Library/Preferences/ Command not found
Any help?

CCA Badge

Posted: 3/11/15 at 4:51 PM by mm2270

@Hikaru Is this your own personal Mac, or a company owned system? This thread primarily discusses an issue that affects Macs joined to a Microsoft Active Directory domain and, in many cases also running FileVault 2 encryption.
It sounds like the problem you have is on a personal Mac. Is that the case? While its possible you have FileVault 2 enabled, its unlikely you are joined to an Active Directory domain, if its your own Mac.

Also, can you clarify the exact problem you're seeing? Is it hanging after it boots up at around the 50% mark in the progress bar?

I ask all this because you may be experiencing a problem different than what is described on this thread.
Have you tried booting from Recovery HD at any point? Wasn't clear in your post if you have or not.

Posted: 3/11/15 at 4:57 PM by Hikaru

This is a personal mac computer. I turn on my computer it loads with the apple logo then hangs at 50%

CCA Badge

Posted: 3/11/15 at 5:07 PM by mm2270

And what about the other stuff? Disk encryption that you know of? i.e, does it boot up and ask for a password with your user icon or just boot and get hung on the progress bar? Have you tried Recovery HD and checking the disk?

Also, take a look at this post in this very thread from Chris Hotte:

You may be having the boot cache issue as described. If so, the fix Chris outlines may help. Follow the instructions exactly.
No guarantees it will help, since I honestly don't know how your Mac is configured. Good luck.

Posted: 3/11/15 at 7:45 PM by Hikaru

I do not see a recovery disk.
I turned off encryption via Disk Utility.

I did chris hottie's way and I am just confused. I get the window and everything but I do not know how to apply settings etc. I did it exactly but the thing is that I press enter and it just starts another line/ Is there a more thorough step by step version?

Posted: 3/11/15 at 11:23 PM by pchang

@emilykausalik ...that is my dream too!'ll happen one day....

Posted: 3/12/15 at 9:45 AM by NightFlight


Are you an Admin, responsible for a company's workstations? If you are just an end user - this workaround/resolution does not make sense for you and likely you have another issue. If you do not have Active Directory enabled - this workaround is not the fix you are looking for.

If do not know how to use the command line and related editors - this is not the forum you are looking for. You need more basics first and this is not the platform for that instruction.

I haven't read the contents of this link, but at a glance it appears to be what you require to get started:

I know its on Linux, but MacOS is just darwin based, so its essentially the same when on the command line.

CCA Badge CMA Badge

Posted: 3/12/15 at 12:30 PM by dgreening

10.10.3 Dev Beta users check the opendirectoryd build in the latest release. :D

CCA Badge

Posted: 3/12/15 at 12:37 PM by EliasG

@dgreening spead the news what is it?

CCA Badge CMA Badge