build and Install the module (ATI driver install)

michapma · 11-12-2005, 03:56 PM

Hi all,

I feel as though I am really getting caught up in 2 things:
1) having fun with Debian
2) the spirit of RTFM, or "Google is your friend"

Nevertheless, here is another useless "I can't quite get my ATI card installed" thread. Looking on the bright side though: I finally got my locales woes subdued, something I had never quite solved for a long time. Setting LANG in /etc/environment to en_US.utf8 instead of just en or en_US did it. Meanwhile, locales was broken; wouldn't reconfigure or allow itself to be removed. But reading the APT how-to, I found out about apt-get -f install and dpkg --configure -a. Yes! :)

Ahem. Anyway. So the next chunk of configuration I'd assigned myself was the ATI driver. After reading some enthusiastic but confusing posts here on the forum, I downloaded and executed the ati-driver-installer-8.18.8-i386.run installer. There was an error toward the end, and I'm pretty sure it left some stuff lying around. For example, in the installation path I chose:
# ls /root/ati/usr/share/fglrx/
ATI_LICENSE.TXT fglrx-install.log fglrx-uninstall.sh

Wonder what else might have been dumped somewhere during that failed process...
This leads to two small questions: 1) Is it okay just to just do /root# rm -r ./usr (i.e., get rid of usr, share and fglrx under /root)? 2) What is a more appropriate installation path for non-standard packages? /usr/local? If so, where in there? I'll read up on this if someone wouldn't mind telling me where to read.

I then turned to Google and found some reasonable sounding guides.
1) http://www.vtk.org/Wiki/VTK_OpenGL which is based on
2) http://www.watchland.org/dmcgraw/ati-debian.html
3) http://xoomer.virgilio.it/flavio.sta...installer.html

The first is based on the second, and the last one looked more up to date but . . . terrifying. So of course I went with number 2 (watchland.org). To follow my references in the rest of this post you can open that link.

The first point where I got tripped up was the discrepancy between the output of uname -a and the available kernel-header packages.

Code:

# uname -a
Linux <hostname> 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux

Code:

# apt-cache search kernel-headers-2.6.8
kernel-headers-2.6.8-2-386 - Linux kernel headers 2.6.8 on 386
kernel-headers-2.6.8-2 - Header files related to Linux kernel version 2.6.8
kernel-headers-2.6.8-11 - Header files related to Linux kernel version 2.6.8
....
kernel-headers-2.6.8-11-em64t-p4-smp - Linux kernel headers for version 2.6.8 on Intel EM64T SMP systems
kernel-headers-2.6.8-2-686 - Linux kernel headers 2.6.8 on PPro/Celeron/PII/PIII/P4
kernel-headers-2.6.8-2-686-smp - Linux kernel headers 2.6.8 on PPro/Celeron/PII/PIII/P4 SMP
....

I am running a Pentium4, so of course Debian definitely got it right on install. Unfortunately, last night I didn't see kernel-headers-2.6.8-2-686 and went with kernel-headers-2.6.8-2-386 instead. I didn't realize the difference until too late.

So here were the steps so far: download the fglrx_4_3_0-8.19.10-1.i386.rpm (I checked that I have XFree86 4.3); install kernel-headers and kernel-source packages (386 instead of 686); make the symbolic links and "change the kernel headers to reference the kernel source package's drm include". This all seemed to work.

In the next step I am to "build and install the module." Apparently, there is supposed to be a script available that I can use make on. This is where I get stopped cold:

Code:

# cd /lib/modules/fglrx/build_mod
bash: cd: /lib/modules/fglrx/build_mod: No such file or directory

Note that also in the following LinuxAnswers article (which I didn't follow) here at LQ it is also assumed that this directory exists:
http://www.linuxquestions.org/questi...icle&artid=212

When should this directory have been made? Directory /lib/modules/fglrx does not exist on my machine. When should it have gotten there?

So here are my main quesitons:

1a) Should I remove the kernel-headers and kernel-source 2.6.8-2-386 packages and install the 2.6.8-2-686 packages? If so, should I then also remove all the links I created and repeat the installation procedure?

