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/
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.
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.
@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.
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.
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
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.
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.
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.
@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?
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.
+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.
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?
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
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.
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.
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.
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?
we have non-FV users experiencing this. Though we got around it by doing a cmd+v (verbose boot seemed to work).
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.
@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.
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.
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.
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.
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.
