also, @joecurrin, thanks for the heads up that you are still seeing the issue even after applying the rc.server fix. We have not seen this issue here at our HQ, but in one of our remote offices that has statically assigned IPs for all macs (except on the imaging subnet, that's DHCP), they are seeing this issue consistently when moving a newly imaged Mac off the imaging subnet to a production network.

re: NDA - is there a parallel thread on the developer forums that anyone is using? I know it's not a great solution for here, but if we can do something there, maybe here gets the benefits.

So.. Who wants to test OS X 10.10.3 beta to see if it fixed this?

NDA

while restarting keep pressing the Option key

We're getting multiple issues here on several 10.10, .1 and .2 machines. Interestingly only the machines that have been imaged via Casper seem to be exhibiting this problem. Currently testing @chris.hotte's fix, and the safe boot/restart method. Looking through the 10.10.3 seed notes, it's all about the new Photo's app, nothing mentioning this issue.

I can no longer reproduce this boot hang on my lab iMac that I can always reproduce it on.

10.10.2, with no rc.server file. Force powered down and powered up multiple times and it always boots to the login screen, after installing a certain "10.10.x" (update) that we are not supposed to comment on.

Looks like it is addressed / fixed

@joecurrin

Can you post here or PM me a copy and paste of your /etc/rc.server?

When I was originally testing I had three iMacs on a power bar with no less than 15 forced power downs (x3=45) in a row with successful restarts constituting what I believed to be a working fix before I posted it here. We now have deployed to nearly 2K 10.10.2 machines with only the occasional continuance resolving into where the Kludge was not applied or removed for some reason. I currently have it added to my deploy studio workflow and scripts which execute when the login window comes up.

Besides, its a Kluge. No guarantee it will work for everyone. Just something to try and no support! That being said, I'd like to know why it may not be working for you.

@johnklimeck
Please issue the command: md5 /usr/libexec/opendirectoryd and post the return value here. There may have been a silent release.

Sure thing,

MD5 (/usr/libexec/opendirectoryd) = 48e66dd75000feb31d66e889870fb9ee

@johnklimeck so should I open an enterprise support case referencing the tickets here and get on the "NDA" bandwagon? I'm going to try Chris's fix on some machines this morning.

A little trick I used to get into a stuck machine was to boot into Single User mode, delete the .AppleSetupDone file, and reboot. On the reboot, the New User Assist starts, and it creates a non-AD account that I can use to boot the machine. Not the most convenient method, but one that was worked without issue for a week.

10.10.3 = :)

@chris.hotte

This is what our file looks like: Nothing special.

#!/bin/sh

# Credit to chris.hotte from jamfnation

/usr/sbin/BootCacheControl jettison

The MD5 hash of opendirectoryd in 10.10.3 dev preview matches what was in 10.10.1 and 10.10.2 (48e66dd75000feb31d66e889870fb9ee) and not the test version of opendirectoryd I was supplied by applecare engineering support. The replacement opendirectoryd completely fixes the issue in all testing I have performed. However the support contact is adamant it shouldn’t be used in production (and I honestly don’t know how it would shake out if I pushed it out, then Apple released the fixed version in an OS update)

I can still recreate the issue on 10.10.3 dev preview with the usual improper shutdown on an AD bound system. I have not noticed the behavior being any more “graceful” in the 10.10.3 preview. After triggering the bootlock issue I can delete the caches and cajole the system back to life.

Our Applecare contact does not know when/if the opendirectoryd fix that appears to be a permanent, Apple provided solution will be implemented.

@joecurrin

Are you using this as a startup script or how are you deploying this?

Posted Yesterday at 8:59 AM by joecurrin
@chris.hotte

This is what our file looks like: Nothing special.

#!/bin/sh
# Credit to chris.hotte from jamfnation
/usr/sbin/BootCacheControl jettison

@bwiessne I installed as part of our imaging configuration. So this file would be installed long before we encrypted. I also tried it to a system that was already encrypted as well. Both situations produce the same results. I didn't see anything within the forum stating this file needs to be activated or called upon. It was my assumption the OS automatically calls upon it. Correct me if I am wrong...

Did you create the file under single user mode using the directions and then go into /etc and capture it with Composer? You should not have to tweak the permissions in Composer, as the correct permissions are set when you create the file in single user mode. Thats what I did and it has worked well for me.

I am in the same situation as @joecurrin][/url. Does the file need to be called upon, or activated somehow?? If so, please share the details! Clarification is needed before I send a scathing email to AES.

@dgreening yes the file was created in Single User Mode. I then captured it with composer and doubled checked the permissions.

Weird -- I've tested this here and the presence of it on a laptop that will hang at hard boot will successfully boot every time (opendirectoryd patch not being in the discussion...)

@joecurrin][/url - what hardware are you testing against?

@maser I personally have tested the 2013 MacBook Air 13, 2013 MBPr 13. I am having techs test the other equipment for me. Oddly enough our 2013 MBPr 15 has acted fine. We install each OS on each machine and thoroughly test. Across the board we have been able to easily reproduce the issue with the patch.

@joecurrin

Nope, you got it. Its a bash hook (I assume, since you don't even have to chmod the /etc/rc.server file) that's called by the system to fire up the server scripts. Since its not used by the client it was just a very handy install point. There is also /etc/rc.installcleanup (or similar) I see barking out during every verbose boot and it likely could be used as well. However I suspect the latter script would be wiped by an update.

Hi All,

I am having this issue as well. I have tested on physical machines, and i am now testing it via a VM. I added the VM Mac OS X 10.10.2 to AD, enabled HomeFolder mount, and logged in as an AD user. Initial login had no issues seeing the home folder and was able to login without issue. Once I enabled FV2, rebooted, disconnected the network, I ran in the subject of this thread. I have tested @chris.hotte's /etc/rc.server on this VM with the same results I have gotten on physical machines. Nothing changed. Am I missing something in getting this file to be read/activated by the OS upon login???

Am I missing something in this picture? :-/

None of my tests include FV2 or FV as its not something we implement.

In my case (which is that this is working fine) we use FV2, AD, but with no UNC path enabled.