Yosemite Macbooks stuck at 50% boot (Progress Bar)

ctopacio01
New Contributor

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!

423 REPLIES 423

davidacland
Honored Contributor II

@mpebley we've seen it with the following configuration:

  • 10.10.1
  • FileVault switched off
  • CoreStorage enabled
  • Joined to AD

Is that the same as your 10.10.2 setup?

bentoms
Release Candidate Programs Tester

@davidacland, we can't recreate it. Difference is we're reverting to the standard volume format & partition.

@chrisw, you do what?

davidacland
Honored Contributor II

Certainly sounds like the core storage option might be a culprit (not much help for FV2 users). I'm wondering whether 10.10.2 is going to resolve the problem. The note from @mpebley would indicate that it might.

I'm assuming a typo from @chrisw. Made me chuckle though!

ImAMacGuy
Valued Contributor II

what about if you do a cmd+option+shift+esc?

chrisw
New Contributor

Oopppsss...I meant "memory". I am used to texting and it fixing my mistakes...

Thanks for all the posts regarding this topic. I didn't really know where to turn if the Apple Genius's don't even know.

jasonh
New Contributor

@spowell01

That had no change in the 50% boot issue we are seeing, so i then tried to unload the boot cache.kext as well as totally remove the kext file and reboot. Still able to get stuck at 50% if i force the machine off.

Does that mean you got it to behave by unloading then deleting BootCache.kext, but the stall would come back after a hard shutdown?

spowell01
Contributor

We have not had any luck getting the machine to behave. I ran the command to unload the KEXT file and then immediately deleted the KEXT file itself. As soon as i deleted the file, the screen on the macbook flickered briefly and then went to a black screen with only the current users login image(an eagle) displayed. I had to hard power the machine off at that point, and it got stuck at 50%. After multiple reboot attempts it finally made it to the OS, and i was able to reproduce the 50% hang by just forcing the power off again. I relayed this information to our apple rep and he informed me that they are fully aware of this issue, and on a weekly basis are pushing the issue with engineers in cupertino....I'm really hoping they can get a fix implemented before the public release of 10.10.2, but unfortunately I'm not expecting much.

It puts us in a tough situation, since we have moved away from overhead projectors to flat screen TV's in classrooms in conjunction with Apple TV's. The airplay connectivity improvements in Yosemite are what we really need to make our new solution work, but with the lingering boot issue there is no way we can upgrade our teachers yet. Currently they are sticking with Mavericks and utilizing splashtop with their ipads & macbooks since the ipads are able to maintain a better connetion than the macbooks.

Joyia
New Contributor

I too am stuck at 50% of the boot loading bar. After installation of Yosemity, my 2009 MacBook Pro got stuck at 50% on the progress bar during the subsequent first automatic reboot. I haven't been able to make it to the login screen once since the 'upgrade'.

I have tried all the suggested fixes, incl. SMC & NVRAM & PRAM reset, booting into recovery mode, turning off Wifi, repairing permissions, checking & "repairing" the disk (although no errors were found), yet - upon rebooting via "restart" from the menue, (as well as warm start), still the same issue: stuck at 50%. I am uable to enter safe mode, since it also only leads to progress bar reappearing and getting stuck...

I eventually reinstalled OS X via disk utility from recovery mode, wich went through fine, but upon restart - same issue: stuck at 50%.

The only way I have been able to access the system since the 'update' has been via recovery mode (command + R).

- My MacBook is not part of a network, - so no likelihood for AD issues.
- The screen that gets stuck is not black with white apple but the light grey (pre-login) one with black apple and progress bar.
- I didn't have Mc Afee or any other AV prog. installed.
- There was no Homebrew or any of the other notorious culprits for endless installation lags installed.

I have an idea for possible reasons but am not command line savvy enough to resolve them from recovery mode:
- I have had a canon inkjet printer installed, the extensions for which had been mentioned as one reason for continuous stalls upon boot up.

- My 1TB hdd was partitioned into two partitions, which made it necessary to install Yosemity without FV.

- I did have quite a bit of content manually placed outside "users".

Any thoughts on it or suggestions how to deal with it from recovery mode - aside from a complete wipe and clean install - are greatly appreciated!!

Joyia
New Contributor

Reinstalled OS X another two times from recovery mode, which seemed to go through fine, shut off Wifi before final restart, - same result boot hanging at 50%.

I am out of ideas. ...and in a bad pinch: not been able to use my computer since three days! ..with only an iPod left to communicate.

Any hint of an idea is greatly welcome!

james_ridsdale
New Contributor III

@Kaltsas Your workflow worked for me...

/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm /private/var/db/BootCache.playlist
reboot

Thanks - I'll look to add this to our environments.

emily
Valued Contributor III
Valued Contributor III

Wow, that workflow from @Kaltsas totally worked for me too. On a machine that was the biggest thorn in my side for over a week (it was fine until FV2 was enabled, then it refused to boot).

external image link

Kaltsas
Contributor III

