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!

[Kmitses]

I had the same problem with workstations with file vault.... looks like it is a know issue and that method is valid.... check out this article....

http://www.macissues.com/2014/10/27/filevault-bug-makes-yosemite-pause-or-hang-at-login/

[alexjdale]

If the systems are bound to Active Directory, they are possibly trying to authenticate the user and getting stuck. Turning off wifi would force them to use cached credentials.

We just put a full stop to Yosemite deployments as a result of a few different Active Directory-related issues.

[gburgess]

I've seen this issue as well on my own machine. I saw success by rebooting the machine into "Safe Boot" mode and then restarting the machine normally in case you wanted to try saving a few clicks.

[ctopacio01]

@Kmitses We do not use FileVault on our district machines.

@alexjdale Our machines are bound to Active Directory but we cannot get to the log in screen. Just the apple logo with the progress bar.

@gburgess Will try this out with the next MacBook that has the same issue.

[jon_mohar]

I have had this happen twice on a 10.10 AD bound Mac Mini, no filevault, with Wifi disabled due to wired network. It hasn't done it since having the PRAM reset.

Had a similar issue when restarting a 10.10 FV enabled laptop went to black screen after the Apple boot logo disappeared. The user could see the mouse cursor, but nothing else. Using ARD to remote into the machine, the user's session was active with the "Your computer restarted because of a problem" dialog. Clicked Ok, and user could immediately see their session on their end. I restarted the machine initially via ARD as I was troubleshooting an instance where the machine restarted automatically.

Now I'm in a similar boat with Alexjdale, due to the crashing/autorestart of Yosemite.

[pbenham]

