A "Command Line To The Rescue" Story

As you may recall from my earlier review of my new Dell desktop, I bought it to replace my previous Dell desktop, a Dimension 2400. Over the last couple of weeks I have installed a couple of distributions on my old system. First the Windows 7 Beta (the first installation of Windows in my house since 1996), a sad story that I hope to write about soon, and over the weekend I formatted over that horror and installed Fedora 10.

I've used a lot of Red Hat products over the years and I favor it for administration, however, I have a growing fondness for Ubuntu because it seems to deliver the best desktop user experience. When it comes to Red Hat stuff though, I'm pretty expert at installing it.

Now I have to digress a bit and talk about a phenomenon I have discovered about Linux. It is often useful to think about Linux as though it were a living thing. It's been said that Linux is based on evolution, not "intelligent design." This means that Linux evolves naturally in a series of fits and starts, rather than being the result of some grand plan. This is the opposite of proprietary software, which (if done properly) is the result of careful planning.

What this means is that sometimes a subsystem in Linux goes away and is replaced by another re-written replacement that addresses a need. And, of course, programmers prefer to re-write code rather than maintain old code. Anyway, this periodic "churn" of code is natural to the process.

The problem is that sometimes things that worked in previous versions stop working in the new versions. This is fairly common Linux, and it's perhaps its most off putting characteristic.

One case in point is the display driver for Intel integrated graphics chips. Admittedly, some of these chips really suck, especially the earlier ones. The new ones are better and also get official driver support from Intel. Over the last year or so, Linux distributions have been deploying the new "intel" driver replacing the previous "i810" driver. The new driver is in every way much better than the old driver, except it doesn't like the older chips very much.

This brings us back to my Dimension 2400, which, as you may have guessed by now, uses one of the old chips.

So I pop the Fedora 10 install DVD into the drive and reboot the machine. The installer starts and gets to the first graphical install screen and completely hangs. Dead, inert. It doesn't look like I'll be doing a graphical install this time.

I power-cycle the machine and just as the DVD starts to boot, i press the escape key and get:

boot:

Wonderful! A boot prompt. Now I know what to do. I enter:

boot: linux text

which instructs the boot loader to boot the kernel called "linux" and pass the argument "text" to the system. On a Red Hat style systems this will invoke the text mode installer. I answer all the prompts and the install gets underway. While I have some time to kill, I Google for a way to get the graphics working again. From my search, I determine that the problem isn't so much the new driver but rather that, by default, the new driver uses a new "acceleration method" called "EXA" rather than the previous method called "XAA". Making a one line change to the /etc/X11/xorg.conf file will cause X to revert to the old method and solve the problem.

After the installation is complete, I reboot the machine and it comes up in text mode. This is caused by a configuration file called /etc/inittab which contains a setting for the default run level, which is 3 for text mode and 5 for graphical mode on Red Hat style systems. In text mode you get a login screen:

Login:

I log in as root and create a personal account for myself:

useradd bshotts

passwd bshotts

After I create the account and set the password, I press Alt-F2 to get to the second virtual console. There I log in as bshotts and try to launch X. I do this by entering the command:

startx

The X server starts and almost gets to the desktop before it chokes again. Looks like it's time to fix that xorg.conf file. I restart the machine and and log in as root again. I go looking around in the /etc/X11 directory and notice that there is no xorg.conf file. This is because with modern X servers, the file is no longer required, as all the configuration is done dynamically at runtime which, in concept, is great when it works.

Bummer.

I think to myself, "there must be some kind of configuration program for X," so I start digging around in the man pages. I discover that the Xorg program has an option called -configure that will create an xorg.conf file based on the server's best guess of what the correct configuration should be. You must be root to use this option so I give it a try:

Xorg -configure

and it creates a file named xorg.conf.new in root's home directory. I copy this file to /etc/X11 which is where X expects to find it:

cp /root/xorg.conf.new /etc/X11/xorg.conf

Next, a little editing with vi and I add one line to the "Device" section of the file:

Option "AccelMethod" "XAA"

After saving the edited file, I login in as bshotts and try the startx command again and low and behold, I have a working desktop! I confirm that the graphics seem correct and log out of GNOME. This returns me to the text console. Since I want the system to work in graphical mode by default, I need to change the default run level. I do this by returning to my root console session and editing the /etc/inittab file. I change the last line to read:

id:5:initdefault:

changing the "3" to a "5" to set the run level to graphical. After saving the file I reboot the machine and everything works. New installation successful.

So what does all this teach us? It teaches us that sometimes there is no substitute for a good command line. A command line can work wonders. It teaches us that, with enough digging around, most problems are solvable. And most of all, it teaches us you should keep learning and never give up.

Hope you had a good weekend too!