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.
Hey @mklos look at @chris.hotte's post again above the code block. He boots into single user mode then uses nano to create a rc.server file at /etc/ and then puts the script in that code block in and saves it.
That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun - but something in there helps to identify the code is executing during a verbose boot.
You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point.
Not much else for it.
Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.
That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever! But to be fair most releases get pretty good around X.X.8. Then its time for the next one. *sigh*
That pretty much summarizes it. If you have a remote box, that presents an issue. Such as helping someone on the phone. You can direct them through the steps. Obviously the echo command was just me having a bit of fun - but something in there helps to identify the code is executing during a verbose boot. You can also have a remote user attempt many repeat many hard boots until they get to the gui and use terminal to add the /etc/rc.server script by hand, or you can remote in at that point. Not much else for it.
Okay I'll just keep an eye on it...like I said hopefully Apple fixes this issue in 10.10.2. It sounds like their well aware of the issue from reading around support forums.
That being said I've pretty much said the same thing about every new release. 10.5, 10.7 being pretty exceptional... and not in a good way. If I could, my vote would be 10.6.8 forever!
If I remember correctly, wasn't 10.6 mostly an under the hood OS update? Not many new improvements/features but just code cleanups, fixing issues with the OS, etc. Basically setting the OS up for future updates and squashing all the little bugs that annoy us users. Maybe Apple needs to do this again. They could stand doing the same thing with iOS but thats a different topic for a different time.
@chris.hotte thanks for posting about /usr/sbin/BootCacheControl jettison command.
Can this be setup to run as a logout hook? As that would be ideal as it could be turned off in future from the JSS as a policy if 10.10.2 fixes these startup issues with our Yosemite users.
Unless this is a permanent command that has another command to turn it off?
@chriscollins good point, so setting up a policy to run this command once a day at startup, login and check-in should cover any sudden loss of power from the client.
This way it's easy to remove this command from clients once (and hopefully) 10.10.2 addresses this bug.
What does everyone think?
@frank if you're using the rc.server workaround with the BootCacheControl jettison command then there's no need to anything else for now. Regardless of whether the Mac is cleanly powered down or hard powered off that command will be called every time the laptop boots! That's why it's a good workaround/fix until Apple get their stuff sorted.
Once Apple come out with a correct fix for this issue you should be able to safely remove the /etc/rc.server file from your client Macs (not Mac OS X Server) without any harm and they will revert to their standard boot process. In our environment i've used Composer to take a copy of the rc.server file (created with nano) and package it in the correct location. We've pushed it out to our Macs as a "once per computer" deployment - Make sure you do your testing first of course though!
Once Apple do their fix we'll likely remove it with a simple script similar to:
rm -f /etc/rc.server
Hope that helps!
What @mkremic][/url said.
In regards to the testing. Be thorough! If you were to mass deploy and somehow manage to trigger a freeze during boot in the /etc/rc.server script (I don't know how... but if you did) it will lock boot on every machine with no hook for recovery. Meaning you would have to manually touch every machine and boot into single user mode to undo.
I call that sort of error a bad day.
i used @chris.hotte][/url 's method, tested it many times and it worked well.
thanks for your workaround mate!
We'Re using Deploystudio/munki in our company, so i created the rc.server file on my local mac and created a dmg file with the command munkiitem from munkitools.
i mass-deployed the dmg with munki on every mac here.
worked without problems and the problem seems solved.
if apple do their fix i will just deploy a script like @mkremic][/url said.
A colleague and I have spent this afternoon in my labs recreating the issue (bound to AD, 10.10.x, hard power off) and have had 100% success on over 40 cumulative hard power offs using @chris.hotte 's suggestion.
This has definitely saved our bacon in the staff environment, the labs however i'm lucky enough to have hardware that will still take 10.9.5 so i'm going that route for the time being.
One thing however, I had 0% success when using single user mode and running the command manually - it would only work when inserted into an /etc/rc.server file - which I find a bit odd. Cheers again.
I will add that we have been provided a test fix today from the apple rep thats working on our case. Initially after running it on an example machine that could reliably reproduce the boot hang, it looked to eliminate the issue and even make the machine boot up a bit quicker. We have now deployed the test fix to our 30 macbook test cart of 10.10 machines as well a few one off 10.10 machines we have in a library. I need to update apple on the results of the test fix as the day progresses.... Out of 4 "fixes" or workaround they had me try, this is the first that appears to be successful...
We have implemented Chris' suggestion with 100% success.
I created the rc.server file in /etc and captured it with composer.
I then created it as a .pkg and deployed to our test machines, then finally our production machines.
This has been a great thread. Looking forward to movement on an official fix from Apple.
Great work everyone.
I'm having the exact same problem, I've been with OS X Yosemite for a while now, (since Christmas) and only a couple of days ago this problem occurred. I've had my MacBook Pro for almost three years now, with no problems at all. Went to Apple today and asked them about this issue and apparently my hard drive is busted and it needs to be replaced? This doesn't sound right, as you guys are having this exact problem. I'm not expert on this stuff, and would greatly appreciate if someone could take me through step by step on how to fix this problem. I read above that chris.hotte found a potential solution to this, but had no idea where to even start. I've been without a computer for three days now, getting quite annoying.
Thanks for you time,
Let me just say that I am not optimistic that it's in the latest beta released today. If you have access to the latest beta, check the date/strings on /usr/libexec/opendirectoryd.
Knowing Apple's typical development cycle for Yosemite updates, this patch is pretty late in that cycle for integration with 10.10.2.
Perhaps it will be released as a standalone update that will be integrated with 10.10.3.
I've followed Chris.Hotte's suggestion by doing the following:
/bin/echo BootCacheKludge Beta 1.0 - Chris Hotte 2015 - No rights/blame reserved.
When we loaded it, the actual Mac was no longer on the domain. Is that supposed to happen if your Mac was previously on the domain?
I wanted to report that installing the rc.server hack via the JSS on a 10.9.5 client (AD bound, FV2 encrypted) and then upgrading the machine to 10.10.1 (via Self Service) produced a 10.10.1 client with the rc.server file intact in /etc post-upgrade.
Ideally we will want to deploy the rc.server file to 10.9.5 clients prior to their upgrade to 10.10.1. Based on my testing it looks like this will work. Anyone else care to confirm on their end?