Yosemite Macbooks stuck at 50% boot (Progress Bar)

[ctopacio01]

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!

[acdesigntech]

Apple's NDA on this issue is BS. There's a HUGE problem, its well documented, it's known by engineering, they even have a fix for it, and yet they're pulling this NDA crap. Just release the damn fix already.

[acdesigntech]

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.

[kirkmshaffer]

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.

[Abdi]

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

[andysemak]

NDA

[khurram]

while restarting keep pressing the Option key

[womby]

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.

[johnklimeck]

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

[NightFlight]

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

[johnklimeck]

Sure thing,

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

[Aristotlejones]

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

[mlaundrie2015]

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.

[johnklimeck]

10.10.3 = :)

[joecurrin]

@chris.hotte

This is what our file looks like: Nothing special.

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

[Kaltsas]

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.

[bwiessner]

@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

[joecurrin]

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

[dgreening]

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.

[WUSLS]

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.

[joecurrin]

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

[maser]

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?

[joecurrin]

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

[NightFlight]

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

[WUSLS]

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? :-/

[NightFlight]

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

[dgreening]

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

[spalmer]

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.

[NightFlight]

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

[joecurrin]

@chris.hotte

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

[dstranathan]

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

[NightFlight]

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/

[lehmanp00]

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?

[maser]

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.

[maser]

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.

[spalmer]

@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

[maser]

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

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

[RobertHammen]

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.

[#39]

@ johnklimeck

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

[NightFlight]

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.

[spalmer]

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