Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Yosemite Macbooks stuck at 50% boot (Progress Bar)

Hi,

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

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

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

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

Thank You!

Like Comment
SOLVED 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....

http://www.macissues.com/2014/10/27/filevault-bug-makes-yosemite-pause-or-hang-at-login/

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

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

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

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

Like
SOLVED 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 (https://www.sophos.com/en-us/support/knowledgebase/121510.aspx) \- 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.

Paul

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

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

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

Like
SOLVED 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?

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

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

Like
SOLVED Posted: 11/17/14 at 6:43 PM by haircut

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?

Like
SOLVED 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:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

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

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

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

Like
SOLVED 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?

Like
SOLVED 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).

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

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

@jtol

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.

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

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

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

I've been following https://discussions.apple.com/thread/6606429 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.

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

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

Like
SOLVED 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

Like
SOLVED 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!)

Like
SOLVED 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 https://jamfnation.jamfsoftware.com/discussion.html?id=12901#responseChild75864) 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]'.

Darren

Like
SOLVED 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
reboot

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.

Like
SOLVED 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?

Darren

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

Like
SOLVED Posted: 1/9/15 at 8:52 AM by haircut

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

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

Like
SOLVED 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?

/System/Library/Extensions/BootCache.kext

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

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

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

*Update*

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.

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

Like
SOLVED 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/com.apple.loginwindow 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.

Like
SOLVED 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?

Like
SOLVED 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?

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

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

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

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

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

@spowell01

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?

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

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

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

Like
SOLVED 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
reboot

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

Like
SOLVED 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

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

Like
SOLVED 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:

/usr/standalone/bootcaches.plist

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!

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

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

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

Like
SOLVED 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:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

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

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

Like
SOLVED 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/com.apple.loginwindow 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!

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

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

Like
SOLVED 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/sh
/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.

Enjoy!

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

Like
SOLVED 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?

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

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

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

Cheers

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

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

Like
SOLVED 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?

Thanks

Like
SOLVED 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?

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

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

https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/

Like
SOLVED 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
reboot

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.

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

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

Like
SOLVED 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
reboot

Link to forum post: https://discussions.apple.com/thread/4960066

Like
SOLVED 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?

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

Like
SOLVED Posted: 1/15/15 at 1:06 PM by spraguga
Like
SOLVED 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.

Thanks!

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

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

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

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

@tnielson

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

Pre-installs...
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*

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

@chris.hotte

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

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

Again:
external image link

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

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

Like
SOLVED 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

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

Like
SOLVED 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?

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

Like
SOLVED 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?

Like
SOLVED 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:

#!/bin/bash
rm -f /etc/rc.server

Hope that helps!

Cheers!

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

@frank][/url

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.

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

Cheers

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

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

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

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

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

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

Like
SOLVED Posted: 1/20/15 at 3:24 PM by haircut

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

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

@bmwarren

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

Like
SOLVED Posted: 1/20/15 at 3:41 PM by haircut

@spowell01 Wonderful, thanks!

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

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

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

Cheers,
Gavin

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

Like
SOLVED 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,
Sam.

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

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

Like
SOLVED 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

Like
SOLVED 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/sh
/bin/echo BootCacheKludge Beta 1.0 \- Chris Hotte 2015 \- No rights/blame reserved.
/usr/sbin/BootCacheControl jettison

  1. Reboot.

When we loaded it, the actual Mac was no longer on the domain. Is that supposed to happen if your Mac was previously on the domain?

Thanks
Yashy

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

Coincidence?

Cheers,
Gav

Like
SOLVED 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?

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

John

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

Well that is certainty good news!

Like
SOLVED 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?

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

sure,

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

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

Like
SOLVED 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

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

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

cool, going to test this now

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

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

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

Like
SOLVED 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

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

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

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

Like
SOLVED Posted: 1/22/15 at 11:10 PM by NightFlight
hi guys, I've followed Chris.Hotte's suggestion by doing the following: x39kO8yw3DGFaAd3ytkx #!/bin/sh /bin/echo BootCacheKludge Beta 1.0 \- Chris Hotte 2015 \- No rights/blame reserved. /usr/sbin/BootCacheControl jettison vTyhjJOLj7TrqUFIcOK8 When we loaded it, the actual Mac was no longer on the domain. Is that supposed to happen if your Mac was previously on the domain? Thanks Yashy

Thats odd. I tested on 40+ workstations bound to AD for a week prior to full roll out on 1500...no wait. \~2K machines under our administration. We... would have noticed AD unbinding. ;-)

