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