Yosemite Macbooks stuck at 50% boot (Progress Bar)

[ctopacio01]

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!

[bwiessner]

Is anyone rolling the 10.10.3 in production? If so how are you doing this with imaging?

[dgreening]

No, no I am not rolling 10.10.3 beta anything into production. ;)

[mm2270]

Uh, yeah, its still beta, not a final release. I'd hope no-one is crazy or desperate enough to roll it out in production yet :)
Even when its final, you can bet that sucker is going to go through a lot of internal testing before we roll it out. I'm concerned it will fix one thing and break something else! In all seriousness, Yosemite has been one of the biggest headache OS X releases we've seen in years. So many problems with it. We have several open tickets with enterprise support that we're still working through of stuff that just flat out broke with this version. Apple's quality of their releases is really slipping.

[EliasG]

any update on the 10.10.3, is the fix in the next update?

[psherman]

I can confirm that I have six brand new Mac Mini's with the same issue on 10.10.2. It happens every time when the power is cut by accident.

[Knight]

Did the rename apple.loginwindow.plist fix, and it worked fine. Only thing was that it listed an new user at login Window called Casper, with root user password for access. Curiouser and curiouser!

[bountyman]

@Knight, the Casper account 'was' probably an hidden account like it should be. apple.loginwindow.plist stores such settings. By removing this file (or renaming it), it uses the default values and therefore your Casper management account now shows up at login window.
Just my 2 cents.

[emily]

Just installed Dev Center 10.10.3 on a VM and it reports opendirectoryd is build 382.20.2. Since I saw 382.20.1 mentioned previously, I'm guessing there has been active work on this. Which is a good thing methinks.

[Howard]

This has happen to me many times and booting to safe mode then just rebooting once more normally worked for me although it doesn't alway boot to safe mode on the 1st reboot. It would sometime still boot 50% of the way trying to get to safe mode so sometime I had to reboot twice at max.

[BruceLM]

It's good to hear 10.10.3 solves this. At the same time we have three machines with this problem and none of the various workarounds, the rc.server hack, the cache purge, the DSBind timeout, etc., none of them work. All we can do is move their data to a new machine to get them going again.

[emily]

I've been getting around the rc.server fix by logging in with a local account, then unbinding and re-binding to AD with the "Use UNC path from Active Directory to derive network home location" disabled. Works like a charm in our environment.

[alexforsyth]

Except @emilykausalik, you won't have access to your Windows Server network home with your approach - so it's not really a viable fix in every situation!

[emily]

@alexforsyth right, which is why I said it worked for our environment. :) We don't issue network home drives for users anymore so it's a fix for us. Ideally it wouldn't be an issue in the first place, but at 300+ comments on this thread…

[dstranathan]

@emilykausalik

To Clarify, are you implying that rebinding to AD is proactively avoiding the Yosemite boot hang issue, or is it resolving the boot hang issue on previously-affected Macs?

I'm asking because all of my Yosemite Macs are bound to AD, but none of them use the "Use UNC path from Active Directory to derive network home location" option.

[mm2270]

If you disable the "Use UNC path from Active Directory to derive network home location" setting, you can still have users home shares mounted at login with a LaunchAgent that runs a script to first check for a valid connection to your domain controllers, then queries AD for the user's home share (SMBHome) and uses that to mount their share for them. If the script can't connect to AD it just exits silently. This gets around the issue of hangs at login.

The Apple AD plug-in really should be handling this problem much more gracefully rather than locking up the OS while it struggles to connect to something it can't. But since Apple really can't give two darns about Macs and AD and can't seem to spare a developer to actually make it work right from day 1, we're left with crafting our own workarounds. At least 10.10.3 will finally fix most of these cases. Wish they'd release it already so we can start testing the final version and deploy it.

Also, @BruceLM - Are these affected Macs using FileVault 2 encryption? Are they also using Active Directory accounts to log in?
If so, you may want to take a look at my post here (from further up this thread) to see if you're getting stuck at the invisible dialog, like we were. We were also seeing the rc.server fix address many, but not all cases, until I found the information here on JN about this invisible dialog popping up due to the user's OriginalHomeDirectory key in their AD account.
Removing the OriginalHomeDirectory key from an AD cached local account has helped quiet down the remainder of these cases, along with the rc.server fix, which helps clear stuck boot cache files.

[emily]

@dstranathan For every machine I've done this on so far, it fixes the issue (meaning, resolves it for pre-existing machines exhibiting this behavior). I've changed the Directory Binding settings in our JSS environment going forward, too, and so far no new users have reported it as a problem.