1b) In general, when you get busy executing scripts and making links and "all kinds of stuff" during installations, but the installation fails or it succeeds but leaves files lying around, how should I manage to keep track of all of it, in order to keep the system clean and orderly? I have no clue where most of the stuff goes.

2) How can I build the module or ATI make script or whatever when it doesn't exist? Its preexistence is apparently assumed, and I don't understand why. Should it have been installed in one of the steps? It doesn't seem so to me, but I am new to this.

Thanks...

dastrike · 11-12-2005, 04:56 PM

See the ATI Display Driver Installation on Debian instructions I have written. I have described two different methods of installation - one with ATI's own installer, and the other with the fglrx packages you have taken a peek at (#3 in the list of links you provided).

michapma · 11-12-2005, 05:03 PM

Beautiful! I will try this soon. Grabbing from a 3rd-party source seems like a good solution for me.

I would appreciate it very much if someone could still take the time to answer some of my other problems, specifically about the kernel source and header packages (386 vs 686), as well as my general "anxiety" about loose files.

The mystery of /lib/modules/fglrx/build_mod will continue to haunt my dreams... And then it's on to sound, tweaking firewalls, getting more fonts, rounding up missing packages, and on and on.

Cheers

dastrike · 11-12-2005, 05:16 PM

The -386 kernel headers won't do any harm, but if you want to remove them, do so by:

Code:

apt-get remove kernel-headers-2.6.8-2-386 --purge

and then install the -686 ones if you already haven't done so:

Code:

apt-get install kernel-headers-2.6.8-2-686

Or to get the kernel headers for one's current kernel regardless what it is (as long as it is packaged and provided by Debian):

Code:

apt-get install kernel-headers-$(uname -r)

(note that in the future (might be a while - Debian releases are quite far between) the kernel-headers-... packages will be renamed to linux-headers-... instead, this has already been done in testing and unstable)

As for things you install manually, there are two main suitable places.
/usr/local
/opt
E.g. games can be put in /usr/local/games, libraryish stuff in /usr/local/lib and so on, and binaries or links to them in /usr/local/bin (which is in the $PATH by default so it is quite convenient). The Debian system never touches anything itself inside /opt and /usr/local.

I myself typically install manually installable things into /opt, e.g. /opt/netbeans-5.0beta and so, and place a symlink to the executable into /usr/local/bin.

michapma · 11-13-2005, 09:48 AM

Thank you, dastrike. Your instructions were easy to follow. I like the site design, too -- nice use of CSS.

One thing I should mention, in the way of improving the instructions: in the method "Using ATI's installer," under point 4, installing the driver, you might mention that you should not select the option to "Generate distribution specific driver package." The first time (before following your guide) I tried running the ATI installer I chose this method. I thought this would be necessary because of the way creating Debian packages is normal. Even when following your guide there was some uncertainty for me on which option to take.

I followed the instructions last night and thought the install had failed. The reason is that after restarting X and using

Code:

$ glxinfo | grep -i opengl

, the printout indicated that the Mesa project drivers were the ones being used. So I went to bed and resolved to get to the bottom tomorrow (today). After booting up I rechecked just in case, and to my delight, got

Code:

$ glxinfo | grep -i opengl
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9800 Pro Generic
OpenGL version string: 1.3.5395 (X4.3.0-8.18.8)
OpenGL extensions:

So I'm not sure why, but a complete reboot seems to have done what restarting X did not. That might be useful to suggest on the site.

Needless to say, I'm very thankful for you and others who take time to create such resources. It also inspires me to do the same once I know a little better what I'm doing.

dastrike · 11-13-2005, 10:30 AM

Thanks for the feedback, I'll improve those sections of the documentation.