Building proprietary ATI fglrx driver on Debian Lenny x86_64

August 25th, 2008

To build the ATI proprietary driver (version 8.8, being reported as 8.522) on Debian Lenny 2.6.26-1-amd64 (probably the same for testing/unstable) on x86_64 I ran into 2 subtle problems which requried a little tricking to get the driver compiled and loaded. The following issues apply only to the x86_64 version of linux.

The first issue is a library problem with a very misleading description .

shell# sh /home/random/ --buildpkg Debian/testing
... build fails with library missing ...

The solution is to install the ia32-libs, which contain the correct libs for ia32. Building with the above command work fine afterwards. Then it was possible to install the packages

shell# dpkg -i fglrx-amdcccle_8.522-1_amd64.deb fglrx-driver_8.522-1_amd64.deb fglrx-kernel-src_8.522-1_amd64.deb

The second issue happened during loading of the kernel module after building, installing and loading it with

shell# m-a build fglrx
shell# dpkg -i /usr/src/fglrx-kernel-2.6.26-1-amd64_8.522-1+2.6.26-3_amd64.deb
shell# modprobe fglrx

fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
fglrx: Unknown symbol flush_tlb_page

The patch is basically to remove the defined(__SMP__) from a preprocessor rule (this is not my patch, please see for details).

-#if defined(__x86_64__) && defined(__SMP__) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25))
+#if defined(__x86_64__) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25))

After applying the patch, rebuilding the packages, recreating the module, installing the resulting kernel-module package and loading the kernel module everything worked like a charm. Of course you need to correctly configure the driver for your X server.

System backup vs. system images

October 13th, 2006

Creating a system image is IMHO different from creating a level 0 backup.

A backup is destined for the one host it was taken from, no other. MBR, partitioning, filesystems will all stay the same. Whereas a system image is used to multiply an installation to different hosts, with probably different partitioning, eventually different mount points. Differences of configuration is not part of this post, so yes, there are definitly different setting for network, hostname, …, but that has to be handled after restoring the image.

Target systems are Intel-based, so a Rescue-CD like RIP (Rescue Is Possible) can be used. The whole system is to be backed up, so unmounting of the root partition is going to be hard, meaning a boot from external media (e.g. CD) is required. We sure want to have a consistant state, so changes to the running filesystem must not be possible during backup. The backup destination is either an external storage like a DVD burner, tape or USB harddisk, but can also be a network storage like nfs directory, netcat tcp backup, …

Let’s take a closer look at the steps involved for either of the possibilities:


Operates on the block level. Similar to saving bit by bit from the blockdevice in question. This should never ever be done on a mounted filesystem.


  1. Boot from CD
  2. Prepare backup destination
  3. Backup MBR(s)
  4. Backup partition table(s)
  5. Backup whole disk(s) or required block devices
  6. Reboot


  • independence of the filesystem used (so indirectly all filesystem features are supported)
  • can be used for non-linux filesystems (e.g. backup NTFS partitions)


  • inflexible
  • unable to restore single files or directories
  • no listing / index possible


Filesystem based

Operates on the filesystem level. The supported filesystems are known, usually with all the features they offer (e.g. extended attributes, ACLs). This should never ever be done on a mounted filesystem.


  1. Boot from CD
  2. Prepare backup destination
  3. Backup MBR(s)
  4. Backup partition table(s)
  5. Backup required filesystems
  6. Reboot


  • independence of the blockdevice
  • all filesystem features supported
  • only a limited number of filesystems supported (mostly linux)


  • some flexibility
  • unable to restore single files or directories
  • no listing / index possible
  • partition sizes must be at least as large as the original one



to be written

Blockbased backups are definitly more suitable for level 0 backups, as we definitly restore to the same host, and everything should be the same, bit by bit.
That leaves filebased archives for system images, as they are extremly flexible.


We got hacked…

November 3rd, 2005

Strange, but true. Our new server got hacked recently by some unknown folks. The downside of this incident was, that we had visitors from some unethnical hacking groups, which abused the server for UDP attacks and spam mailing. I cleared the remaining 18000+ mails in the deferred mail queue yesterday.

System was restored and the trojan files were removed (which was quite some fun as the were hidden and proticted by filesystem attr). We upgraded the system too to the latest versions, so that might make it harder for new attacks. We’ll see.

vServer move to

October 18th, 2005

As always it seemed to be just a view hours work to move all services from the old hosted vserver to the new dedicated server owned by Duke. So we join efforts on that front and are going to share the server for all our vhosts and services.

Everything is moved now, except mail service. I still need to tweak the mail configuration by merging both our domains (database vs filebased). But I see the light at the end of the tunnel.

It’s obvious that also this blog is working again, fine so far.

« Prev