ati-drivers-3.2.8 build fine, but I cannot load the module. modprobe fglrx says FATAL: Error inserting fglrx (/ilib/mod...fglrx.ko): Invalid module format.
Quick checklist 1 use test10, test9 has some issues. 2 do you have the right tools? check if you can modprobe other modules, maybe you have modutils instead of module-init-tools 3 could you attach dmesg if 1 and 2 fail?
Thanks, with test11 it works.
Please reopen this bug! It hasn't been fixed. I encountered the same problem and the solution is simple. When trying to load fglrx.ko, modprobe outputs "Invalid module format", without any clarification. However, /bin/dmesg reveals that the specific reason why fglrx.ko refused to load was a mismatch in "version magic". The kernel appeared to have been compiled with a GCC 3.2 compiler, while the fglrx.ko module was built AFTER I had switched to the ~x86 tree (which included a build of the GCC 3.3 compiler). As soon as I recompiled the kernel with the same 3.3 compiler used to build the module and rebooted with it, the driver loaded and worked like a charm. The same thing happened with Hanno. When Luca suggested that he try a different kernel, Hanno built the new kernel. It worked, but simply because he recompiled with the current compiler, not because he used a different kernel version. Solution: Include some checking mechanism in the ebuild, which checks if the current kernel has been compiled with the same compiler and which breaks off the ebuild when there is a mismatch, instructing the user to recompile the kernel with the current compiler first. This would be the most elegant solution, but I guess a simple warning message (with a few seconds delay) during the ebuild could suffice if the former option would be too much work or impossible for some reason. I couldn't find the solution anywhere, even with Google. Thanks to the Gentoo ATI Radeon FAQ, which advised me to check the dmesg output for more specific error messages, I found it out. By the way: Apart from this small issue, it's amazing to see how effortlessly the ebuild applies the correct patches to the ati module, making it perfectly compatible with both Nforce2 chipsets and 2.6 kernels. Kudos to the Gentoo developers! :)
maybe such suggested check should apply to every third party module ebuild
That might indeed be a good idea. This problem could possibly occur with any other third party driver. I currently have too little knowledge of the internals of Portage to know if it currently can distinguish between driver and non-driver ebuilds. If so, then it would be obvious that such checking code should be designed as a global feature for all driver ebuilds. Time to escalate this feature proposition into a separate bug, perhaps?
keep in mind that is up to you have your kernel and your modules built properly, I think that we could just check that and issue just a warning about this issue.
Even just a noticeable warning would be a major improvement. Then at least people would know why it might not work and what steps should be taken to resolve the problem. Can portage tell driver ebuilds apart from other ebuilds?
