On Ubuntu 8.04 “Hardy”, the ATI Catalyst 8.4 Driver .deb packages for amd64 will build from the ATI download, but one of the four packages, xorg-driver-fglrx_8.476, will not install out of the box when you try to install the packages in the usual way.
The problem is an error in the preinstall script for the package. In a Debian package, one of the things that a package script sometimes does is “divert” files. The idea is that a package can specify that any attempt by a future package to install a file having a particular name is to be handled by renaming the file to something else, or diverting it. In this way, a package can protect files from being overwritten without causing another package to fail to install. If you have customised a package-supplied file, which might be overwritten by a package upgrade, you can use dpkg-divert to protect your version.
The ATI xorg driver package uses this facility to stop MesaGL, a software Open GL renderer, from overwriting the ATI hardware drivers. That's a good thing, but the problem is that the preinstall script diverts two files to the same target. In other words, it says “instead of installing /foo/bar, rename it /foo/quux” then a second later, “instead of installing /foo/baz, rename it /foo/quux as well”. That's not allowed (because it's obviously stupid).
This accounts for the seemingly bizarre error-message that xorg-driver-fglrx_8.476 is trying to divert to a file target that it, itself, has already diverted another file to!
I suspect that the person who wrote the script copy'n'pasted the line, remembered to edit the filename to divert, but forgot to change where it was diverted to. An easy, if silly, mistake to make. ATI have made a lot of progress in providing decent Linux driver, maybe we shouldn't be too hard on them for lousy QA.
The fix follows below the fold…
The Fix
IF THIS BREAKS, YOU GET TO KEEP BOTH PARTS
In principle, the fix is very easy:
- Unpackage the .deb archive.
- Edit the preinst script to fix the error.
- Repackage the .deb archive.
In practice, it's a little tricky to do manually, so I've provided a shell script to help make it easier: fix-cat84.sh.
It seems that the postrm script is similarly "challenged", but I didn't know this until Chris (below) brought it to my attention. I've done the best I can to fix the postrm script too (it's straightforward), but I would have to remove the existing package, install the new one, and then remove it in order to test the new postrm script, and that's a bit too much like hard work, so I haven't tested it. When an update to the driver appears, I'm going to have a problem removing the old package and I'll post my solution when that happens.
If you decide to go ahead, here's the instructions:
- Build the packages, but don't install them.
- Create a new empty directory.
- Copy the script into the directory and make it executable.
- Copy the xorg-driver-fglrx_8.476-0ubuntu1_amd64.deb package into the directory.
- From the shell-prompt, cd into the new directory and run the script.
For example (if you like to live a little dangerously):
$ mkdir tmp $ cd tmp $ wget http://www2.ati.com/drivers/linux/ati-driver-installer-8-4-x86.x86_64.run $ sh ati-driver-installer-8-4-x86.x86_64.run --buildpkg Ubuntu/hardy $ wget http://caulfield.info/emmet/src/fix-cat84.sh $ sh fix-cat84.sh
You should now be able to install the packages in the usual way.
Amazing, cheers mate!
You're welcome, and thanks for commenting: it's nice to know that at least one person found it helpful.
Thanks for your great script, the installation was sucessful!
Now i tried to remove the package (sudo apt-get remove xorg-driver-fglrx).
It ended with an error:
"dpkg-divert: Keine Übereinstimmung mit Ziel für Umleitung
beim Entfernen von »diversion of /usr/X11R6/lib32/libGL.so.1 to /usr/X11R6/lib32/fglrx/libGL.so.1.2.xlibmesa by xorg-driver-fglrx«
»diversion of /usr/X11R6/lib32/libGL.so.1 to /usr/X11R6/lib32/fglrx/libGL.so.1.xlibmesa by xorg-driver-fglrx« gefunden"
I think theres something wrong in the driver.postrm?
Hi Chris,
I'll look into this. In the meantime, if you look at the manpage for dpkg-divert you might find a solution before I do.
Emmet.
Hi Emmet,
Thanks for your help. I am encountering this error when trying to build packages for my X1950 pro on hardy:
dpkg-shlibdeps: warning: symbol XauFileName used by debian/xorg-driver-fglrx/usr/sbin/atieventsd found in none of the libraries.
dpkg-shlibdeps: warning: debian/xorg-driver-fglrx/usr/sbin/atieventsd shouldn't be linked with libXrender.so.1 (it uses none of its symbols).
dpkg-shlibdeps: failure: couldn't find library libfglrx_gamma.so.1 needed by debian/xorg-driver-fglrx/usr/bin/fglrx_xgamma (its RPATH is '').
Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
dh_shlibdeps: command returned error code 512
make: *** [binary] Error 1
dpkg-buildpackage: failure: debian/rules binary gave error exit status 2
Removing temporary directory: fglrx-install.Ui8787
Any ideas?
Shelly,
There's a fix suggested in in this Debian user forums thread.
There seem to be quite a few problems with this latest package: I wouldn't be at all surprised if AMD/ATI released a "fixed" version rather quickly. Things are moving so fast (new version every couple of weeks) that it's hardly worth going to a lot of trouble to install the latest driver since there'll probably be another one along soon.
Emmet.
Does this still work with the 8.5 drivers?
Hej Luftkopf,
The 8.5 drivers seem fine to me. If you've previously installed the 8.4 drivers, then you may have to manually "un-divert" the broken diversions installed by the previous 8.4 install. It's not hard, you just use "dpkg-divert --remove" to get rid of a few diversions relating to "X11" or "GL", then uninstall the 8.4 drivers. Once that is done, install the 8.5 drivers and everything should work out OK. You might have to play around a bit with dkms to upgrade the kernel module. There have been a few kernel package upgrades; with one of them, I had a minor problem: when the new module was built under the old kernel, it didn't work and I had to use dkms to manually build the new kernel module. After that, it worked fine.
If you think it would be helpful, I could describe it in more detail.
Emmet.
A more detailed description would be helpful.
Thanks.
Uwe,
Thanks for posting. Sorry for the delay. Please find full instructions here.
Emmet.