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!

[mm2270]

Yes, we're seeing it happen a bit again (though not quite as much as before) since we started updating clients to 10.10.5. I fear this particular bug has resurfaced again. It was fixed as of 10.10.3 but now we are seeing it again. Ugh..nothing like reintroducing previously fixed bugs, eh? Thanks Apple!

[DraconicBlue]

We have been seeing some odd issues after one of the updates. All of our laptops are FileVault enabled and after logging through the FV prompt, the system sits there at about 30% of the loading bar.

We did some digging and found that something is removing the execute permissions from the root directory.

If you boot to single user mode and mount the drive /sbin/mount -uw / and then do a quick ls -lsa, you will notice that the root drive is listed as drw-rw-rw instead of drwxr-x-r-x.

We did a quick chmod 755 . rebooted the system and it seems to fix the problem.

It has been completely intermittent and have not been able to determine the root cause. Maybe 30 times out of 1200 10.10 systems.

[jrippy]

@JRossA could you expand on your answer a bit more? Which file are you looking at with the

#!/bin/sh
ls -als?

Are you looking at /Volumes/Macintosh HD? Are you looking at /. (The dot file)?

Thanks

[DraconicBlue]

It is the /.

[jrippy]

Weird. I have 10 computers currently experiencing the issue. So far I've looked at 2 of them and they both have the correct permissions on the dot file.

[jrippy]

After 2 weeks, I can confirm this is definitely an issue again. I am now reimaging my labs back to 10.10.4 and blocking the update to 10.10.5.
This sucks cause its a lot of unnecessary work and there are a ton of bug fixes in 10.10.5 but I have to have usable computers.

[NightFlight]

Huh. We haven't seen it at all with 10.10.5. Sure it takes a long time on first boot after the update, but thats expected. You did remove the Kludge after 10.10.3 came out right?

[jrippy]

@chris.hotte Yes. Once the problem was "fixed", we did fresh 10.10.4 installs and everything worked great. Until 10.10.5 came out.

[emily]

I don't think it's the same issue, at least from my experience. We have Macs that hang on the login for a good 2-3 minutes sometimes, but it's when the machine is attempting to authentication to the directory and the behavior just doesn't seem the same from what's happening here.

[Eleteipe]

Hello everyone

I have an issue with a machine that after a forced shut down gets stuck at 50% boot and then the screen turns black with only the cursor visible. I have tried everything posted here but I am still trying to find the correct solution. Do you have any ideas? The machine is updated to the las version of Yosemite.

[davidacland]

If you're running the latest version ofYosemite and have tried the fixes on this discussion, its probably a different issue.

It could be hardware related but have you tried re-installing OS X?

[May]

Hi all
i'm late to the party...