I've seen this 4 times in the last 2 weeks.
Rebooting into safe mode has worked for me.
Next time I see one I'm going to note the time and then go back and comb through the logs to see if anything jumps out - or maybe reboot into verbose mode and see if that show where the machine is getting hung up.
By any chance are you all using Sophos Anti-Virus on your machines that you are seeing this with? I know our version of Sophos is not yet at 9.2.2 which they recommend for OS X 10.10 (https://www.sophos.com/en-us/support/knowledgebase/121510.aspx) - we're still on version 9.1.8. Just a hunch.

Oh and no FileVault on our machines with the issue and a mix of laptop and desktop wi-fi/ethernet.

Paul

[emily]

I've had issues with users upgrading to Yosemite (with and without FV2) and the progress bar screen hanging. SMC and PRAM resets fix the issue for our environment.

[mpebley]

Had similar issues and I ran into a problem with unsigned kernel extensions that were being used on 'upgraded' machines (not fresh imaged).

Run this in Terminal, will take a few mins.
system_profiler SPExtensionsDataType>~/Desktop/kexts.txt

Open the resulting txt file and locate any line where "Obtained from: Not Signed" Those resulting kext had to be removed. I found 2 old Canon BubbleJet USB drivers that was causing out problem. Once removed the hanging boots disappeared.

[jconte]

I have had the same issue on MAC mini's without filevault. resetting the pram worked for me. WiFi off, McAfee installed, all clean images-new builds, all bound to AD.

It has been sporadic, about twice out of 15 images. If it continues to happen I will open a ticket with TAM.

[ctopacio01]

@pbenham][/url No sophos on our machines.

Tried SMC/PRAM resets and did not fix the issue in our environment. I still have yet to try Safe Boot on one machine I am currently working on.

Anyone have the problem reoccur (hours/days) after the Safe Boot fix?

[ctopacio01]

Something to add as well... On our machines, the background shows white with an apple logo and a progress bar stuck at 50%. Background never turns gray and cursor never shows.

[cotten]

+1 to this issue. We ended up wiping the machines and starting fresh. In each case they were bound to AD and were yosemite upgrades. We use a .local domain for AD which needs needs to be manually specified in the DNS search order. I noticed it was getting stripped in successful upgrades, not sure if its related to this.

[haircut]

This has happened at least once with every machine I've upgraded to Yosemite in our environment. For some, it's happened multiple times.

Booting into single-user mode and running a filesystem check will usually allow the machine to boot properly on the next attempt. Sometimes, booting into safe mode then rebooting normally will allow the OS to load.

Based on other suggestions online, I've verified that each machine is not attempting to load unsigned kernel extensions.

Other notes:

• Models: 2012 MacBook Pro, 2013 MacBook Pro, 2014 MacBook Pro, 2013 iMac, 2014 iMac
• Bound to AD, though issue happens both on and off network
• Waited 20-minutes to 72-hours for boot to complete normally
• Happens on both FileVault-encrypted and unencrypted machines
• I haven't yet received any Yosemite machines straight from Apple, so all these problems have occurred on computers upgraded from Mavericks
• No Sophos here

I've also had to halt all additional upgrades until we can determine if this is a Yosemite bug or some other problem, only a problem when upgrading from Mavericks, or some problem with AD-bound machines.

Any additional variables we can explore?

[spraguga]

What I found so far, this may also apply to non-encrypted machines.

If the "Use UNC path from Active Directory to derive network home location" is checked in Directory Utility when an AD account is created then you cannot login to a Yosemite encrypted machine off network.

Uncheck that box, recreate the AD account, add the account to FV users, and you can login off network fine.

More here:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

[endor-moon]

We are putting off our Yosemite deployment plans because of this problem. Sure wish Apple would fix bugs that affect large-scale deployment in a big hurry.

[paulnz]

Seeing this behaviour on 10.10.1 across iMacs and MacBook Pros. Booting into safe mode and then restarting seems to be the fix for now.

[chriscollins]

I know some have said they tried this and it didn't work but every machine that has had this problem for us, deleting the "OriginalHomeDirectory:" attribute for the AD mobile account with dscl has resolved the issue permanently.

[jtol]

Hi Chris
I have a machine that I upgraded from Mavericks that has this issue. At the moment when I try and search for that attribute it says attribute not found. I am in the Directory editor looking under Viewing: Users in node /Local/Default to see if I can find the attribute to then remove with DSCL

What command did you use to remove the attributes?

[ImAMacGuy]

we have non-FV users experiencing this. Though we got around it by doing a cmd+v (verbose boot seemed to work).

[emily]

I've only had one Machine (in-place upgrade from Mavericks) that was not recoverable with a PRAM reset. Apparently it was just an OS issue because when I finally sucked it up and wiped/reinstalled the OS the machine is working totally fine. Sigh.

[chriscollins]

@jtol

Usually I do this over SSH because in our case the issue is with the user's login completing but the OS is up and running even though it looks like its actually frozen because the 50% progress bar is stuck on the screen.

I run ```
dscl . -read /Users/<user> OriginalHomeDirectory
``` to verify if the user has the attribute which again in our case they always do when this issue happens because there were some machines that were manually bound a long time ago by some of the PC techs and they weren't paying attention to the checkboxes in Directory Utility so this attribute would get created.

If the attribute is there, then I run ```
'dscl -u <admin username> . -delete /Users/<user> OriginalHomeDirectory'
``` Then just tell it to reboot.

You can do this through Directory Utility I just do it this way so we don't have to boot into safe mode when I am helping another tech fix the issue.

[Kaltsas]

We have some departments that have purchased new mini's that require 10.10. I am starting to see this issue more frequently.

There appear to be two separate issues that present in a similar fashion.

? An encrypted macintosh that is upgraded to 10.10 may experience a hang during the boot process. Reseting the PRAM/NVRAM resolves this issue.

? A 10.10 or 10.10.1 Macintosh that is AD bound that experiences a forced shutdown or an unexpected power failure will consistently hang on boot.

I can consistently replicate (and resolve) the issue with safeboot or Single User Mode fsck. However the issue keeps reoccurring in the wild. I struggle to believe that all these systems out there are ALL experiencing improper shutdowns but I can only replicate the issue in the office by pulling the plug or a 4 second power button hold. It seems like there is some combination of sleep settings that may also cause the issue but I haven't been able to figure it out if there is. It just seems unlikely that a dozen Macs a day are seeing improper shut downs.

[bigchief_ch]

Same problem here on a Macbook Pro 15' mid-2012. Boot stuck at 50%, impossible to boot in safe mode, checked hdd, reset pram, everything but no luck. It was working again only after reinstalling the system (whithout erasing data).

I did some tests and found that the problem on my Macbook is due to the update called "Canon inkjet printer software update" version 3.1

As soon as this update is installed the Mac refuse to boot.

Note that this Mac is part of an Active Directory domain and the HDD is not encrypted.

Hope it will help somebody.

[csheridan]

I've been following https://discussions.apple.com/thread/6606429 about this same issue. In our environment it's been units logged in to AD accounts (local homes, not roaming) that have lost power (intentionally and unintentionally). Mostly users staying logged in to AD bound machines and the machines going to screen saver with the "Require Password" option set, thus requiring a hard power down of the machine for the next user.

I've taken steps to make sure the "Require Password" option is disabled, and am watching the above apple discussion.

[rhysforrester]

Chiming in; 10.10.x labs (machines bought with Yosemite on them), bound to AD, no wifi on, accounts deleted at logoff, no UNC path set.

If an AD user is logged in, and a machine is hard powered off it will stick at ~50%. If verbose mode is used it will show that after getting an IP address the freeze is happening immediately prior to en2/en3 entering promiscuous mode.

If the machines are hard powered off when not bound to AD, or are bound and a local user has logged in, then there is no issue.

I've seen a mixed bag of results with single user mode, pram resets etc. Currently I have 3 machines that I locked up last night and none of the suggested fixes have managed to pull them out of their boot lock state.

For our area at least, I think we can safely assume this problem exists around AD and mobile accounts. I am however more than a little curious about the implementation of Samba3 with Yosemite, when Samba2 hit us it caused no end of issues around network drive mounts and network printers.

[rhysforrester]

Thankfully i'm able to move my labs back to 10.9.5 (late-2013 iMacs), tried all the same lockup methods and no issue.

Unfortunately(?) we'll be staying with Mavericks until such time as the AD issues surrounding Yosemite have been corrected.

[daz_wallace]

One possibility to add weight to the built in plugin being the issue. We are not having this issue at all when using the Centrify Express free AD plugin.

Hope that might help some of you guys out if you need 10.10

[benshawuk]

Just to chime in here as I've been extensively testing this in our environment, in case it helps anyone:

We run a .local domain (legacy reasons) and use the Apple AD plugin for binding (with mobile accounts).
In this scenario, an unclean shutdown causes the boot issue every single time without fail.
The single user mode "rm -rf /Library/Preferences/OpenDirectory/" fix resolves the problem every time.

As soon as the machines are unbound from AD (and the settings/prefs trashed etc.) I cannot reproduce the problem on forcing an unclean shutdown.
I'm also now having success with the Centrify Express plugin (cannot reproduce the issue following an unclean shutdown).

(I should have learnt my lesson really: this must be about the 6th OS X release that has introduced problems with .local AD domains and the Apple AD plugin. I naively thought that from 10.6 onwards .local AD plugin problems were ironed out!)

[daz_wallace]

One other thing I have yet to try, as suggested as a possible cause by @bentoms (thread https://jamfnation.jamfsoftware.com/discussion.html?id=12901#responseChild75864) is disabling core storage and see if this affects the replication of the issue.

This can be done without reimaging the mac using 'diskutil cs revert [Core Storage UUID]'.

Darren

[Kaltsas]

I have an open ticket with Applecare Enterprise Support. It is a known issue that has been reported to the product development team with no ETA for a fix. The procedure that has worked every time for us and has been the recommended procedure for temporary resolution is as follows in Single User Mode.

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

Honestly, I don't expect a fix until 10.11. Maybe Apple will surprise me but the lack of movement on our open case doesn't fill me with cupcakes and kittens.

[daz_wallace]

Thanks for the info @Kaltsas

I'm guessing by the use of 'temporary resolution' in your post, a killing of the power brings the fault right back?

Darren

[Kaltsas]

That is correct you can easily recreate the problem. The first boot after the reboot command in SU takes a while but they consistently boot.

The Support Engineer I spoke with indicated they believed something in BootCache.playlist is getting corrupt in this scenario on a directory bound macintosh but was unable to provide further details. We gave them an estimated count of potentially affected machines, which I believe gets sent to the product team to help them prioritize internally. This is why I don't believe we will see a fix anytime soon. There are other bugs that affect way more systems *cough wifi*.

I think I have some users that are 4 second smothering their mac at the first sign of trouble and giving themselves grief. We also have several conference rooms that we just unbound because the issue kept reoccurring, I think there is some sort of power issue in those rooms but I couldn't sus out what it could be. The only repeatable trigger is force it off/pull the plug.

[haircut]

@Kaltsas Would you be willing to share the enterprise case number with me? I do not have enterprise support, but my regional engineer (who claims this problem doesn't exist and is unreported) wanted to reference a case number so he could "add impact" to the case priority. I can't speak for him, but he may be able to add impact or at least a comment of "I have a customer with another 50 machines affected by this" if you can provide the case number. Thanks!

[chrisw]

Just my 2 cents...we had the same issue. A couple with in place upgrades from Maverick and even a brand new Macbook purchased with 10.10. Resetting Pram (as recommended by the Apple Genius) worked but not consistently. I ended up reseating my member and that seemed to resolve the issue for now.

[jasonh]

Since it's only a corrupt cache causing the problem, would disabling this kext prevent the creation of the cache and prevent the problem from recurring?

/System/Library/Extensions/BootCache.kext

Not in a position to test this right now but curious if anyone has any luck with it.

[mpebley]

I have had luck with the upcoming 10.10.2 builds fixing this issue for us. Hopefully it will be released soonish.

[Kaltsas]

@bmwarren][/url][/url I'm not at my desk but I will get you our case number as soon as I can.

*Update*

Case number should be 490421.

We actually purchased an enterprise contract because of this issue. I had been pressuring my boss for a support contract for a while but having an actual game breaking issue that needed resolved greased the wheels as they say.

[csheridan]

@Kaltsas - Awesome! Thank you. My most consistent fix so far has been single user removal of caches, but I wasn't even thinking of bootcache.playlist. Here's to hoping for a fix soon!

[spowell01]

We also purchased an enterprise contract with apple for this specific issue. Our case # is 485446, and their last suggestion was,

Thanks for the update. We do have another workaround available that I would like for you to try. However, please be advised that the argument is the time to wait for the Directory Server to bind before continuing login. The default is 60 seconds. So if you entered 10, the delay would be at most 10 seconds. You may run into problems where you don't get password expiration because you aren't allowing enough time for the system to connect to the AD server before continuing the log in.

1) Launch Terminal

2) Execute the following command:

sudo defaults write /Library/Preferences/com.apple.loginwindow DSBindTimeout -int <seconds>

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.