Latest Tweets

Debian Squeeze ATI FGLRX.KO blank screen after some package-upgrading

Preamble

After upgrading the system by executing the update-manager on two GNU/Linux boxes running Debian Squeeze 64 bit, the screen went completely blank. It was still feasible to connect to the computer remotely. It was accessible in text mode also, so the problem had to be related to the Xorg server. In both cases, the graphic card installed was an ATI controlled by the fglrx.ko driver. The driver was loaded, so the fglrx.ko was not the culprit.

GLX

ATI uses its own implementation for the hardware acceleration library libglx.so. When the ati-installer is run, it does copy its own version in /usr/lib/xorg/modules/extensions/libglx.so. According to the ati kernel driver sources, fglrx.ko, it does use DKMS to avoid future issues after upgrading the kernel, that is, the KLM fglrx.ko would load without errors even when a new version of the GNU/Linux kernel was installed on the computer. That was so in both cases. However, ATI does not include protection against upgrading other parts of the operating system that can affect the way it works, as when it comes to some Xorg server libraries – and, in particular,  libglx.so -.

Knowing that the module was loaded in both computers, I decided to focus on what sort of packages had been upgraded since the last time the Xorg server was working fine, by means of reading the /var/log/dpkg.log file. This is what came out:

013-04-18 14:48:01 upgrade xserver-xorg-core 2:1.7.7-14 2:1.7.7-16
2013-04-18 14:48:01 status half-configured xserver-xorg-core 2:1.7.7-14
2013-04-18 14:48:01 status unpacked xserver-xorg-core 2:1.7.7-14
2013-04-18 14:48:01 status half-installed xserver-xorg-core 2:1.7.7-14
2013-04-18 14:48:01 status half-installed xserver-xorg-core 2:1.7.7-14
2013-04-18 14:48:02 status half-installed xserver-xorg-core 2:1.7.7-14
2013-04-18 14:48:02 status unpacked xserver-xorg-core 2:1.7.7-16
2013-04-18 14:48:02 status unpacked xserver-xorg-core 2:1.7.7-16
2013-04-18 14:48:04 configure xserver-xorg-core 2:1.7.7-16 2:1.7.7-16
2013-04-18 14:48:04 status unpacked xserver-xorg-core 2:1.7.7-16
2013-04-18 14:48:04 status half-configured xserver-xorg-core 2:1.7.7-16
2013-04-18 14:48:04 status installed xserver-xorg-core 2:1.7.7-16

According to the owners of both computers, it was more or less at that time that the screen went blank (April, the 18th, around 3pm). Well, easy as pie: the culprit had to be the xserver-xorg-core package.

Searching for conflicting libraries

I wrote a trivial bash-script in order to determine which libraries were there to be considered as conflictive, like the one I guessed was causing the issue – libglx.so -. In order to do so, I made use of the ati-installer without actually running the software package, so that I could get a list of libraries included in it. The bash-script is shown below:

#!/bin/bash
PKG=xserver-xorg-core
ATIPKG=/usr/src/amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run
 
LIBS="`dpkg -L $PKG |grep "\.so"|xargs`"
test -z "$LIBS" && echo -ne "No files"
 
clear
 
echo "Obtaining libraries to be installed by ATI FGLRX driver ... "
ATILIBS=`$ATIPKG --list|grep "\.so"`
 
echo "Looking for conflicting libraries ... "
for il in $LIBS
do
        echo -ne "Library $il in ATI ... "
        echo "$ATILIBS"|grep `basename $il` >/dev/null 2>&;1
        # We've got one library
        if [ $? -eq 0 ]; then
                echo -ne "[!!]"
        else
                echo -ne "[--]"
        fi
        echo -ne "\n"
done
 
exit 0

This is what came out after running my script:

Library /usr/lib/xorg/modules/extensions/libglx.so in ATI … [!!]

So, I was right.

Preventing future upgrades from overwriting libglx.so

 Debian has the dpkg-divert command tool to precisely prevent a package providing a particular file to overwrite a previous installed one to avoid issues like the one described in this post. So, all we had to do to solve the problem was to rerun the ati-installer and, then, to add a diversion for the libglx.so library this way:

# dpkg-divert –local –divert /usr/lib/xorg/modules/extensions/libglx.so.dpkg-update –rename /usr/lib/xorg/modules/extensions/libglx.so

# cp /usr/lib/xorg/modules/extensions/libglx.so.dpkg-update /usr/lib/xorg/modules/extensions/libglx.so

So far so good; now future upgrades are not going to interfere with this particular library, so the screen is not going to go blank again. 😉