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!

[bentoms]

@kbach, whilst love sharing solution as much as the next admin.. you post is clearly in violation of Apples NDA & I'd advise you edit it.

[WUSLS]

Highly annoyed, and users don't understand why I won't push out OS X when they are released. I was even told by my engineer that he had seen success on JAMFNation with 10.10.2 beta. I tested, nope. Problem still there. Updated to public release of 10.10.2 and now the issue shows up on my mac. How about those Apples!!!! FACE-PALM INTO BRICK WALL!!!!

[azbikowski]

Pretty normal. Don't deploy Windows until Microosft releases the first Service Pack, don't deploy OS X until Apple gets to 10.x.3. I hoped Apple would get a 10.10 release without Active Directory related bugs, but I'm not disappointed that they didn't. 10.7 had issues, worked fine in 10.7.3. 10.8 had issues, worked fine in 10.8.3. 10.9 had issues, issues resolved in 10.9.3. Hopefully 10.10.3 will be the release I can roll out.

[hmghmg]

I have this problem only with computer have HDD disk. On MacBook Pro and iMac with SSD i don't have this problem.

[jcb]

I have seen people have success with a solution/workaround by chris.hotte but I don't understand the solution, how we would package it and deploy it.

Could anyone throw up a step-by-step on how to do this?

[RobertHammen]

1) create or edit the /etc/rc.server file
i.e. sudo vi /etc/rc.server

Insert this line in the file:
/usr/sbin/BootCacheControl jettison

Save the file. Double check the file ownership to be root:wheel, 644 permissions:
ls -al /etc/rc.server
-rw-r--r-- 1 root wheel 462 Apr 11 2013 /etc/rc.server

Open Composer, don't create a new policy.
In the Finder, click Go then select Go to Folder
type /etc into the box and hit OK.
Scroll through the list of files until you find rc.server
Drag it to Composers left sidebar, under SOURCES
You should now have a folder listing that shows /private. Expand it and it should show /etc. Expand it again and it should show only the rc.server file

Save this as a DMG or a PKG file. Upload it to your JSS using Casper Admin, then create a policy to deploy it to your 10.10.x clients. Upon a restart, assuming you edited the file correctly, it should work.

Hope this is helpful.

[lehmanp00]

I got this from an Apple rep. It has worked for us so far for this same issue. We don't use FV or OD, just AD.

mount -uw /
cd /Library/Preferences
mv com.apple.loginwindow.plist com.apple.loginwindow.plist.old
reboot

Edit: Forgot to add do this in Single-User Mode

[bentoms]

@lehmanp00, did that work?

[lehmanp00]

@bentoms

Tried it on 3 Macs that wouldn't boot. Stuck at 50% or so... and yes all 3 worked fine afterwards.

[bentoms]

@lehmanp00 nice thanks for sharing.

[jcb]

That is actually really helpful - Thanks for your help!

Really, thanks.

[maser]

