Skip to main content

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!

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?


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


@rstansifer

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.


@rstansifer @calumhunter

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


Discourage AD, in an enterprise... HA! best thing i've heard all night


If you have AppleCare Enterprise and have experienced this, by all means open a case. Apple fixes bugs based on number of affected users. I'm sure it appears that the number of affected users is low...


@RobertHammen
no enterprise support contract here :(


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


@RobertHammen

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


For those using /etc/rc.server workarounds... make sure you append /usr/sbin/BootCacheControl jettison to the file if it exists. Most clients will not have it, but anyone that is using OS X Server.app will already have an /etc/rc.server with server tweaks.


@RobertHammen][/url is correct.

Radar, radar, radar. https://bugreport.apple.com

Currently we prioritize fixes by knowing how many customers are effected. If you've not alerted us to your situation, file a Radar and ensure your SE knows so we can increase the impact scores of bugs.


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.


Has anyone been able to confirm or deny opendirectoryd love in 14D87p? (Public Beta, no NDA)


opendirectoryd is still at build 382.0 on 10.10.3 Public Beta. <sigh> apple...


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


I am seeing build version 381 for < 10.10.2 or lower - the Beta Build is showing version 382. I am currently testing with 10.10.3 bound to AD. I will keep the thread posted to the results.


quick test - - -10.10.3 fails......


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.