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.
The 10.10.2 update does indeed pave over the rc.server file (in that it removes it). I made an extension attribute to check on it's existence (or lack thereof) so that I can target those machines for re-application. Here it is:
if [ -e /etc/rc.server ]; then
else echo "<result>Does Not Exist</result>"
Chris Hotte: Yes, my management software automatically pushes the file out so it's definitely still there.
In fact I think I've resolved the problem: After an unclean shutdown the 10.10.2 macs do actually boot, but take quite a bit longer with the progress bar stuck around the middle (a few minutes or so). I think I was just being impatient and incorrectly assumed that "the boot problem" was happening again.
One other thing I noticed that I'm not sure has been mentioned here: The macs appear to need a reboot after the file has been deployed, before it takes effect. This is another reason why I've spotted some machines exhibiting the problem, despite having the rc.server fix applied to them (some of our users don't reboot for weeks on end).
Sorry for the "false alarm".
So I came across this today, even though we don't use FileVault by default, we had a new user with a pre-existing Yosemite Macbook with FileVault enabled. I didn't realise until the first reboot after setting it up.
Booting in single user mode and jettisoning the boot cache did nothing. Tried booting into recovery mode, and turning off encryption through Disk Utility, but even though the conversion status was "Converting" the conversion direction remained at "none". Tried booting it to target disk mode and plugging it into my 2013 Macbook running Mavericks, but it would crash my Macbook when I went to unlock the volume.
In the end, I plugged it into my test Macbook (2012 model running Yosemite) and did it through that. Conversion direction is showing as "backwards" and the progress percentage is going up. So I'll call that a tentative success for now.
What a mess.
Edit: Disabled FileVault successfully, but still had the same issue of getting stuck at 50%. Putting in the rc.server workaround fixed it this time (which didn't fix it when I had Filvault enabled).
Thanks for your suggestions, it saved me.
I've been skimming this thread for months. We have about 120 Macs running off of Active Directory. No FileVault (I loathe FileVault...working for Apple Retail made me hate that system with a passion) and running ESET Antivirus. However, our oddity is that the hang does not occur consistently. I've seen Macs that have yet to hang others that have already hanged.
For a time, I was able to CMD-V Verbose Boot and for some reason I couldn't figure out, that seemed to solve the problem. It didn't make any sense to me. I had stumbled upon it when trying to troubleshoot the issue.
Afterwards, I found that a Safe Boot and a Restart would solve about 98% of the issues and we never had a reoccurrence. Still, it's frustrating to have to deal with this issue at all.
So fsck is run during a Safe Boot...but my question is why would that be solving the problem?
FV isn't needed to produce the hang.
10.10+AD bind +hard power off = hang
very easily reproducible, with the exception that "some" new machines with fast SSD's don't always exhibit the problem
I would hazard a guess that fsck, safeboot and verbose mode are not doing anything to solve the issue and that the issue still exists, you just are not seeing the symptoms (ie the hang) on the hardware you have.
I have a vague recollection from OS X recert materials that Safe Boot flushes the boot caches, of course my memory could be at fault.
I've started seeing this issue appear in the last week, or at least similar symptoms, thought it seems to be further along in the startup process. The logs are giving me precious little to work with. I've tried the BootCacheControl jettison but didn't seem to have the desired outcome.
We have been experiencing the same issue. We have 180+ macbook Pro devices in our environment. So far it doesn't matter if the devices have SSDs or not, but it does require a hard power off or loss of power to cause the issue. A normal reboot will work most of the time until a hard power is done. Once the issue happens, even if you are able to recover it, it will continue to happen on every reboot. Wiping and reinstalling so far has been the only thing that fixes it completely (until another hard boot)
@tunecorpit, have you tried setting up the rc.server script as mentioned above on a machine *before* you hard power it off? For me this has resolved the issue
I'm aware of sites with 100 times your number of machines being affected. Apple's response to this is pretty appalling. I know they've been discouraging AD use for some time but come on guys
we do have an enterprise contract. I opened a case. Biggest waste of time ever...
The engineer had absolutely no clue about anything named opendirectoryd or anything even resembling that, or at least he claimed not to. But he WAS able to assure me this was their top priority. Yeah, right. If that was so then 10.10.3 would have been out weeks ago and this issue would be FIXED. But I'm sure Photos makes up for it.
That company's such a joke.
Apple schedules their OS and patch releases and does not deviate. The .1 will typically ship a month after the OS releases, the .2 update ships 2 months after that, ad infinitum.
What we should have seen was a separate standalone update (like the bash fix or NTP) that was eventually rolled into a future OS update. Not sure if the rumored opendirectoryd patch addresses the issue, or why it hasn't been released yet, but there must be a reason...
Apple is pretty good with metrics and customer numbers in general.
I'm sure Apple can extrapolate the number of Enterprise customers (or even SMB customers who have even the most basic AD infrastructure) and therefore come up with a ballpark estimate of how many Macs are currently unable to boot. Its got to be hundreds of thousands or possibly millions or Macs world-wide.
My stomach turns when I say the words "Unable. To. Boot." Kinda a big problem.
By the looks of Tim Cook's comments and publicized plans on Enterprise customers (including the IBM partnership etc), Id say Apple might be on the right track - at least compared to Steve Jobs leadership. I'm am cautiously optimistic.
At least I don't have to worry about bind my Apple Watch to Directory Services. Wait...Proximity-based Kerberos ticket granting via Apple Watch perhaps? Never mind.
For the record, the /etc/rc.server workaround has been working for me thus far.
If anyone has ever worked with AppleCare Enterprise, one of their standard questions is the number of systems affected.
This is a factor on how timely bugs are addressed and they do_not extrapolate the data.
So if only a handful of people report it, it remains unaddressed. Seem like a weak system? Yeah. But that's the way it presently is.
If you don't have AppleCare Enterprise, talk to your SE's or Sales reps. Tell them how you are not adopting Yosemite and/or not purchasing new systems until this is addressed.
Agree Apple under Tim Cook sees the enterprise as more of an opportunity (moreso than Jobs' "Eff these guys" attitude). But they aren't there yet and this is one of their Achilles heels. But we've drifted off-topic... I have implemented the rc.server workaround and it seems to work fine at multiple clients. No idea why it doesn't everywhere, but...
I rarely post unless I have some useful input and I have experienced this on such a small level, I haven't input anything prior to now. I hesitate even now, as it may seem like a red herring but.....
I have only 2 machines running 10.10.x, a test bench machine (iMac 21.5, mid-2011) for testing against internal systems and software (will NOT take 10.10 into production until .3 - or later) and my own personal MacBook Pro. Both have FV2 enabled.
The iMac is bound to AD and I have never had the issue-but have never had to hard reboot and haven't forced it for kicks.
My personal MBP (2 local accounts) is not, and never has been, bound to ANY directory service and I experienced this DAILY.
The cause of the "KP/shutdown/hang requiring hard reboot" was - every single time - accessing something that used Flash in a Chrome browsing session.
Logging into and out of another local account with FV2 rights would fix it until the next crash. Flash and Chrome have since updated and I have used an *ahem* unauthorized opendirectoryd fix and have not had a login hang since - even after forced reboots.
@casper100 I think your issue is a different problem to what this thread is reporting.
The problem i think the majority of this thread are reporting is very easily reproduceable
1. install 10.10
2. bind to ad
3. hard power off
4. reboot = 50% progress and machine is hung will not boot further.
I suspect that the fixed/patched opendirectoryd that you have also resolves other reported dns-related issues which i think is more the case your seeing where you are getting KP/system freezes ect ect
Hi all. I haven't chimed in on this thread yet, but since we started rolling out Yosemite in our environment over the last couple of weeks, we've been hit sporadically with this issue as well.
At first, we started implementing the rc.server fix posted by Chris Hotte above. In many cases this did seem to resolve the issue on our affected Macs, but not in all. We were still seeing cases of either total hangs (like leaving it for days at the 50% mark and never progressing) or very very long boot/login times.
Just today after doing some more testing we revealed something that I believe was mentioned either in this thread or another one here on JN. I can't take credit for discovering this since I recalled reading a post by someone that the theory was a hidden dialog is causing the hang to happen. (Edit: found the original post with this information: https://jamfnation.jamfsoftware.com/discussion.html?id=12188#responseChild77988) There is in fact a hidden dialog popping up that is causing many of our Macs to get stuck when the user logs in off the LAN. In our tests, we saw that being connected (wired) to the LAN bypassed the issue. Only when off the network was when we saw it 100% of the time.
We have FileVault 2 enabled on our imaged Macs and what's happening is, OS X Yosemite is NOT respecting the Mount Home share and Use UNC Path settings that are both Disabled. It is still attempting to connect to our AD user's home share points when off the network and coming up with an error dialog. Problem is, this can't be seen normally when FV2 is enabled.
However, here's what we did to reveal it.
After getting into an affected Mac, we ran:
sudo defaults write /Library/Preferences/com.apple.loginwindow DisableFDEAutoLogin -bool YES
This forces the regular username & password fields to appear after unlocking the drive at the FV2 login screen. Once we did that we rebooted the Mac and kept it off the wired network and finally saw the dialog which stated something along these lines:
There was a problem connecting to the server "servername" The server may not exist or it is unavailable at this time. Etc, etc.
with an OK button. Important note here is that the dialog appears BEFORE the desktop appears, not after. So until that button is clicked, the login will not proceed into the user's Desktop. This same dialog is coming up when the DisableFDEAutoLogin is set to False as well but it doesn't show up, which causes it to hang at 50% indefinitely. Pressing the Return key once the hang happens allows the Macs without that FDE setting turned on to continue the login.
I'd love to hear from others also seeing this if they can run the defaults command above and see if they reveal the same error pop up after turning that setting on. As I said, although the rc.server BootCacheControl command has fixed many cases, it isn't working all the time, and we think this is why.
Just to add, we updated our Casper DP's.. 1st restart post update was fine. Some hung on the 2nd or later restarts.
Deploying a modified rc.server file as per @chris.hotte's directions seems to have worked.
We took a DMG of the original, then made the changes to the original & deployed that. The copy of the original DMG wil be redeployed to these servers once YoYo is not a nogo.
I'm sure that having access to diverse emoji affects a far greater number of people, but come on. Fatal showstoppers like this have to qualitatively jump to the front of the line, or what is it exactly that we are all sitting around doing with our professional lives? They even have a patch for it already! Pretty deplorable and sadly confirms the worst biases against Macs in the enterprise.
Why, as Spock once said "the needs of the many outweigh the needs of the few (or the one)", And Apple needs Many dollars more than they needs a few. They are probably all rolling around in shock trying to figure out how Microsoft released the tablet/keyboard surface thing that snaps together and runs a real OS with normal Apps for about the same price as an iPad and trying to figure out how to release a touch screen computer without looking like windows copycats to worry about a few enterprises or schools authentication issues. Lets complain about the cheap wifi chipset they use in these computers so that if you use bluetooth and wifi in an office environment with multiple Access points your computer spends its whole day trying to figure out what 2.4GHz AP to connect to, or no more locking port for an office environment on your laptops, while we are at the complaint game. Again the normal average 99% of the users wont notice or complain or leave for anything better so Apple still wont care.
They have slowed down the hardware, dumbed down the OS so it looks faster on slower hardware, while trying to add so many cool new features what do you expect
For those with profiles using AD credentials go ahead and try this:
Go to system settings>>users>>Unlock>>Click the account you have issues with>>Network account server, delete the current network account server
We disconnected the user from the domain, made a new user name called test admin, rebooted and was able to login (only have to do this if you are remote)
Once you are in the profile, re add the user to the domain, reboot and it should work.
That is what we figured out was going on for some reason when they moved to crazy networks at hotels and such their mac would never boot, only into safe mode.
Try it out and see how it goes.
So far, the /etc/rc.server workaround has been working for my Macs...until yesterday.
My Desktop techs had a support call for MacBook Air that had succumb to the boot hang issue. After further inspection, I determined that the /etc/rc.server file was in place. The fix/triage consisted of the usual voodoo: PRAM zap, boot into Recovery Mode, repair disk permissions, etc.
My environment consists of about 75 Macbook Pro retinas and Macbook Airs that are:
-FileVault -Hangs at login
Booting to single user mode and running a fsck only fixes it temporarily in my experience. All of the other usual "voodoo" works for a while then back to square one as well.
Running a machine with 10.10.3 beta and it seems to be better, but no guarantees.
unbinding from AD seems to have fixed it. After I rebound it to AD the problem came back....Hope this helps some.
I have a macbook pro.
I have tried the Pram Nvram Smc resets. No luck
I also did the disk utility verify and repair. no luck on that
I tried the sin-user mode I tried the fsck and mount tricks. no luck
I even tried the turn off wifi and reboot. no luck
Can anyone come up with any ideas.
This happened to me last night actually.
If it helps I did delete the IPMonitor in usr/library/systemconfig by accident
and I DO have sophos .
I did not backup so wiping clean would be harsh on me