8.12 fglrx Inrepid build with dkms

[nbi1]

dkms seems to be badly broken. I was able to successfully install the official 8.12 ATI driver under Intrepid, but can't make it work with a kernel newer than the stock Intrepid kernel (2.6.27-9).

'dkms status' shows:
fglrx, 8.561, 2.6.27-9-generic, x86_64: installed

So I'm thinking if it this is ok then maybe 2.6.28 isn't a stretch, but:

'dkms build -k 2.6.28 --kernelsourcedir /usr/src/linux-2.6.28 -m fglrx -v 8.561' yields( between dashed lines):

----------------------------------------------
Preparing kernel 2.6.28 for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.......(bad exit status: 2)
using /usr/src/linux-2.6.28/.config
(I hope this is the correct config for this kernel)
make oldconfig.....
make prepare-all....(bad exit status: 2)

Building module:
cleaning build area....
pushd /var/lib/dkms/fglrx/8.561/build; sh make.sh --nohints --uname_r=2.6.28; popd....

Error! Build of fglrx.ko failed for: 2.6.28 (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/fglrx/8.561/build/ for more information.
----------------------------------------------

One of the first hints that dkms is floundering are the nonsensical messages that it spits out. make.log in fact yields nothing of value, it's make.sh.log that we need to be interested in. That file shows:

----------------------------------------------
Error:
kernel includes at /lib/modules/2.6.28/build/include do not match current kernel.
they are versioned as ""
instead of "2.6.28".
you might need to adjust your symlinks:
- /usr/include
- /usr/src/linux
----------------------------------------------

Again more nonsense. So what if the includes don't match the current kernel?? The includes specified by "--kernelsourcedir" most definitely match the target kernel as required per the dkms man page. And there is nothing wrong with the /lib/modules/2.6.28/build symlink. The "linux" symlink is fine too. I have no idea what symlink is being referred to by "/usr/include". Those are the headers for the current kernel. They could be symlinked, but typically are not since one usually provides the header path explicitly when building any app that requires the headers. Nothing appears to be wrong so dkms shouldn't be falling on its face. If anyone has a reasonable theory on what's causing dkms to barf I'm all ears.
Many thanks.

[Kano]

Best you use debian packages for a new kernel. If needed you can use my packages too, they work with every Debian (after converting hdX to UUID) + Ubuntu systems. Just vesafb is static there thats the main difference:

http://kanotix.com/files/kernel/kernel-update-pack-generic/kernel/

Rest is mainly pure Ubuntu git - luckily the patches I provided are already integrated there.

[nbi1]

Best you use debian packages for a new kernel. If needed you can use my packages too, they work with every Debian (after converting hdX to UUID) + Ubuntu systems. Just vesafb is static there thats the main difference:

http://kanotix.com/files/kernel/kernel-update-pack-generic/kernel/

Rest is mainly pure Ubuntu git - luckily the patches I provided are already integrated there.

Thanks. I think I see the light. dkms seems to depend on updated versioning info which seems to be taken care of by the scripts in the .deb packages. That's clearly a dkms bug since it allows explicit specification of where the correct headers are located. Not every distro is going to have recent kernel packages available, many folks just grab tarballs from kernel.org so the versioning info should not be sought by dkms in that case. I'll file a bug report with the Ubuntu folks.

[Kano]

Thats not a dkms error. The problem are missing headers in non standard position.

ls /lib/modules/$(uname -r)/build

has to show the headers. Also you have to use a correct config, with bad config it will never run.

[nbi1]

Thats not a dkms error. The problem are missing headers in non standard position.

ls /lib/modules/$(uname -r)/build

has to show the headers. Also you have to use a correct config, with bad config it will never run.

Sorry, but that's wrong on several counts. Are you not reading my posts in their entirety or is something getting lost in the translation?

Are you suggesting that "--kernelsourcedir" is not a valid dkms option?? Looking at the dkms man page one clearly gets the impression that the dkms authors intended to do the right thing which is to facilitate builds for wherever the headers might reside. Obviously dkms should not have built into it a notion of how a particular distro views headers. With regards to a "standard" location there is only one: within the kernel source tree itself. If there is a "standard" for all distros then the folks at kernel.org certainly aren't aware of it!

But I do in fact have a correct view of the headers. I compared the contents of /lib/modules/2.6.27-9-generic vs. /lib/modules/2.6.28. They both contain a symlink to where the headers reside. The only difference is that for 2.6.28 it points to within the source tree itself. I don't see why that should be a problem.

Regarding the .config being correct that obviously is not an issue. I'm not rebuilding the kernel. I'm trying to rebuild fglrx for a particular kernel. That kernel boots without any problems.

I have yet to give your .debs a try. It has occurred to me that the Ubuntu packagers have altered dkms to conform to the Debian/Ubuntu view of things. There is nothing wrong with that, but it would be wrong for them to remove or alter basic dkms functionality so that it no longer conforms with the man page. My assertion is that it should be possible for dkms to successfully build regardless of where the headers are located. If that's not correct then the Debian/Ubuntu packagers need to update the dkms docs in their distro's dkms packages.

[Kano]

The only difference between manually and via dpkg installed kernel is that a dkms trigger is executed on install and remove of a kernel package. The trigger precompiles the kernel module, otherwise it would be done at boot. Also your view is absolutely stupid. When you don't have got kernel headers/source at the correct position usually you can not compile any module without override options - with or without dkms.

[nbi1]

The only difference between manually and via dpkg installed kernel is that a dkms trigger is executed on install and remove of a kernel package. The trigger precompiles the kernel module, otherwise it would be done at boot. Also your view is absolutely stupid. When you don't have got kernel headers/source at the correct position usually you can not compile any module without override options - with or without dkms.

The "correct position" by default is in the source tree. It's always been that way. That's why the kernel source is distributed by kernel.org the way that it is. I and many others have been successfully building libraries and modules outside of any package framework for many years. In many cases you have to because there simply aren't corresponding packages available. It's never a problem because correct building is easily achieved by the specifying the correct options for the configure script and/or modifying the Makefile. In fact the configure scripts for non-packaged source have become as good as they are largely because this is a fairly common occurrence. So please pull your head out of your behind and actually read and think about other people's posts before you start spouting off. And take a second to read the dkms man page so that you don't look like a complete fool.

[Kano]

I know how to use it. I can even mod other drivers to use it.

[nbi1]

I know how to use it. I can even mod other drivers to use it.

Yeah, I know how to use it too. As described on the man page. As intended by the authors (who btw are neither Debian nor Ubuntu). Just because you're the best Debian/Ubuntu video/distro hacker doesn't mean you have all the answers on 3rd party tools that have been adopted by these distros. I know it's difficult to see the forest when the trees get in the way.

And last night I confirmed my hypothesis. I installed the 2.6.28 source packages which are available for Jaunty. Lo and behold, dkms now builds fglrx cleanly for the 2.6.28 kernel. Other than some Ubuntu patches that aren't relevant to fglrx this is the same source as in the kernel.org tarball. A tarball whose source dkms is fully equipped to build as is with the proper options.

That's the good news. But I'm seeing the same failure mode that many have reported in these forums, mangled display when X starts up. I have carefully ruled out some potential culprits:

1. Incorrect xorg.conf. *NO*, using the same xorg.cong succesfully for the 2.6.27-9 kernel.
2. Bad .config. *NO*, exact same options other than the new ones identified by 'make oldconfig'.
3. Different environment, i.e. X server, etc. *NO*, fglrx 8.561 (Catalyst 8.12) works fine in exactly the same environment.

At this point I'm concluding that fglrx is broken because it has an unidentified dependency to kernel code. By switching kernels this problem is exposed. I have ruled out .config options so that strongly suggests that utilized kernel code seems to have changed. Unfortunately zeroing in on the culprit requires some video expertise. Looks like I'll have to follow through on acquiring an nVidia card.