I've just started testing with FileVault on Yosemite and i'm finding that the auto login process takes around 70-80 seconds (off the network, i haven't tested on yet) I've tested a few suggestions from this discussion and it's definitely something that's happening during the Auto login process that's related to the Active Directory binding. Use UNC path from Active Directory to derive network home location is not ticked
and there is no dscl OriginalHomeDirectory key

What i've found so far:

Yosemite - FileVault - Auto Login Enabled - AD user login = 70-80 seconds

Yosemite - FileVault - Auto Login disabled - AD user login = 5 seconds
(/Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES) @mm2270 re your question, i do not get the dialog message you described “There was a problem connecting to the server "servername"

Yosemite - FileVault - Auto Login enabled - a local user login = about 5 seconds

Yosemite - No FileVault - Auto Login enabled - AD user login = takes about 5 seconds

Yosemite - FileVault - AutoLogin Enabled - DSBindTimeout -int 1 - AD user login takes 12 seconds
(sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int 1)

Does anyone know what the implications of lowering the DSBindTimeout interval are ? i'd rather use this as a work around rather than disabling the Auto Login.

[mkremic]

Hey @May , how far away are your Domain Controllers from the Macs you are testing on?

In our environment we were operating off DCs in different states and countries and this was dramatically slowing down the logon process. We ended up staging local DCs at most sites and this took the logon speed down from the 70-80 seconds you mention to a more respectable 25-30 seconds. Still not amazing but I haven't been able to push past that boundary.

If a DC locally isn't an option you could look at a Read Only DC but this has other implications such as password expiry times not being correctly retrieved and Macs won't see it as a RODC and will try and bind to it initially.

Your DSBindTimeout options is how long the mac will take to time out if it can't find a directory service. 10 is usually a good number to work with but it varies with each environment. 1 will log on quickly (as you can see) but may have issues contacting the domain for logon authentication... it's probably skipping a domain auth altogether and using the cached credentials on the mac.

Hope that helps!

[May]

Thanks @mkremic

The DC's are geographicaly close and it takes roughly 70 seconds to log in,
i've done some testing with the DSBindTimeout interval and 10 does seem to
be quick enough (about 20 seconds to login when offsite).

I've thrown together an EA so i we can see if its been set at 10 or not.

#!/bin/sh
if
timeout=$( defaults read /Library/Preferences/com.apple.loginwindow DSBindTimeout 2>&1 )

#echo "$timeout"
[[ $timeout != "10" ]]; then

echo "<result>not set</result>"

else

echo "<result>$timeout</result>"

fi

Cheers again for the guidance!

[davidhiggs]

Now seeing this in El Capitan OS X 10.11.3. Working with Apple to see if this is related to the Yosemite bug. The machines affected weren't upgraded from 10.10, they were clean installs.

Getting caught up on kauth

I'll report any fixes/workarounds.

[rdwhitt]

kauth external resolver timed out (1 timeout(s) of 60 seconds)

This has been a thorn in our side since 10.10.5 and is primarily happening in our high traffic public Mac labs. The behavior is also widely inconsistent which makes troubleshooting this extremely frustrating. I've been able to recreate the problem after upgrading from 10.10.5. to 10.11.3, but I haven't seen it on a clean install of 10.11.3 (yet). We've also been working with Apple and they have said it appears to be similar to the bug fixed in 10.10.3, but as of yet they do not know what is causing this in our environment.

I've tried the various work arounds found in this thread and others including:

Safe Boot
Deleting boot caches
Repairing disk and permissions from recovery
Reduce the login window delay timeout
PRAM and SMC resets

Generally I can get the machines to boot again with a PRAM reset but it will happen again on reboot. We also have to keep firmware passwords on these which makes it more irritating.

I'm currently considering voodoo or witchcraft so if anyone has experience in either of those fields let me know.

[davidhiggs]

@rdwhitt I feel your pain, you've described my exact situation and attempted remedies in an extremely high traffic mac lab environment. Nothing is working to bring them back to working order except re-imaging.

[davidhiggs]

@rdwhitt just wondering if your affected machines have SSDs or Fusion drives?

[rdwhitt]

@davidhiggs negative, these do not have SSDs or Fusion drives.

[cddwyer]

I had this issue many times during our company wide 10.8 & 10.9 > 10.10 upgrade plan. There was an easy but manual way to resolve that was putting the affected machine into target disk mode then running the combo update installer (10.10.5) on a working machine and pointing it to the HDD in target disk mode connected instead of the local drive as is selected by default.

This worked for me every time.

Hope that helps.

[kkt]

@davidhiggs have you had any luck figuring this out? We're seeing it a bunch on both iMacs and 11" MBAs now. :/

[Chuey]

@kkt Check out this thread here: Stuck on Startup

[davidhiggs]

I solved my issue! response is here

[jamesandre]

I've run into the same issue with Sierra File-Vaulted Macs that also use Time Machine. These Macs are not bound to AD.

The temp fix from @Kaltsas worked, which was -

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

The more permanent fix from @chris.hotte via @NightFlight worked too. Which I will use Composer to create the file to deploy via Jamf.

single user boot: bash-3.2# mount -uw / bash-3.2# /usr/bin/nano /etc/rc.server

Then adding the following to the file-

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

Thanks to everyone who contributed.