[vox-tech] Caught in an infinite login loop

[Rick Moen]

Quoting Bob Scofield (scofield at omsoft.com):

> On Wed, 2011-06-01 at 06:07 -0700, Dr. Denny Scronek wrote:
> > This is my second shot at this. Posting, that is. My laptop is caught
> > in an infinite login loop ...won't except my password. Not a wrong
> > password/CAPSLOCK problem that I can see. Any takers? Running xubuntu.
> 
> 
> If you Google this problem you will find about six different
> explanations for login loop.  Here is the solution that worked for me.
> 
> 1)  Do what Alex says and boot with a live CD.
> 
> 2)  Mount your xubuntu partition.
> 
> 3)  Go to /usr/share/X11/xorg.donf.d/ and create a file called
> "xorg.conf"
> 
> In xorg.conf put the following:
> 
> Section "ServerFlags"
> Option "AIGLX" "off"
> EndSection
> 
> I'm probably the only person on this lists who has no idea what all of
> this means.  But it worked.
> 
> If someone on this list wants to interpret what I've put here, I'd be
> interested in learning.

You don't actually need a rescue disk to do that repair, if you have
the basic ability to do bash shell operations.  (Of course, *buntu
people often don't.)

What you did was construct a configuration file for the X.org graphics 
engine ('X11 server') that turns off Accelerated Indirect
openGraphicsLibrary eXtension (AIGLX), which, loosely speaking, is a set
of calls for fully hardware accelerated graphics rendering.  Whoever
suggested that remedy to you correctly speculated that your release of
Xubuntu's X.org / AIGLX software doesn't properly support hardware
accelerated graphics on your video hardware.  Hence, whenever you try to
login, the AIGLX extensions choke and kill the X server, taking you back
to the login screen popped up by your X display manager, which is
probably the GDM one that XFCE4 likes to borrow from GNOME.

You probably could have determined that the step would be useful before
carrying it out by having a look at /var/log/X.org.log from the non-X11
bash command line.  That might seem impossible because, you might be
thinking, 'How can I do system operations when I cannot login and X11
isn't working?'  I'll get to that point, further down.  

By the way, /usr/share/X11/xorg.conf.d/ (slight typo corrected) is not
really the ideal place to make that fix.  /usr/share/X11/xorg.conf.d/ 
is a set of configuration snippets internal to the X.org engine that it
uses as hints for hardware detection.  Although your creating an
instance of xorg.conf there _works_ in the sense that it alters X.org's 
hardware detection to prevent it from trying AIGLX, the problem is that 
that directory is / should be under the control of your package
management system, not under the control of you, the sysadmin.  A better
place to create that file is /etc/X11/ , where it is guaranteed not to
get overwritten by package updates.


Anyway, let's get back to the original dilemma you faced.  You couldn't
login, and therefore you needed a live CD to fix your system, right?
Actually, wrong.  You _could_ login, just not via the graphical login
screen (the login screen GDM puts up for you).  That's typically virtual
console #7, reached by doing Ctrl-Alt-F7.  Do Ctrl-Alt-F1 to visit
virtual console #1, which you'll notice is plain, non-X11 console.  
Visit each of Ctrl-Alt-F2, Ctrl-Alt-F3, etc., comparing them.  Visit
Ctrl-Alt-F7 again, to verify that you can get back to GDM.  

Go back to Ctrl-Alt-F1 (virtual console #1).  Notice the text-mode login
prompt.  You know what to do.

Hey, it worked.  You're logged into your system and seeing a bash
command prompt, and all without X11!  You're boldly going where hardly
any *buntu user has gone before.  Do 'cd /var/log'.

Now, 'ls | more' that puppy.  There are various logfiles from different
subsystems.  Here are two bits of wisdom, useful in practically any *nix 
debugging scenario:

o  When in doubt, look for clues in the logfiles.
o  90% of *nix problems involve file/directory ownership & permissions.

This is part of the other 10%, but the first rule applies:  If you look
in /var/log/Xorg.log, you'll almost certainly see AIGLX choking at X.org
startup time.  (The /var/log/Xorg.n.log variants are older snippets of
that same logfile that have been rotated out.)

OK, _without_ X11, how would you create /etc/X11/xorg.conf (or, if you
insist, /usr/share/X11/xorg.conf.d/xorg.conf)?  That's where it's handy
to learn to use an ASCII editor progam, practically any ASCII editor
program, that is not dependent on X11.  We sysadmins learn to use vi for
that purpose, despite its learning curve, for the simple reason that
there's some implementation of vi on every *nix system without exception
and it works even over anything more high-bandwidth than a tin can and
strings, and it works even if the system in question is pretty severely
broken.  You might prefer 'ee', or 'nano', or 'joe', or something like
that -- but with the long-term drawback that they are not guaranteed
present on other people's arbitrary *nix systems.  

If you want to try vi, the 'vim' implementation is the one usually found
on most Linux systems, and is least user-hostile.  (Cranky BSD and
Solaris admins seem to prefer nvi, which is a bit less friendly but has
compensating advantages.)

Anyway, I have gone through this exercise because it's really sad that
so many new Linux users go absolutely helpless and start fumbling for
live CDs if they are unable to use X11 graphics for some reason.  The
ability to resort to shells on the other virtual consoles, especially to
diagnose and fix X11, is a basic core skill that people should learn.