Like
SOLVED 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

Like
SOLVED 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)

Like
SOLVED 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?

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

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

Guys it all worked. Apologies for that.

Chris.Hotte \- great script. Thank you

Like
SOLVED 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?

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

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

Thanks

Like
SOLVED 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).

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

@maser][/url

So Chris -- you did *nothing* with the opendirectory.d patch that was indicated above? And you can force-shutdown machines over and over with just your "jettison" option?

Yes. I don't have the patch. I didn't know Apple Enterprise support was still around.

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

@Kaltsas

The opendirectoryd patch is being provided to Applecare Enterprise OS Support customers, it is not generally available, and is intended only for testing to ensure no reoccurrence of the AD lockout issue. I'm holding out hope it will get wrapped into 10.10.2 since 10.10.2 hasn't dropped yet (however I can still recreate the AD lockout issue on the latest developer build).

Not to de-rail this thread \- but 'ensure no reoccurrence of the AD lockout issue'... that makes me laugh. I've never not seen OSX inappropriately lock out both AD and OD accounts. Since I can't alter policy on my AD, I loop a script to unlock all accounts every minute to render our Enterprise functional. I mean, if I turn off that script \- we'd have to hire a guy just to unlock accounts all day.

Like
SOLVED 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 support.apple.com, not in the SUS stream, and rolled into the next major update (10.10.3).

@chris.hotte AppleCare Enterprise is busier/more popular than ever, with the increased prevalence of Macs in corporate enterprise. I work with engineers from there quite a bit at varying client sites.

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

Like
SOLVED 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…

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

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

Like
SOLVED 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?

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

Like
SOLVED 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."

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

Looks like 10.10.2 just got released!

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

without a new version of opendirectoryd, though...

Highly disappointed.

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

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

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

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

SWEET! Something to test! Thanks for posting this!

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

This link worked for me

https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/

. From the recovery partition (or target-disk or single-user mode, if you don’t have a firmware password,) deleting the following directories has sometimes been enough:
rm -rf /Volumes/Macintosh\ HD/private/var/db/BootCache*
rm -rf /Volumes/Macintosh\ HD/Library/Caches/com.apple*

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

Thanks for the link kbach!!

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

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

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

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

Like
SOLVED 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?

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

Like
SOLVED 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
mv com.apple.loginwindow.plist com.apple.loginwindow.plist.old
reboot

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

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

@lehmanp00, did that work?

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

@bentoms

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

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

@lehmanp00 nice thanks for sharing.

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

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

Really, thanks.

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

@lehmanp00][/url

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

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

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

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

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

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

@maser

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

I did not try the rc.server fix.

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

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

@lehmanp00

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

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

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

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

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

Like
SOLVED 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?

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

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

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

Thanks @Kaltsas and fully understood!

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

Like
SOLVED 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

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

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

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

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

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

Like
SOLVED 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:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

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

Cheers!

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

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

My Desktop team bought (50) 2013 iMac 21.5" workstations for our 2014 summer Refresh. These are the second generation "thin" iMacs. The Macs arrived in July, but remained in Apple retail boxes until August where there were imaged with my 10.9.4 Mavericks production modular image (DeployStudio/NetBoot). 40 of the 50 iMacs went into production running 10.9 Mavericks last summer/fall.

The remaining (10) iMacs got pushed back due to other projects in 2014, so they didn't get deployed until Jan 2015.

By this time I had a production Yosemite 10.10.1 image ready, so the Desktop Techs re-imaged the new iMacs again, this time with my 10.10.1 Yosemite image.

According to the techs, the iMacs came up from the DeployStudio imaging process just fine once, and then the issue covered in this form post was discovered \- it affected 9 out of the 10 Yosemite iMacs. Why (10) iMac is immune to the issue is beyond me. Weird.

Before I discovered this post, we tried the following things:

Rebooting \- fixed 1 iMac. That was easy!
Zapping PRAM \- fixed 1 iMac
Running fsck and/or Recovery GUI tools \- fixed the remaining Macs
Multiple rents were required. Like a Vegas slot machine.
One of my Techs claimed that unplugging Ethernet at boot fixed 1 iMac too. One Tech here also swears by running fsck first THEN 3 PRAM zaps.

Total voodoo. Am I on an episode of "Mac Admin PUNKED Season 2"?

I did notice a few things:

The iMacs were all stuck on a light get and dark grey boot loader screen. After the Macs were "fixed" they started booting with the new, improved sexier black screen with white logo. Related? I dunno, but there is a pattern here.

When booting into Verbose mode, All the iMacs would all get stuck at the following standard output boot message: "promiscuous mode enabled succeeded" and other output related to Apple/Broadcom driver information. This was 100% reproducible. Sounds like boot cache corruption to me...possibly.

The lowdown:

All 10 of my Yosemite iMacs are on identical 2013 or 2014 hardware. All Macs are imaged from an identical 10.10.1 or 10.10.2 deployment image.
All Macs are bound to the same AD (with Managed Mobile cached accounts). None of the Macs are using FV2 or any disk encryption. Firewalls (ALF) are enabled on most iMacs but not all.
None of the Macs have Wi-Fi enabled \- they all use copper Ethernet. No Brew or 3rd-party low-level stuff in /usr. No VMs. No BootCamp.
No 3rd-party drivers other than some HP printer stuff (from Apple's blessed SUS)

I have almost 300 Macs in production \- good thing most Macs are running 10.8 or 10.9!

Speak of the devil!

It JUST happened to me during a power blink as I was typing this post (freaky!). I now have 10+ more production 10.10.1 and 10.10.2 Yosemite Macs in boot limbo \- right this very moment. I was hoping 10.10.2 fixed this issue, but I can confidently confirm that 10.10.2 did NOT fix the issue.

Epilogue:

OK, so me and my team have figured out 2 ways to fix this based on suggestions.

Option 1:

Force a reboot (press and hold power button if needed)
Boot into Single User Mode (Command \+ S)
Run fsck -yf as needed
Reboot
Zap PRAM 3+ times

There is some confusion if zapping PRAM should be done first or last. We now think last is best.

Option 2:

(from Allister's post @ https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/)

From the recovery partition (or target-disk or single-user mode, deleting the following directories has sometimes been enough:

rm -rf /Volumes/Macintosh\ HD/private/var/db/BootCache*
rm -rf /Volumes/Macintosh\ HD/Library/Caches/com.apple*

Reboot

He optionally mentions running this too:

defaults write /Volumes/Macintosh\ HD/Library/Preferences/com.apple.loginwindow.plist DSBindTimeout -int 10

I am not doing this step on my production Macs yet, but I do have it applies to some of my IT Macs.

If need be I suppose I can add this command to my DeployStudio final setup script.

Option 3:

Call a priest and request an exorcism.

Editorial rant:

Apple is delinquent regarding this matter. This issue goes back several months ( first heard about if from a Desktop Tech here who saw it once back in October 2014). I'd call it a critical issue.

OS X 10.10.3 where are you?

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

EDIT:

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

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

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

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

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

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

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

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

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

Thanks @joecurrin

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

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

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

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

Like