@emilykausalik The Applecare Support Engineer I have been working with indicated the issue appears to be more prevalent with FV2 encrypted Macs but I have had no issues replicating the issue on Non-FV2 encrypted systems. Most of our reports in the wild have been from unencrypted desktops (most of our laptops are encrypted). I suspect this is because desktops are more likely to experience a power failure than laptops.

bentoms
Release Candidate Programs Tester

Hi All,

Just an idea, but when writing AutoCasperNBI myself & @neil.martin83 kept seeing a hang on restart until i deleted the below:

/usr/standalone/bootcaches.plist

If you have Macs that you can test & recreate this on, can someone try deleting that file & then breaking the Mac again.

This is just a theory, so please don't do it in prod!

emily
Valued Contributor III
Valued Contributor III

Okay, so it worked once on one computer but now that one isn't working again. And another user is having the same issue and that fix didn't help. I tried @bentoms suggestion but didn't notice any change. I can boot into Safe Mode but can't get the OS to load otherwise. Super frustrating.

Kaltsas
Contributor III

With the steps I outlined after hitting reboot in SU the initial boot will take 3-5 minutes in my experience but it will boot. Tech Ops also reported one system to me that the outlined procedure would not resolve the issue yesterday. However they formatted the system before I was back in the office today, I would have liked to have access to the "broken" system to work with our support contact on it but it is what it is. I have not been able to replicate, following the procedure to delete in SU mode works every time on my test systems.

emily
Valued Contributor III
Valued Contributor III

Interestingly I just tried the "turn off Wifi in Recovery Mode" and that did work, so I'm starting to wonder if there's some kind of issue with FV2-enabled Yosemite Macs talking to the directory service while loading the OS/mobile profile. Since it bypasses (well, more hands-off than bypasses) the regular login screen I'm wondering if the sequence of events to check with the directory and load the mobile profile is busted somehow.

spraguga
Contributor

