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!

[chriscollins]

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.

[NightFlight]

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.

[cscsit]

@chriscollins Okay I guess I did do it right but sometimes it boots and other times it doesn't. This only seems to be an issue if someone just holds the power button down instead of shutting it down naturally. I'll keep monitoring it. Hopefully 10.10.2 fixes the issue.

[NightFlight]

@tnielson

Don't install Yosemite, it's a giant turd. I realize this is not helpful to your problem, I'm sorry.

Pre-installs...
Business requirements...

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*

[cscsit]

@chris.hotte

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.

[emily]

Used @chris.hotte's suggestion and it totally fixed a Mac I thought was a goner.

Again:
external image link

[tnielsen]

I understand @chris.hotte. We do a thin image on hardware that only works with Yosemite... there will be no upgrading to it in any way, however.

For the record, I really like 10.9.5. 10.7.5 was my previous favorite. The almighty 10.6.8 as well, for SMB connections only.

[roiegat]

We just had a good success with @chris.hotte suggestion.

So would adding that rc.server script to all yosemite machines in /etc resolve the issue? Thinking about how to apply this widespread to prevent further issues.

[WatchtowerCaspe]

Safe Mode, Resetting PRAM, or fixing Disk Permissions does not fix the issue.

chris.hotte 's fix works great - /usr/sbin/BootCacheControl jettison

[jperelli]

@chris.hotte Could you tell me the exact steps you took. ie how to get into single user mode and what are the exact commands you ran in the terminal.

Sorry I am not very familair with osx and all of our AD bound macs have this issue.

[frank]

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

@frank I think the issue with that idea is that this happens because of a sudden power loss or a user purposefully doing a hard shut down which corrupts the cache. The chances of a user logging out THEN hard powering down or losing power is minuscule.

[frank]

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

[mkremic]

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

#!/bin/bash
rm -f /etc/rc.server

Hope that helps!

Cheers!

[NightFlight]

@frank][/url

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.

[pdpk]

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.

Cheers

[joecurrin]

Our configuration is 10.10.1 AutoDMG package
FV2 Enabled
AD Bound

We are seeing the issue and resetting PRAM/logging into single-user mode fixed it for us.

[rhysforrester]

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.

[NightFlight]

Great to hear.

As for the single user boot reason... I'm not certain - could be a timing/sequence of events issue.

[jhalvorson]

If you have access to AppleCare OS support or a TAM, be sure to open a case with them.

[bentoms]

I've seen reports of a supplied fix from Apple to some customers.

No idea if it'll be in 10.10.2 yet, & neither do I have the "fix" myself.

Just wanted to say, it appears to be coming.

[spowell01]

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

[haircut]

@spowell01 - Can you provide your support case number? Our engineer has still not responded and I'd love to provide him this info to see if we can get the fix as well, since and official Apple fix would be supported.

[spowell01]

@bmwarren

Sure, our current case number is 485446. I'm not sure if apple considers this a "fix" but more of a test. If this works as we seem to be seeing, then maybe they will implement this before 10.10.2?

[haircut]

@spowell01 Wonderful, thanks!

[jconte]

I received the pre-release fix today as well. It worked on the two machines I tried it on and do agree that the machines appear to boot faster. I will install it on my primary machine to see if anything else breaks.

[jasonh]

I don't suppose it's a set of commands we can try? I requested the fix as well in the meantime, in case it's a pkg.

[Kennedy]

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.

Cheers,
Gavin

[acdesigntech]

Any idea if that command can be ADDED to rc.server on a 10.10 server? I've got two mini servers running yosemite that have this issue.

[SamBoWick]

Hi guys, 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,
Sam.

[chriscollins]

I heard from an Apple rep today that apparently the fix that is being circulated is included in the latest 10.10.2 beta.

[RobertHammen]

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.

[andysemak]

just updated an MBA to 10.10.2 (latest beta), forced power off and it's hung

[yashy99]

hi guys,

I've followed Chris.Hotte's suggestion by doing the following:

1. Log in as single-user
2. Entered the lines 'mount -uw /' and '/usr/bin/nano /etc/rc.server' (hit enter)
3. Put the below into the nano editor and save it:

#!/bin/sh
/bin/echo BootCacheKludge Beta 1.0 - Chris Hotte 2015 - No rights/blame reserved.
/usr/sbin/BootCacheControl jettison

1. Reboot.

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?

Thanks
Yashy

[Kennedy]

We have not seen this issue and we've now rolled out to over 400 macs and counting.

Coincidence?

Cheers,
Gav

[dgreening]

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?

[johnklimeck]

I can confirm, that on OS 10.10.2 / 14C106a, this issue no longer occurs. Updating from 14B25 base / clean OS X.

Forced powered down this Mac like 7 times, boots up no hangs at all.

John

[dgreening]

Well that is certainty good news!

[spraguga]

@johnklimeck][/url Can you confirm that you are testing with an AD bound account w/UNC path checked during account creation and an encrypted computer?

[johnklimeck]

sure,

- Definitely bound to AD (via JSS Directory Binding)
- UNC path is Disabled (we do not use this derived UNC path, causes issues (question mark in dock)
- No File Vault