This is definitely going to vary from environment to environment. YMMV, etc.

[Sierra_Bob]

When our AD Server went down due to UPS failure, my Mac Pro wouldn't properly shutdown. Unfortunately, I had to power cycle the machine. When rebooting, the Mac got stuck at the infamous 50% point. Numerous attempts booting and frustration later, I fortunately found this post.

I booted with the help of an external Mac OSX bootable SSD with Micromat's Tech Tools 8 onboard. No hardware issues, so I pressed forward with the Finder equivalent of (from above):

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

and rebooted... The Mac Pro came right up.

Thanks to those who blazed the trail before me - I only lost a few hours this morning!

[donmontalvo]

@Sierra.Bob you can also boot into Recovery HD and run those commands.

[chriscollins]

10.10.3: https://support.apple.com/en-us/HT204490

Addresses an issue that could cause Macs bound to an Active Directory server to become unresponsive at startup

[dgreening]

HUZZAH! Awaiting the release of the Combo and the Full Install (from App Store).

[rstansifer]

Halle-freaking-lujah!

[mm2270]

I'm also interested in this bit from the enterprise section:

Fixes an issue installing a configuration profile for 802.1x with EAP-TLS

We've had a lot of strange issues with our 802.1x profile not working correctly, or in some cases, not working at all on Yosemite, despite appearing to be set up correctly. It would be great if this update improves the reliability of those profiles.

[emily]

54 mintues to download. Yikes!

[jhalvorson]

@emilykausalik check your network cables for kinks. OK, maybe I am a bit too giddy about this release.

[laurendc]

@mm2270 same here - anything to improve our 802.1x profile with 10.10 would be excellent.

Also noting this part from the Enterprise section which would be great if the update improved this function as well:

Resolves an issue where folders from a DFS share point might "disappear" when viewed from the Finder on some Macs

[pchang]

whoa dang! 54 minutes!? I'm glad our firewall caches these updates! :)

[mm2270]

Not surprised on the 54 minutes to download. This has been a hugely anticipated release. Its the first point release for Yosemite that holds the promise of making 10.10 actually work reliably instead of the turd its been so far. My guess is everyone out there that's been waiting for this hit the download button as soon as it popped up :)

[dgreening]

Still no combo or updated full install. Hrmmm

[rstansifer]

Also remember we're fighting all the normal end-users who want to play with the new Photos App. It's just like every other Apple release: their servers just slow to a crawl, no matter if its OS X or iOS.

Just business as usual.

[dstranathan]

14d131 in da house, yo.

In my initial testing, the 10.10.3 update (the delta update from the Mac App Store), did not pave over the /etc/rc.server configuration.

I haven't tested the stand-alone Combo update yet. But I assume they all behave the same.

if [ -f "/etc/rc.server" ]; then
rm -rf /etc/rc.server
fi

[dgreening]

Yeah, nor did the existence of rc.server cause me any issues in upgrading using the Combo. I excluded 10.10.3 from the rc.server deployment policy and made a new one to remove it for 10.10.3 clients only.

[NightFlight]

You should try a 2MB DSL that's shared. I'm firewalled from the App Store servers... so I have to go this route. If I lean in close I can hear the banjo picking away each bit as it comes down.

[dstranathan]

On related note...

Does anyone know if OS X Yosemite 10.10.3 (build 14D131) will "unify" all current Apple Mac hardware, including the newly-announced 2015 super-duper thin MacBooks?

[kirkmshaffer]

Not sure about the new MacBooks - but our basic 10.10.3 image from AutoDMG works on a brand new 13" MacBook Pro Retina, and brand new MacBook Air. Previously They were using their own forked versions of 10.10.2.

[dstranathan]

@Shaffer Does AutoDMG work with the new 10.10.3 image? I am currently seeing a "Installer is newer than update profile" warning with AutoDMG 1.5.3

[bentoms]

@dstranathan you'll be fine, the author is updating the update profile currently.

[kirkmshaffer]

@dstranathan Yeah - I saw that, too but decided to give it a shot. Everything went through just fine. I'm guessing it has more to do with finding available updates (like newer safari, security updates, etc) than the main OS. My impatience paid off... this time :)

[bentoms]

geez, you impatient lot.

[donmontalvo]

I'm more interested in iOS 8.3 (wireless CarPlay).

I can wait for the dust to settle for 10.10.3. :)

Don

[Poseiden951]

Took less than 20 minutes to download. Started the AutoDMG process and went home.