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.

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

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

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

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.

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

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.

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

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.

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.

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

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

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

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.

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

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

@chrisw, you do what?

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!

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

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.

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

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.

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

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!

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

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