Dear All.

I appreciate any help.

I am upgrading from Debian (woody kernel 2.4.20 gcc 2.95.4) to Slackware 10.1 (kernel 2.6.10 gcc 3.3.4, glibc2.3.2).

Debian is sitting in /dev/hda5 and I am installing Slackware on /dev/hda1.

First, I installed Slackware onto /dev/hda1 (kernel 2.4.29) then complied new kernel (2.6.10). Unfortunately, new one did not start up and things were messed up. Next, I booted on Debian and compiled new kernel (2.6.10) and installed onto /dev/hda1, which booted successfully. Now, while tuning up this kernel and pcmcia-cs, I ran into trouble.

Problem is:
I've got some modules not working. dmesg complains as follows:

***************************************************

agpgart: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
ide_scsi: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
pcmcia_core: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
pcmcia_core: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
pcmcia: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
ipv6: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'
ipv6: version magic '2.6.10 486 gcc-3.3' should be '2.6.10 486 gcc-2.95'

************************************************************

It seems that problem comes from the fact that Debian and Slackware use different version of libc and/or gcc.

I did "make mrproper" and "make clean" when I complied 2.6.10. so that whatever I compiled on Debian are erased (I think.) I also physically erased modules and installed again, but no luck.

How can I solve this situation?

Could this be a problem with System.map or config? (I do not quite understand how lilo and "make install" work with dual boot.) I did both manually copy bzImage and use lilo. (no luck again.)

Thanks in advance.

Kaz

I had the same problem this evening on my Gentoo box and it turned out to be that I hadn't run LILO. I figure that the problem is caused by the `cp` command not actually overwriting the old kernel but putting it in a different location on the disk. Unlike GRUB, LILO can't parse the filesystem, so it has to know the exact physical location on the disk where the kernel is. Since that just changed, it gets the wrong kernel because the old bits are still there on the disk, just not in the filesystem.

Try doing `cat /proc/version` to see what version your kernel thinks it is. Then find a module and do `modinfo /path/to/module.ko` to find out what the module thinks it is. If the kernel has the wrong version, then LILO must not have actually done anything. Check for an error or the -t flag. I like to run lilo with the -v or even -vv option just so I can see what it's doing. If the module has the wrong version, then a good 'ol `make clean` on your kernel source and then a recompile should fix the problem.