September 19, 2014
 
 
RSSRSS feed

Basic Linux Tips and Tricks, Part 3

X Marks the Spot

  • October 23, 2007
  • By A. Lizard

Part 1 of this article provided the general background a reader needs to solve problems with Linux. Part 2 of this article discussed the process of solving Linux problems. In this final part of a three-part series, we'll step through a real-world example of solving a Linux problem.

X Window is the video part of the Linux operating system, with Xserver acting as the internal server that delivers the video to your display. The configuration file read during startup also plays some part in driver setup for other built-in hardware like the keyboard, mouse, and even functions like font selection.

The Xserver's configuration file is /etc/X11/xorg.conf.

I use X Window video in my examples here because this is where I've had the most frequent problems in the context of Linux upgrades. It's also a significant problem for new users: no X means no GUI desktop. The methods I use to solve my X Window problems are the ones you can use to solve Linux problems in general.

First, you need to start and stop X and its window managers.

  • $ startx will start the default window manager
  • # gdm start starts the GNOME window manager; gdm stop halts it
  • # kdm start starts the KDE window manager; kdm stop halts it

You can also choose your session type (console, KDE, GNOME, other window managers) from a pull-down menu at the X Window login prompt.

After this, find out if your networking still works? If not, get to another computer and find the fix you need, starting with a search on the error message. (I've never had networking go down in the context of a failed video driver install--I regard it as a "solved problem" for Ethernet wired Linux installations.)

If your network is indeed up and running, you can use the text-based Lynx console browser search on the last error message you got before whatever you're using crashed. However, text-based web browsing is a painful experience and if Javascript, etc. are necessary to view site content you need, you're stuck.

Another trick to try: Knoppix or some other Linux Live CD. Which driver did the Live CD distro use? Watch the text on the screen when the Live CD starts running--it should show the driver used just before it starts the Xserver GUI.

If your problem is a non-working video driver, put the driver name in xorg.conf, This will keep you going until you find the right fix. To edit xorg.conf, open it in a text editor as root:

# nano /etc/X11/xorg.conf

Section "Device"

#    Driver         "nvidia"
    Identifier     "Generic Video Card"
    Driver         "vesa"

If your old driver isn't working, comment it out as shown with # and add whichever driver successfully ran on the Live CD. In this case, the alternative driver is vesa. I wasn't content to stay with vesa because it doesn't support OpenGL, i.e., no video acceleration, and it doesn't support hibernate/suspend, meaning no power saving modes. A so-so replacement like this should get you by if you need a quick fix.

The problem I've had is that for Nvidia card (and ATI), the video driver is a kernel module that has to be separately installed every time you get a kernel upgrade. Nvidia is one example of this, Ordinarily, the fix when you get dumped to a terminal screen is:

# aptitude install nvidia

What do you do when this fails? The first thing to try is making sure your kernel video driver matches the kernel if the kernel has been upgraded. If you aren't sure what your kernel version is, type

$ uname -a

To find out what's installed, enter

# aptitude search nvidia

I finally found that reinstalling the nvidia drivers on every reboot, stopping gdm via

$ /etc/init.d/gdm stop

stopping kdm via

# /etc/init.d/kdm stop

deinstalling and reinstalling the nvidia packaged driver (instead of the Debian package), then restarting kdm got me to a GUI login prompt.

I found the fix here by using these Google keywords: nvidia install reboot.

Note: Thisfix is for a much earlier version of the kernel and driver than the one I was using, but since the symptoms matched, I thought the suggested fix was worth a try.

The fix was:

# cd /etc/init.d
# mkdir old-drv
# mv nv* old-drv

which move both nvidia and nvidia-glx scripts out of play.

Then, I reinstalled the nvidia binary.

Apparently the new video drivers I hadn't noticed being installed, had nvidia and nvidia-glx startup scripts in init.d leftover from an earlier version with the startup instructions that actually work with the current driver somewhere else.

If you just did a kernel upgrade and nvidia's down, if you're using kernel version 2.6.21+, read on to find the solution and how I discovered it.

You can find your kernel version by:

$ uname -a
Linux terrarium 2.6.21-2-k7 #1 SMP Wed Jul 11 04:29:08 UTC 2007 i686 GNU/Linux

I took a screenshot with a camera to make sure I got the crash error message exactly right and referred to it when doing a search.This is where a decent point-and-shoot digital camera comes in handy, if you're in the console not running from a desktop, GUI screenshot applications are useless. Doesn't have to be high-end, but decent light sensitivity and autofocus are really helpful.

I searched on the following error message from dmesg:

"nvidia: disagrees about version of symbol struct_module"

I found out that the kernel developers decided to make a kernel call relating to paravirtualization unavailable to non-GPL proprietary drivers. The first workaround I saw was "rebuild the kernel without paravirtualization." As a VMware user, paravirtualization is something I'd miss, so I looked for another fix. What I found was that someone had patched the kernel to make the call correctly, bypassing the developers' changes.

You can find a complete description of the problem here and the workaround if you go to the links from the summary I wrote, including a link to where you can get the patches.

There appears to be a permanent fix in 2.6.22.

Sitemap | Contact Us