MBP (Early 2011) gets stuck on this screen on startup. Why?

Posted Apr 17, 2012, 3:26 AM UTC

Posted Apr 17, 2012, 3:26 AM UTC
Damn that sucks... best of luck my friend.
To verbose mode with you!
I came across this when updating Lion. Have to force shutdown and restart it. For some reason there's supposed to be a dialog box and its waiting for you, but I feel its behind the background.
What's happening here is that your OS can't load up the Login Window process or something related to it. This could be due to a bad preference, wrong permissions, or a system plug-in is hanging up your system.
When did this start happening? Will the login window eventually show up? Have you tried Safe Mode (holding left shift at boot)? Have you tried resetting the P-RAM?
Waitwaitwait, you tell me that my advice is bad and then you say that "wrong permissions" could cause this and resetting ACL's is not recommended? Do you have any idea what you're talking about?! How could system-level permissions cause the issue in the loginwindow process, but user-level ACL's could not?
I'm sorry dude, but you have no idea what you're talking about.
Repairing permissions != resetting ACLs.
Edit: Resetting ACLs is just bad advice.
Double-edit (high score!): Don't be sorry. Stand by your convictions. If you're going to claim that I have no idea what I'm talking about, you might as well do that blindly and go the full monty and not apologize about it. For all you know I could be an Apple engineer. Or not.
Resetting ACL's is great advice and if you are at all an Apple engineer (we could play the "swipe my badge" game to see who wins that battle. Or not.), you would know that resetting ACL's is a recommended troubleshooting step in this instance for ACMT's.
Coming from you, who typed
I just meant modifying permissions and ACL's from Terminal scares the hell out of me, since I don't have a good grasp of the command language. Basically, anytime I type the word "sudo," I make sure that I know exactly what I'm doing before I hit that enter button.
an hour ago, yeah, I'm not going to take what you say about the system seriously. And badges? I don't work at Apple, mate (or wherever you thought "badge-swiping" was relevant). It's cute that you thought of me as an ACMT though. <3
The loginwindow process is failing for some reason.
First thing to try is booting into Safe Mode. If that doesn't work (and assuming that you're the only user on this computer; if not, skip to the next step), the next step would be to boot into your Lion Recovery partition and click Utilities>Terminal>resetpassword and then click enter. Select your MacintoshHD in the next window that pops up, select your user account and click the Reset ACL's button. Once it finishes, restart.
If that doesn't work, try a different user and see if you can get in through there. If you can, it's likely that you have some startup items that are causing a login issue. Have you recently installed new software?
Last but not least, if all else fails, you can reset the PRAM in case there's some cache error that's preventing the loginwindow process.
Thanks! I've done the PRAM thing before and it seemed to help. I will try those other things when I get home tomorrow.
Do NOT listen to this person. There is no way to know if "the loginwindow process is failing" without actually being there. The only good advice is Safe Mode and resetting PRAM. After that it's bad advice.
I'm sorry that I have to keep commenting on each of your comments, but the level of wrong that you have in each one of them requires me to do so. A failing process does not mean that it's not going to work in the future...it means that the process is failing to load, or "the loginwindow process is failing."
Yes, I can tell you with 100% certainty that the loginwindow process is failing if the computer is hung on the linen backdrop, although I cannot tell you what is causing it fail without being there.
No. You can't. It could be a plug-in or something that's trying to finish before loginwindow tries to run.
I don't see how resetting ACL's and the password are going to help Login Window come up at boot.
If the person can't get the login prompt, how are they going to check a different user account?
When you can't get to the login window, this should be your steps:
Please think about the advice you're giving as some of your steps have irreversible effects.
I said nothing about resetting the password and resetting ACL's can, in fact, resolve a login issue, specifically when the user has automatic login turned on, exactly as I wrote. In Lion, you can only reset ACL's via the resetpassword command, hence the reason he has to enter that.
Also, if you read what I actually wrote, I said in the preceding paragraph, "...assuming you're the only user on this computer; if not, skip to the next step"
And renaming your root level library prefs is not a fix; it's a troubleshooting step for someone who would know what to look for next. Telling this person to rename this folder is the same as telling me to turn off my car to fix the problems with my engine. Sure, the problem will not persist when the car is off, but that sure as hell isn't going to solve my problem.
If you were at all familiar with how ACL's functioned for automatic login, resetting them would be one of the first things that you would troubleshoot. Please do not lecture me about "thinking twice" for "irreversible effects" when it is not only a proper troubleshooting step, it's RECOMMENDED troubleshooting step.
tl;dr- grow a clue.
eta: if you boot into Safe Mode, you're running an fsck that would repair faulty kernel extensions, so recommending that you run an additional fsck after booting into Safe Mode makes absolutely no sense whatsoever.
There is nothing wrong with running fsck -fy twice.
fsck does not repair faulty kernel extensions. It does a file system check. It checks the file system. It doesn't do a kernel check. That's not what the "k" in "fsck" stands for.
Herp derp, son. Herp derp.
No, there isn't anything wrong with running fsck twice, it's just pointless.
And I'll admit that "repairing" was the wrong word to use with respect to kernel extensions. It will ignore the kext cache, which means that it reverts to default kexts and does not repair them.