I realize this is an old question, but it's also pretty general without any details about the specific hardware involved. That said, you can't file a bug or go about fixing things until you figure out some more details.

I thought I'd take a stab at this since I faced the issue and recovered from it pretty recently. I'll probably run through here again later and throw in some more info and simplify the steps, but the answer list is already pretty big, so I'll go easy on the screenshots.

Recovery mode is your friend, but you don't always need a single-user root session to solve things. In fact, you might just be able to do a normal console login by selecting "resume" without considering any of the other options on the recovery menu. The nice thing about a normal console session over the single-user root mode is that you can get multiple terminals running at once--Switch between them or open up new ones with Alt + F1 , Alt + F2 , etc. There's a good chance that it's a video driver issue which is preventing you from going into the graphical login, and it might just be a result of some upgrade you did before rebooting the computer.

You might go a couple of years at a time without experiencing similar issues, but it's a good idea to know your hardware and to be prepared to use the terminal. Basically there are two video drivers to worry about: the kernel driver and the xorg driver. Xorg is a video server that uses the x11 protocol to display things in full color with depth and all kinds of crazy effects--It's an abstraction layer between applications like the desktop environment or windowing managers and the kernel driver. The kernel driver is yet another abstraction layer, but it's a bit closer to communicating with the actual hardware.

It's the kernel's job (in this case, Linux) to pass messages between applications and the hardware. The drivers can either be compiled into the kernel or added in a more ad hoc way through kernel modules. Probably you're using modules unless you configured and compiled your own custom kernel. The kernel driver as a module gets loaded shortly after you boot up, which allows for easier upgrades when you power down to swap out a card. The good news is that there are some more or less standard tools that you can run from the command line to give you more information about those kinds of drivers, the actual hardware and whether they're loading: lspci, dmidecode and dmesg, to name a few. There are man pages (e.g., $man dmidecode ) and many howtos on those kinds of tools, so I won't go into too much detail here for now.

Then there are the xorg drivers. To list what's available in the repositories, you might type apt-cache search xserver-xorg-video | less to give you a list of all possible drivers. Piping it to less with the '|' symbol which you can probably type by tapping the slash key while holding down shift (to be clear on what symbol this is), gives you the option to scroll back and forth through the list of drivers (with the arrow keys). To get more info on a specific driver, you might type apt-cache show xserver-xorg-video-vesa (to pick one at random). To install one, you could type apt-get install xserver-xorg-video-vesa and hope for the best. As of I don't know how many versions ago Xorg will try to load one of the installed drivers for you automatically, but under certain conditions you might have a configuration file lingering around in /etc/X11 called xorg.conf . So take a look and see if there's one there: ls /etc/X11/xorg.conf

If you upgraded an Xorg driver without directly upgrading Xorg itself, there's a chance that reverting to the old driver via apt-get install will not automatically pull in the version of Xorg that it's compatible with--It should but apt doesn't always do what it should. Minimally, you'll need a matching version of xserver-xorg-core. Don't bother with uninstalling the upgraded xorg replacement though, just enter the command apt-get install xserver-xorg-core to revert back and uninstall the newer version automatically. This advice applies mostly to transitional renamed packages which provide virtual packages to replace ones that are still being maintained in the same branch of the package tree. Virtual packages are sometimes a mess and can do funny things with any of a number of dependencies which are getting swapped around in the upgrade/downgrade process, but concentrate on getting back to the GUI first.

Now that I've given an overview of some directions to start with troubleshooting, let's get back to the console screen that you hopefully pulled off without a hitch from choosing "resume" at the recovery menu. It's a pain to be stuck without a mouse at the console when you've got a lot of copying and pasting to do, so prepare yourself with some gpm for mouse support and some other tools: links/links2 or w3m (web browsers), vim (text editor), dpkg, apt, less (vim style keys and searching like man), and grep. I'm probably leaving a few out.

Some particularly useful commands for dpkg are dpkg -L to show files for packages that are already installed and dpkg -l | less to show all packages which are currently installed (piped to less ).Sometimes gpm is a little finicky about letting you select things, so you can restart it with /etc/init.d/gpm restart but you might have problems with clicking on links in a page before you restart w3m or the browser links . w3m is a little easier to scroll around and generally better for authenticated sessions (e.g., logging into forums for help). It takes a bit of getting used to hitting the Esc key to click on links (the hyperlinks) though, and the learning curve is a bit steeper than with the browser known as links .

Unless you've got an Nvidia card or something with proprietary driver support for linux that you want to try, I'd shy away from kernel drivers before trying things with xorg--Try troubleshooting the xorg drivers first because it can be a lot easier than customizing a kernel for hardware (depending on the brand). The thing is that you might wind up following a series of links that lead you in the wrong direction, with chip makers sending you to the card makers and card makers giving you no support. As for trying out different kernels for different "vanilla" versions of the driver, stick with kernel versions that aren't far off from your current one (given by uname -r ) unless you're really interested in testing. There's a pretty good chance that the latest mainstream kernel won't even boot up on your system, so why bother if you're stuck with a half-way broken setup? Keep focused on doing the bare minimum that it takes to get back up again so you're not falling behind on too much work. You can type things up in emacs, vim or pico/nano or check your email in mutt or pine, but eventually you'll want to come back to the 21st century.

Good luck!