@emilykausalik][/url Yes, this has already been confirmed further up this thread, see my post.

And this thread:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

NightFlight
New Contributor III

I'm not alone!!!

Sporadically over our 1500+ systems on 10.10.1 loosing power at one site or the other would result in ~%25 machines not able to boot - stuck at %50. Annoying - for me. Costly for our business. Yikes!

I've isolated down to the Apple AD plug-in being enabled. Solid troubleshooting over the last couple days - using 3 iMacs on a power bar and hundreds of reboots later and many many many clean installs later, I know the following.

Clean install of 10.10.1 with nothing else.
Enable active directory and bind it.
Boots to %50 and hangs following a forced power failure.

dgreening
Valued Contributor II

Has there been any response from Apple on this? Does anyone have access to the betas of 10.10.2 to see if this is still an issue? I am aware that NDA prevents discussion of specifics, I am just wondering if anyone is testing this. We have not seen a single occurrence in our testing (AD 2008). Granted we have mostly portables...

mkremic
New Contributor III

Same thing happening in our environment with ~600 Macs joined to Active Directory. Can reproduce the 50% hang with a forced power off consistently.

99% of our Apple devices are laptops with AD auth and FV2 enabled. We've recently gone through a domain migration and of the few machines left over to migrate we haven't seen this issue with the Macs that aren't using the AD plugin to talk to the domain.

Tested following fixes to no avail:
- Changing AD authentication timeout values to low numbers (even 0) - as in this terminal line: sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>
- Unckecking the "Use UNC path from Active Directory to derive network home location"
- Installing 10.10.2 beta release on a Mid 2012 MBP made no noticeable difference unfortunately. A hard power off resulted in the same stuck loading bar.

Kudos to @Kaltsas, I tested your workaround to get a mac up and running again by booting into single user mode and it booted perfectly! Took a good couple of minutes but it came right. Good to have a consistent workaround until Apple get this sorted!

I'll keep searching the interwebs like we all are for possible workarounds. Hopefully something will come soon!

Hang in there people... we're all feeling the pain!

andysemak
Contributor

Just wanted to add my thanks for @Kaltsas workaround.

I raised a bug report with Apple with both the startup hang and the hang after login on a FV2 Mac

The bug for the startup hang was closed as a duplicate around a week ago but so far nothing for the FV2 bug.

NightFlight
New Contributor III

Can the boot scripts be edited to include clearing the boot cache playlist? It would slow the boot process down I suppose, but it would possibly kludge this as a fix.

NightFlight
New Contributor III

I've tried all of the above suggestions which did not provide a consistent fix. But this does.

On the client only, you may hijack the unused /etc/rc.server bash hook, eg single user boot:

bash-3.2# mount -uw /
bash-3.2# /usr/bin/nano /etc/rc.server

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

Boots are now completing %100 of the time.

Edit: We are now beta testing this workaround on ~50 machines.

Enjoy!

mkremic
New Contributor III

@chris.hotte we're trialling your fix on a few machines and it's looking very positive. We've had 3 so far that were refusing to boot and after going into single user mode and editing rc.server they've booted first go. I've got one test MacBook Pro by my side and can now consistently hard power it off and boot back up without it getting stuck at 50%!

Great work! Will continue to trial and post results.

timotei
New Contributor

@Kaltsas booting into single user mode and using fsck fixed it for me. Is there anything in particular that leads you to believe it is an issue with being bound to AD after forced shutdown?

dlondon
Valued Contributor

Hi,

So I guess the question to Chris Hotte and mkremic is whether you ran fsck when you were in single user mode to do the rc.server hack. If so can you see if it was simply the fsck that fixed the issue as it was for Tim?

Regards,

David

mkremic
New Contributor III

@dlondon, nope there was no need to run fsck to do the rc.server hack.

One of our users had told us he had hard powered off before seeing the loading bar issue initially as well which is what we had suspected. The handful of Macs we've tested on today have booted first go after applying this hack.

Cheers

mkremic
New Contributor III

Also I can safely delete the rc.server file when logged in the OS, and if I hard power off the Mac again it freezes at 50%. Just FYI in case anyone else is keen on testing this in their environments.

benshawuk
New Contributor III

Wow, top marks to Chris Hotte: I can confirm that fix is working perfectly in my environment.
I'm going to be deploying this to 50+ macs also over the next few days.

EliasG
Contributor

@chris.hotte so what would the script be to get this fixed? I am running into issues at our place. Also would this be a login script?

Thanks

ImAMacGuy
Valued Contributor II

I'm trying to write up a doc for our support guys around the country in case they run into this, but it still seems there's a fairly large discrepancy as to the actual cause - some say it's AD, some say FV2, I thought I saw somewhere that it has to do with the machine's having power failure, others mention Sophos...

I've seen a handful of these, but we don't use FV2 or Sophos, a power failure is possible but on laptops unlikely. We do use AD, but i've got a about 150 10.10.x machines on AD and I've only seen this 3 or 4 times.

Can someone summarize the issue and workaround?

rtrouton
Release Candidate Programs Tester

The best summary I've seen so far was posted yesterday by @Banks at AFP548.com:

https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/

Kaltsas
Contributor III

@dlondon Consistently in house I can replicate with the tried and true rtrouton method

Setup 10.10
Bind to AD
Login and pull power
Boot and it's hung.

No Casper agent, AV, no extras. It's an OS issue, confirmed and replicated by Applecare Enterprise Support. Sometimes rebooting a few times, zapping PRAM, fsck, and other diagnostic processes will cajole a system back to life. But that resolution is inconsistent.

Consistently the following procedure will fix an affected machine. This has also been confirmed and replicated by Applecare

/sbin/mount -uw /
rm -rf /System/Library/Caches/*
rm /private/var/db/BootCache.playlist
reboot

I have had one report from tech ops that this procedure did not work on a system but they formatted it before I was able to look at it. I suspect one of the techs did not follow the procedure exactly and it was not mounted as read/write.

I am going to be testing the @chris.hotte process and inform our Apple support contact of the effort.

NightFlight
New Contributor III
Hi, So I guess the question to Chris Hotte and mkremic is whether you ran fsck when you were in single user mode to do the rc.server hack. If so can you see if it was simply the fsck that fixed the issue as it was for Tim? Regards, David

I'm not running fsck during my tests. It will run on its own when the disk is marked dirty, or rather - not clean. Given that its run automatically after a forced power down when the file system is not clean - we can safely rule out fsck as a fix. You can confirm fsck runs when the file system is dirty with verbose boot.

NightFlight
New Contributor III
@chris.hotte so what would the script be to get this fixed? I am running into issues at our place. Also would this be a login script? Thanks

Are you asking how to distribute a copy of /etc/rc.server?

We don't yet have casper licenses for our workstations, so we don't use it to roll out fixes. Currently I use a daemonized rsync server configured with anonymous modules. See the rsyncd.conf man page. This distribution tool has worked for us for years without hiccup. So treating the rsync deamon as a repository we just sync whats needed for example on a login hook script as you suggested.

Ultimately, it doesn't matter how you distribute this command into /etc/rc.server. So long as you don't overwrite the file on 10.10 server. ;-) Note that you don't even have to mark it executable since its called by bash. I only noticed it yesterday because bash was throwing an error in verbose mode. Same goes for BootCacheControl. I guess that's what happens when you stare at an issue for a few days in a row.

joaquim
New Contributor

Adding my two cents and what worked for me:

Even after following all the suggested fixes above, the issue still persisted for me. I looked at the syslog once again but this time noticed a whole bunch of errors stating that it could not create var/folders. So I took the advice posted on an older Apple Support forum and created /var/folders manually. After reboot, system launched successfully!

Under single-user mode:

mount /sbin/mount -uw /
cd /Volumes/Macintosh HD/
mkdir var/folders
mkdir var/folders/zz
reboot

Link to forum post: https://discussions.apple.com/thread/4960066

NightFlight
New Contributor III

Sounds like a separate issue. I'm not encountering that. Maybe check your base image?

tnielsen
Valued Contributor

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

spraguga
Contributor

cscsit
New Contributor III

@chris.hotte I guess I'm not following your solution. Are you saying to boot to single user mode and perform the commands written in your original response? If I have a Mac thats already not booting I can't push commands to it, even with a login script because its not getting that far.

I'm confident it will work, I just need to better understand how to implement it.

Thanks!