I am testing the Bootcache jettison fix posted by @chris.hotte][/url as well and I am seeing the same results as @joecurrin][/url. After forcing a power down it initially hangs at boot but after rebooting again it boots fine. I tested with both 10.10.2 and the 10.10.3 beta.

Other than the fact that I have installed a beta this is a fairly "clean" setup in that I installed only a base OS just for the purpose of testing this issue. There is no third party software and no extensive customizations other then to enable the Remote Desktop client and bind to Active Directory using our standard binding script. Contrary to other reports I can consistently reproduce this issue on a year old MacBook Pro with an SSD drive.

Edit: I should have mentioned that I do not have FV enabled on this MacBook Pro used for testing.

My distribution method is to copy a file that I get onto the client computer in user space via a centralized rsync server repository that updates every boot. The script is copied by a daemon that I trigger from the login window using a customize version of DeployStudio's Finalize.app.

The method really doesn't matter so long the file you get in there is clean. Best to test and debug it prior to deployment. If its not executing properly, sometimes adding -x to bash can sometimes shed some light.

Example bash script:
--

#!/bin/bash -x
bash commands
bash commands
bash commands

@chris.hotte

Also, tried configuring /etc/rc.installcleanup with no success.

@chris.hotte][/url][/url][/url][/url

I can't find any trace of the rc.server executing. I can't tell if its working.

For troubleshooting & QA purposes, shouldn't the output and comments contained in the rc.server script be displayed when booting into Verbose mode?

Likewise, shouldn't the standard output generated by OS X at boot also be written to a system log in /var?

#!/bin/bash -x
/bin/echo **
/bin/echo BootCacheKludge Beta 1.0 - Chris Hotte 2015 - No rights/blame reserved.
/bin/echo Dan added this for testing the OS X Yosemite boot hang issue on 02-11-15.
/bin/echo Remove rc.server once this issue is resolved by Apple Inc.
/bin/echo See JAMFNation forums for more info. /usr/sbin/BootCacheControl jettison
/bin/echo ***

My environment: We do not use FV2. All Macs are bound to AD - but with no UNC homedir paths are enabled.

You know, I've not been able to locate the console logs, either from single user or loginwindow - etc for quite some time. I'm guessing its not been properly enabled in syslog-ng or whatever apple has elected to use these days. For things like that I really do prefer a good linux distro for the package management, documentation and source code. *sigh*

But you should be seeing your echo'ed output verbose boot console. Hold cmd-v on startup for verbose or issue:

nvram boot-args='-v'

Oops, don't forget sudo. Pardon me, I live in root.

http://www.cnet.com/news/boot-argument-options-in-os-x/

Would the rc.server fix cause "1st-boot actions" to fail because the fix is blowing away any data in the BootControlCache?

Like say...DeployStudio workflow data that is postponed until 1st boot?

So, FWIW, I tried this again because I was curious.

I took an OS-only, clean install 10.10.2 system. All I did was bind it to our AD (well and I configured it as an ARD client and enabled root...). 6 hard reboots -- 6 failures to boot.

Using ARD, I pushed an /etc/rc.server file to that computer.

These permissions:
-rw-r--r-- 1 root wheel 129 Feb 12 14:18 rc.server

These contents:
host-143:etc root# cat rc.server
#!/bin/sh
/bin/echo BootCacheKludge Beta 1.0 - Chris Hotte 2015 - No rights/blame reserved.
/usr/sbin/BootCacheControl jettison

host-143:etc root#

And 6 out of 6 *subsequent* hard reboots -- the system boots up.

This is on an older MacBookPro6,2 (8G RAM 2.5Ghz i5). I guess YMMV. But for me, it's night-and-day -- *especially* on old computers.

For those of you who say this isn't working: Are you giving it enough time to reboot?

There's a difference in *not* having this kludge -- where it never boots up -- vs having the /etc/rc.server file where it can seem like it might still be stuck -- but will eventually kick through and boot up.

@maser Yes, I just tried again and the progress bar stays at about 25% for 30 seconds to a minute then slowly proceeds to 50%. After an hour at 50% I think I have given it plenty of time to boot. :-)

After I do another force power down and reboot again it boots fine. The properties and contents of my file are below:

