Scientific Linux

Scientific Linux 5.0

The ATI driver installer as of version 8.2.4 has the ability to build RPMs.

ati-driver-installer-VERSION-x86.x86_64.run --listpkg

shows the packages it can build. You may use the Red Hat drivers for Scientific Linux. For Scientific Linux 6 (64-bit) you would run:

ati-driver-installer-X.X.X-x86.x86_64.run --buildpkg RedHat/RHEL6_64a

and it generated RPMs for your specific version (e.g. version 12-3 produces) :

 fglrx64_p_i_c-8.951-1.x86_64.rpm

To install these RPMs run

rpm -Uvh <rpm_path>

After the RPM installation, make sure to run aticonfig to setup your video card.

aticonfig --initial

Your setup may be tested when X is not running with:

startx

Scientific Linux 6x

Continuing with the SL5 steps above, here is the relevant process for SL6.

Steps required once

The following command installs the packages required to get a clean build of the fglrx kernel module and load it. Without some of these installed you can run --buildpkgs without errors, but you will not be able to actually use the driver which is confusing because the Catalyst Control Center will appear to work, but have no effect.

yum -y install gcc freetype kernel-devel zlib libgcc libstdc++ fontconfig rpm-build

The following command initiates creation of an xorg.conf file that the AMD driver module will look for. SL6 normally dynamically creates a new xorg.conf as part of the startup cycle unless an xorg.conf already exists. This step ensures that one exists and that it isn't bogus. This file will be changed by the Catalyst Control Center if you decide to fiddle with options (likely -- no-screentear is too good to not use). You will probably not have to run this command twice, only the first time you install the fglrx module:

aticonfig --initial

Steps required every time you update the AMD drivers or the Kernel

Any time you update the kernel, the kernel-devel package will change, which means the header files that the fglrx kernel module is based on will be different and the driver will likely not work (or simply fail to load). So every kernel update, rebuild the fglrx module and reinstall it to keep things working. Also, note that the package name has changed from "ati-*" to "amd-*". The following commands use Catalyst 12.4 as an example, please check the AMD site for the current version before going through the process below. Obviously, the following commands must be run with root privileges.

First, step down to runlevel 3 to make sure that X is not running anywhere on the system:

telinit 3

Next, download the driver bundle. (This step uses wget, but of course you can use any method you like best for this.):

wget http://www2.ati.com/drivers/linux/amd-driver-installer-12-4-x86.x86_64.run

Use chmod to make the bundle executable:

chmod +x amd-driver-installer-12-4-x86.x86_64.run

Do the work (build the kernel module, move a few things around, etc.).:

For 64-bit systems:

./amd-driver-installer-12-4-x86.x86_64.run --buildpkg RedHat/RHEL6_64a

For 32-bit systems:

./amd-driver-installer-12-4-x86.x86_64.run --buildpkg RedHat/RHEL6

Reinstall the fglrx package via yum. The SL5 instructions above use rpm -Uvh directly, but the reason we are using yum here is to maintain integrity with yum's control of the rpmdb as well as letting it take control of the decision on what to discard/update. This is not a big deal, it merely limits complaints from it in the future.

yum reinstall fglrx64_p_i_c-8.961-1.x86_64.rpm

At this point, if this is the first time you're installing the AMD drivers, you will want to run the final one-time step above.

With all this behind us you can either run "startx" to test things out, or reboot. If you are doing this as a maintenance step on a distant computer via ssh and cannot X-forward to test the environment (or bandwidth doesn't permit real testing), you can reboot (as in "shutdown -r now") the system, shell back into it when it comes back up and check if the module is actually in the list of active kernel modules by running:

lsmod | grep fglrx

If the output shows you something like "fglrx 341525" then everything is fine and the kernel module was loaded at boot time (which also indicates that your xorg.conf was paid attention to). If "fglrx" is not in the list returned by lsmod, then something went wrong and you will need to troubleshoot why your build or installation did not work out. The most common reason is trying to update the fglrx rpm while X is running or building the fglrx rpm on the wrong kernel headers, so that is a good place to start looking for your problem.

See the post by zxq9 on the the SL forums for a discussion about this on SL6: Reference Here