@lehmanp00][/url

Does that removal of the loginwindow.plist file fix all subsequent hard-power-down reboots? Have you tried hard-powering down about a dozen times after doing this?

This issue will only show up if an AD-connected machine is hard powered off. It usually does not show on a machine with an SSD (or fusion drive), but will almost always show on a mac with a mechanical hard drive (iMac or older MBP...)

The *real* test for any of the above workaround is -- can you hard power-it off 10-12 times and have it boot up successfully each time?

The rc.server method appears to "solve" the problem, but I can't comment (without getting in trouble) about the opendirectoryd patch success rate being similar to the rc.server method. Really, I can't.

Any other suggestions have always been one-off suggestions that have yet to stand up to multiple hard-shutdowns.

[lehmanp00]

@maser

I rebooted 7x after the fix. All 3 Macs I fixed were Air's bought this summer. After 4 days so far no issues, however, I'm sure the users don't power them off much.

I did not try the rc.server fix.

[smitty1923]

@RobertHammen-Thank you for posting this! These steps are taken on the user's machine correct? I am new to JAMF/Casper and want to make sure I understand before I start poking around ;)

[maser]

@lehmanp00

As I thought -- I just tried your suggestion on my MBP -- and booting into safe mode and removing the loginwindow.plist file -- did not even allow it to reboot the first time after deleting that.

That's not a viable option. I think you got randomly lucky because you are doing this on Airs where the faster SSD doesn't usually show this hang problem that often, but deleting the loginwindow.plist makes no difference.

[lehmanp00]

@ maser

Absolutely could be. I honestly was skeptical at 1st because it seemed a little too easy seeing what other had to do in this post. So far I am not seeing this issue on MBPs here (cross fingers). However, I wanted to post the solution just in case it might work for others.

[maser]

My testing with a late-2011-era MBP is that if I hard-reboot it over and over (strictly to test this issue) it will successfully boot maybe 30% of the time. With the Air that I tested with, it reboots almost all the time (maybe 1 failed boot in over 20+ attempts).

This is testing without any of the fixes.

[RobertHammen]

@smitty1923 You can do this on each users' machine, or you can do this on an admin machine and follow the instructions to create a package in Composer/policy to deploy to all 10.10.x users. I would strongly suggest the latter approach.

[alexforsyth]

Does the Apple Enterprise fix seem to pretty reliably fix the issue then? Do machines require rebinding to AD afterwards?

[Kaltsas]

@alexforsyth Yes it appears to reliably fix the issue, no it does not require rebinding. However our support contact has no information as to when the product team will implement it. I fear it won't be until 10.10.3 which would be weeks if not months out. I am uncomfortable rolling out prerelease software that apple insists I not use in a production environment so I am reluctant to utilize it in the wild.

[NightFlight]

Does anyone have the capacity to reverse engineer the the Enterprise patch? At the very least run 'strings' on the new files. Even better is when the dev team forgets to remove the debugger info.

[alexforsyth]

Thanks @Kaltsas and fully understood!

[SGill]

I was stunned to discover in 2 test cases yesterday that the verbose startup (Cmd-V) allowed Macs affected by this to boot. Might have just been quirks, but if you're in a hurry, there ya go!

[Kyuubi]

Verbose mode didn't work for me. It still hung. The single user mode fix given by @Kaltsas worked for me like a charm. Props to him! Apple needs to get on this ASAP

[mkremic]

Is anybody having issues again with Apple's 10.10.2 release? I've had Chris Hotte's solution in for a couple of weeks now on 10.10.1 and it's been a life saver. Just had a couple of users coming across again now with the same symptoms and they're running 10.10.2.

[Abdi]

This happened on a brand new iMac binded only to Active Directory, no other software/configs installed.

Planning on testing 10.10.2, hopefully Apple has fixed this.

[WUSLS]

I am still seeing the issue on 10.10.2 bound to AD and encrypted. My own work mac Is being affected by this issue as well.

[aamjohns]

I've had the same problem with 10.10.2. But Chris's rc.server file fixes it. So I am able to deploy the upgrade as long as I put that rc.server file on the user's system. When this is fixed, I can delete that fie.

[WUSLS]

I have found that if I delete the key for the "OriginalHomeDirectory" I am able to reboot the machine, however we lose the convenience of having the homefolder shortcut in the dock. I am more annoyed that this has not been resolved since this is suppose to be a native function of the operating system. I will try Chris's rc.server file fix again. Annoyed that Apple has not produced a fix for this issue.

[spraguga]

@WUSLS Yes, we have already confirmed the OrginalHomeDir issue in this thread and this one:
https://jamfnation.jamfsoftware.com/discussion.html?id=12188

You can also create a new account without the UNC path to get around this.

Cheers!

[dstranathan]

Just wanted to chime-in with my observations, too.
Prologue:

My Desktop team bought (50) 2013 iMac 21.5" workstations for our 2014 summer Refresh. These are the second generation "thin" iMacs. The Macs arrived in July, but remained in Apple retail boxes until August where there were imaged with my 10.9.4 Mavericks production modular image (DeployStudio/NetBoot). 40 of the 50 iMacs went into production running 10.9 Mavericks last summer/fall.

The remaining (10) iMacs got pushed back due to other projects in 2014, so they didn't get deployed until Jan 2015.

By this time I had a production Yosemite 10.10.1 image ready, so the Desktop Techs re-imaged the new iMacs again, this time with my 10.10.1 Yosemite image.

According to the techs, the iMacs came up from the DeployStudio imaging process just fine once, and then the issue covered in this form post was discovered - it affected 9 out of the 10 Yosemite iMacs. Why (10) iMac is immune to the issue is beyond me. Weird.

Before I discovered this post, we tried the following things:

Rebooting - fixed 1 iMac. That was easy!
Zapping PRAM - fixed 1 iMac
Running fsck and/or Recovery GUI tools - fixed the remaining Macs
Multiple rents were required. Like a Vegas slot machine.
One of my Techs claimed that unplugging Ethernet at boot fixed 1 iMac too. One Tech here also swears by running fsck first THEN 3 PRAM zaps.

Total voodoo. Am I on an episode of "Mac Admin PUNKED Season 2"?

I did notice a few things:

The iMacs were all stuck on a light get and dark grey boot loader screen. After the Macs were "fixed" they started booting with the new, improved sexier black screen with white logo. Related? I dunno, but there is a pattern here.

When booting into Verbose mode, All the iMacs would all get stuck at the following standard output boot message: "promiscuous mode enabled succeeded" and other output related to Apple/Broadcom driver information. This was 100% reproducible. Sounds like boot cache corruption to me...possibly.

The lowdown:

All 10 of my Yosemite iMacs are on identical 2013 or 2014 hardware. All Macs are imaged from an identical 10.10.1 or 10.10.2 deployment image.
All Macs are bound to the same AD (with Managed Mobile cached accounts). None of the Macs are using FV2 or any disk encryption. Firewalls (ALF) are enabled on most iMacs but not all.
None of the Macs have Wi-Fi enabled - they all use copper Ethernet. No Brew or 3rd-party low-level stuff in /usr. No VMs. No BootCamp.
No 3rd-party drivers other than some HP printer stuff (from Apple's blessed SUS)

I have almost 300 Macs in production - good thing most Macs are running 10.8 or 10.9!

Speak of the devil!

It JUST happened to me during a power blink as I was typing this post (freaky!). I now have 10+ more production 10.10.1 and 10.10.2 Yosemite Macs in boot limbo - right this very moment. I was hoping 10.10.2 fixed this issue, but I can confidently confirm that 10.10.2 did NOT fix the issue.

Epilogue:

OK, so me and my team have figured out 2 ways to fix this based on suggestions.

Option 1:

Force a reboot (press and hold power button if needed)
Boot into Single User Mode (Command + S)
Run fsck -yf as needed
Reboot
Zap PRAM 3+ times

There is some confusion if zapping PRAM should be done first or last. We now think last is best.

Option 2:

(from Allister's post @ https://www.afp548.com/2015/01/14/when-yosemite-has-fallen-and-it-cant-get-up/)

From the recovery partition (or target-disk or single-user mode, deleting the following directories has sometimes been enough:

rm -rf /Volumes/Macintosh HD/private/var/db/BootCache*
rm -rf /Volumes/Macintosh HD/Library/Caches/com.apple*

Reboot

He optionally mentions running this too:

defaults write /Volumes/Macintosh HD/Library/Preferences/com.apple.loginwindow.plist DSBindTimeout -int 10

I am not doing this step on my production Macs yet, but I do have it applies to some of my IT Macs.

If need be I suppose I can add this command to my DeployStudio final setup script.

Option 3:

Call a priest and request an exorcism.

Editorial rant:

Apple is delinquent regarding this matter. This issue goes back several months ( first heard about if from a Desktop Tech here who saw it once back in October 2014). I'd call it a critical issue.

OS X 10.10.3 where are you?

[Abdi]

Haven't had a problem on 10.10.2. But, judging from your responses; I'll stick to 10.9.5!

EDIT:

I take back what I said, it's even worse than before. Back to 10.9.5

[RobertHammen]

@dstranathan - do you have AppleCare Enterprise? If so, open a case and get the opendirectoryd test fix.

[acdesigntech]

Hey, has anyone seen an issue when after adding @chris.hotte's fix, the non-boot issues comes back after moving the Mac to a different subnet? We're getting reports from one of our remote offices that this is the case.

[dstranathan]

@RobertHammen I do not currently have AppleCare Enterprise. Sounds like Apple is testing a fix, etc?

@acdesigntech We did see situations in which unplugging physical Ethernet during the hang state allowed some 10.10.2 iMacs to continue to boot. However, Im not sure if we ever moved any Macs logically - I doubt it. I didn't witness this, but co-workers did.

[joecurrin]

We tried @chris.hotte rc.server trick. This hasn't produced a consistent fix for us. The first time we will get 50% boot, we will hard reboot again and then the system will normally boot. If we hard shut down from a full booted os, we will boot to 50% again and then have to hard boot once more to get it back to fully boot state.

[joecurrin]

@acdesigntech we are still consistently seeing the issue with @chris.hotte's fix

[joecurrin]

@dstranathan Enterprise support is currently working with Engineering for a fix.

Just as a disclaimer for anyone working with Enterprise Support to keep interactions/patches quiet as we are all bound to an NDA.

[dstranathan]

Thanks @joecurrin

[alexforsyth]

Oh @joecurrin, that's a pity if true. Most other users on here reported consistently good results and I was rather relying on it for a suite of poorly iMacs on Monday!!