tesmac:~ testadmin$ ls -la /etc/rc.server 
-rwxr-xr-x  1 root  wheel  168 Jan 30 15:39 /etc/rc.server
testmac:~ testadmin$ cat /etc/rc.server 
#!/bin/sh

# This file was created by IT Services to prevent the OS X 10.0 Yosemite hang at startup on Active Directory bound Macs.
/usr/sbin/BootCacheControl jettison

Permissions are slightly different on the file, but maybe put a blank line *after* jettison?

I dunno. I was skeptical, but it works here.

For those having issues with packaging it up, I've put a signed installer PKG here:

http://www.hammen.net/downloads/yosemiteboothangfix.zip

The PKG (which you can decontstruct/inspect with Composer) just creates the /private/etc/rc.server file with the BootCacheControl jettison command in it.

If included as part of an imaging configuration, you may want to ensure you've selected the checkbox to "Install on boot drive after imaging" in the Options tab of the Info tab for the package inside Casper Admin.

When Apple releases a fix, you should be sure to remove this file from any 10.10.x system that has it installed.

@ johnklimeck

Has 10.10.3 fix this issue? I've been putting off the upgrade for the time being.

NDA says you can't talk about pre-releases. However given that I personally have not downloaded or viewed any part of it in any form - I can state that the consensus thus far stated in this thread has been an equivocal NO. As of yet, it does not.

@maser Tried the exact same permissions and a blank line at the end for the heck of it. I even added an echo command and I am still not getting the same results as you.

So rather than being anecdotal about it, as with my previous testing, I did 15 tests each of logging into a local admin account (while the Mac was bound to AD) and logging into an Active Directory account. I thought I would try both types of accounts just to see if there was a difference in behavior. Also, since this MacBook Pro normally takes about 10 seconds to boot successfully I only waited about a minute which gave it plenty of time get to the 50% mark and hang.

I also noticed another clue in that when it boots successfully the mouse cursor shows up in the upper lefthand corner right after the progress bar hits about 10% but when it does not successfully boot the mouse cursor never shows up.

I did not find any difference between logging in with the two types of accounts. Each failed 46% of the time. I also noticed that 13% of the time it hung for more than one reboot before it would finally boot successfully, and in one case it hung for a total of four reboots.

I also tried modifying my rc.server file as follows to see if I could log whether or not the BootCacheControl jettison command was happening every time.

#!/bin/sh

# This file was created by IT Services to prevent the OS X 10.0 Yosemite hang at startup on Active Directory bound Macs.

/bin/echo "IT_Services_BootCacheJettison"
/usr/bin/logger -t "IT_Services_BootCacheJettison" "Jettisoning the BootCache..."
/usr/sbin/BootCacheControl -vvv jettison | /usr/bin/logger -t "IT_Services_BootCacheJettison"

Unfortunately nothing showed up in system.log so this may be happening too early in the boot process for logging services.

I would say that its way to early for logging.

When debugging weirdness I use

echo This is a test &>/private/tmp/testoutput.txt

I can confirm that the Chris Hotte fix worked on 10.10.1 macs but is now back again and affecting macs running 10.10.2 :(

Did you re-apply the kludge/patch of /etc/rc.server? The update may have pulled it.

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:

#!/bin/bash

if [ -e /etc/rc.server ]; then echo "<result>Exists</result>"
else echo "<result>Does Not Exist</result>"
fi

It would be nice if the update had fixed the problem rather than trash the workarounds people have been using!

Yeah, I hear that! Bet they will drag their heels on the opendirectoryd update until 10.10.3 too!

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

Great thread!

@chris.hotte

What hardware have you ran your fix on? We haven't had any success with our Yosemite shipped Air's and Mini's.

@mwmc

Older Mini's, older iMacs. A batch of Yosemite shipped iMacs and a couple Yosemite shipped MBP retinas. I've tested success on the Yosemite Shipped MBPs. I don't have any Yosemite shipped MB Air's or Mini's.

FWIW 14D87h
MD5 (/usr/libexec/opendirectoryd) = 48e66dd75000feb31d66e889870fb9ee

But hey check out the new Photos app.............

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.