emerging xfree-drm-4.3.0-r1 looks for 1. /usr/src/linux to determine kernel version, when updating /lib/modules tree. When building, it gets the correct version, but looses it and uses /usr/src/linux to get kernel version for updating modules. My current kernel is 2.4.20-ck2 with /usr/src/linux pointing to * Building DRM... gcc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_AGP -DCONFIG_AGP_MODULE -DCONFIG_DRM_SIS -DMODVERSIONS -include /lib/modules/2.4.20-ck2/build/include/linux/modversions.h -DEXPORT_SYMTAB -I/lib/modules/2.4.20-ck2/build/include -c r128_drv.c -o r128_drv.o ....... >>> Merging x11-base/xfree-drm-4.3.0-r1 to / --- /lib/ --- /lib/modules/ --- /lib/modules/2.4.20-gentoo-r2/ --- /lib/modules/2.4.20-gentoo-r2/kernel/ --- /lib/modules/2.4.20-gentoo-r2/kernel/drivers/ --- /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/ --- /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/ >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/r128.o >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/radeon.o >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/mga.o >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/sis.o >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/i810.o >>> /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/i830.o >>> Safely unmerging already-installed instance... --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/sis.o --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/radeon.o --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/r128.o --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/mga.o --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/i830.o --- !mtime obj /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm/i810.o --- !empty dir /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char/drm --- !empty dir /lib/modules/2.4.20-gentoo-r2/kernel/drivers/char --- !empty dir /lib/modules/2.4.20-gentoo-r2/kernel/drivers --- !empty dir /lib/modules/2.4.20-gentoo-r2/kernel --- !empty dir /lib/modules/2.4.20-gentoo-r2 --- !empty dir /lib/modules --- !empty dir /lib
your current running kernel matches /usr/lib/linux symblink to /usr/lib/linux-xxx ?
there is no link in /usr/lib/ that will refers what kernel I'm running?
/usr/src/linux example lu_zero@utopia lu_zero $ ls -al /usr/src/linux lrwxrwxrwx 1 root root 27 Apr 9 01:37 /usr/src/linux -> ppc-sources-benh-2.4.20-r10
As per my bug description, 1. /usr/src/linux may exists or not exist 2. No program should use it to find which kernel is being run 3. use `uname -r` I filed a previous bug which got fixed ie..ebuild got the kernel-version by not using uname -r, which you can see is building witht the correct modules, but when installing the modules, it somehow goes back to /usr/src/linux. My /usr/src/linux points to different kernel trees at various times as I update it. Currently it is 2.5.66.
could you tell me which ebuild and with bug?
Original bug http://bugs.gentoo.org/show_bug.cgi?id=17545
every kernel related ebuild MUST rely on KV that is basically where /usr/src/linux is pointing and ABSOLUTELY disreagard uname -r. I hope that our doc team will produce a document explaining why in a decent way, mine isn't, I know... Basically that is the only way to be sure that the kernel modules you are building are bind to the right kernel you are going to use. Think about the initial install, you run on the livecd kernel but you can plain to install about every kernel available. Rely on uname -r would break everything pretty well. I hope that I made the point. I hope to have the ebuild fixed for that behaviour now.
