# [SOLVED!!!]Cant compile nvidia-drivers-260.19.36

## lyallp

I have this problem every now and then.

I update my kernel, try install nvidia-drivers, and it decides it can't determine my kernel version.

I have 2 kernels on my system, 2.6.35-gentoo-r15, which is my current kernel whereby I have successfully managed to install nvidia-drivers in the past.

The second kernel is 2.6.36-r5, which I have built and install but have completely failed to have nvidia-drivers install against.

Now I have screwed myself over right and proper by attempting to uninstall nvidia-drivers and now I can't re-install.

I use eselect kernel to create the symlink.

The /usr/src/linux is being found, contains a completely built kernel.

I have linux-headers-2.6.30-r1 installed.

I have a similar problem building virtualbox-modules.

I have tried doing a

```
rm -fr /lib64/modules/2.6.35-gentoo-15 && make clean && make && make modules_install && make install && emerge nvidia-drivers
```

to no avail

In the past, I found that changing ownership of the entire source tree of the kernel to portage:portage seemed to help but not at this point.

I am completely unable to install nvidia-drivers and have no idea why.

```
 * Package:    x11-drivers/nvidia-drivers-260.19.29

 * Repository: gentoo

 * Maintainer: cardoe@gentoo.org jer@gentoo.org,spock@gentoo.org

 * USE:  acpi amd64 elibc_glibc gtk kernel_linux multilib userland_GNU

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.35-gentoo-r15/build

 * Found sources for kernel version:

 *     2.6.35-gentoo-r15

 * Checking for MTRR support ...

 [ ok ]

>>> Unpacking source...

>>> Unpacking NVIDIA-Linux-x86_64-260.19.29.run to /tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work

>>> Source unpacked in /tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work

>>> Preparing source in /tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work ...

 * Applying 256.35-unified-arch.patch ...

 [ ok ]

 * Converting /kernel/Makefile.kbuild to use M= instead of SUBDIRS= ...

 [ ok ]

>>> Source prepared.

>>> Configuring source in /tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work ...

>>> Source configured.

>>> Compiling source in /tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work ...

 * Preparing nvidia module

make -j8 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/2.6.35-gentoo-r15/build HOST_CC=x86_64-pc-linux-gnu-gcc clean module 

If you are using a Linux 2.4 kernel, please make sure

you either have configured kernel sources matching your

kernel or the correct set of kernel headers installed

on your system.

If you are using a Linux 2.6 kernel, please make sure

you have configured kernel sources matching your kernel

installed on your system. If you specified a separate

output directory using either the "KBUILD_OUTPUT" or

the "O" KBUILD parameter, make sure to specify this

directory with the SYSOUT environment variable or with

the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the

kernel headers) were installed, you may need to specify

their location with the SYSSRC environment variable or

the equivalent nvidia-installer command line option.

*** Unable to determine the target kernel version. ***

make: *** [select_makefile] Error 1

emake failed

 * ERROR: x11-drivers/nvidia-drivers-260.19.29 failed:

 *   Unable to emake HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS=  IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux       SYSOUT=/lib/modules/2.6.35-gentoo-r15/build HOST_CC=x86_64-pc-linux-gnu-gcc clean module

 * 

 * Call stack:

 *     ebuild.sh, line   56:  Called src_compile

 *   environment, line 4203:  Called linux-mod_src_compile

 *   environment, line 3104:  Called die

 * The specific snippet of code:

 *               eval "emake HOSTCC=\"$(tc-getBUILD_CC)\"                   CROSS_COMPILE=${CHOST}-                   LDFLAGS=\"$(get_abi_LDFLAGS)\"                   ${BUILD_FIXES}                   ${BUILD_PARAMS}                   ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}";

 * 

 * If you need support, post the output of 'emerge --info =x11-drivers/nvidia-drivers-260.19.29',

 * the complete build log and the output of 'emerge -pqv =x11-drivers/nvidia-drivers-260.19.29'.

 * The complete build log is located at '/var/log/emerge/x11-drivers:nvidia-drivers-260.19.29:20110118-234200.log'.

 * The ebuild environment file is located at '/tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/temp/environment'.

 * S: '/tmp/portage/portage/x11-drivers/nvidia-drivers-260.19.29/work/'

```

----------

## DONAHUE

I would guess something got joggled during an update or depclean between compiling the 35-r15 and 36-r5. I would try:

```
uname -a #make sense?

emerge --sync

emerge portage

emerge -uND world

perl-cleaner all

python-updater # 2.6x selected , 3.1x available

lafilefixer --justfixit

revdep-rebuild

emerge linux-headers

emerge =gentoo-sources-2.6.35-r15

eselect kernel set linux-2.6.35-gentoo-r15

cd /usr/src

ls -l linux # valid symlink?

cd linux

make menuconfig # scan for validity

emerge -av xorg-server $(qlist -IC x11-drivers) #get lucky?

```

 If no luck: emerge -e world

----------

## dmpogo

I wonder how nvidia-drivers determines target kernel version.

Could it be it uses /proc/version and you don't have /proc enabled  or something like that ?

----------

## Jaglover

 *Quote:*   

> *** Unable to determine the target kernel version. *** 

 

I've been using latest nVidia driver for some time now and every now and then things break with very same error. There are a couple of bugs filed. Usually switching to a newer kernel version fixes it.

----------

## lyallp

I have tried reinstalling kernel headers, completely deleting the kernel sources and re-installing.

I regularly do the 

```
make menuconfig
```

 and when I am upgrading, I copy the .config file and do a 

```
make oldconfig
```

I use 

```
eselect kernel set n
```

 to create the linux symlink

Nothing to 

```
revdep-rebuild -i
```

/proc/version is fine.

It's a new install of Gentoo amd64 (about 2 weeks old).

nvidia-drivers determines the kernel version by compiling a little program.

My main issue is that I have successfully installed on previous occasions, on this machine.

Worse, virtualbox-modules, which also builds kernel modules, is having similar problems, it won't install, although, it reports a different error.

----------

## Jaglover

IMO, kernel headers are used only for building glibc.

Doing make oldconfig is not the best thing to do, it is not recommended by Gentoo developers either. It is safe only when upgrading between patchlevels. See Gentoo docs for more.

Anyhow, it may be something else. Are you sure your symlink is pointing to correct sources? Are you sure your /boot was mounted before installing new kernel? In other words, are you sure you are running the kernel you think you are running?

Sorry if this sounds a little silly, but ...

What error you are getting with VirtualBox? Knowing this may help to diagnose the problem.

----------

## lyallp

I only use 'make oldconfig' when I am changing kernel versions.

/boot is mounted, it's where the sources are. I accidentally made /boot 2G instead of 200M so I figure I might as well keep the sources in the /boot system and update /usr/src to be a symlink to /boot/src. I generally keep my kernel sources on other gentoo systems in /usr/local/src as I dislike writing to /usr if it is not necessary.

I only have 2 versions of kernel in /boot and only one in /lib64/modules.

VirtualBox modules complained that KERN_DIR (/usr/src/linux) does not point to a directory, well, of course it's not, it's a symlink but it is pointing to the correct directory as I use 

```
cd /usr/src/linux
```

 to get to the linux build directory where I do 

```
make -j8 && make modules_install && make install
```

----------

## dmpogo

Can you just show as 'ls -l' of relevant directories ?

/boot  /usr/src  ? 

does eselect work correctly if /usr/src is a symlink ?

----------

## lyallp

Tried moving source tree back into /usr/local/src, rather than /boot/src, updated the /usr/src symlink

Rebuilt 2.6.36 and re-installed, re-booted to the New 2.6.36 version (which I don't want because it doesn't play well with my laptop, no brightness controls).

eselect kernel set 1 (2.6.35-r15)

Re-built 2.6.35-r15 and re-installed.

Attempted re-install of nvidia-drivers, success.

I will try later, with sources back in /boot/src, it's my preferred location, but this will do.

It appears I need to be in a different version of the kernel to get nvidia-drivers to build.

```
root@pearcely2 src

# ls -la /usr

total 432

drwxr-xr-x  13 root  root   4096 Jan 19 14:47 .

drwxr-xr-x  22 root  root   4096 Jan  2 10:50 ..

drwxr-xr-x   2 root  root  73728 Jan 19 09:47 bin

drwxr-xr-x   3 games root     16 Jan  3 23:30 games

drwxr-xr-x 338 root  root  40960 Jan 17 15:19 include

-rw-r--r--   1 root  root      0 Nov 18 12:10 .keep

lrwxrwxrwx   1 root  root      5 Dec 23 14:56 lib -> lib64

drwxr-xr-x  30 root  root  28672 Jan 19 09:47 lib32

drwxr-xr-x 123 root  root 118784 Jan 19 09:47 lib64

drwxr-xr-x  12 root  root   8192 Jan 13 16:08 libexec

drwxr-xr-x  11 root  root    141 Jan 19 08:59 local

drwxr-xr-x   9 root  root     83 Dec 26 15:56 NX

drwxr-xr-x   2 root  root   8192 Jan 19 09:01 sbin

drwxr-xr-x 190 root  root   8192 Jan 13 15:43 share

lrwxrwxrwx   1 root  root     14 Jan 19 14:47 src -> /usr/local/src

lrwxrwxrwx   1 root  root      8 Dec 23 14:58 tmp -> /var/tmp

drwxr-xr-x   6 root  root     59 Nov 18 14:48 x86_64-pc-linux-gnu

root@pearcely2 src

# 
```

```
root@pearcely2 src

# ls -la

total 236

drwxr-xr-x  5 root     root     4096 Jan 19 14:46 .

drwxr-xr-x 11 root     root      141 Jan 19 08:59 ..

-rw-r--r--  1 root     root        0 Nov 18 12:10 .keep

lrwxrwxrwx  1 root     root       22 Jan 19 14:29 linux -> linux-2.6.36-gentoo-r5

drwxr-xr-x 24 portage  portage  4096 Jan 19 14:03 linux-2.6.35-gentoo-r15

drwxr-xr-x 24 portage  portage  4096 Jan 19 14:50 linux-2.6.36-gentoo-r5

-rw-rw-r--  1 root     root    73800 Dec 27 17:19 LyallsConfig-nouveau.txt

-rw-r-----  1 root     root    71479 Jan 19 13:27 LyallsConfig-nvidia-35.txt

-rw-r-----  1 root     root    71254 Jan 19 13:28 LyallsConfig-nvidia-36.txt

drwxrwxrwx  4 pearcely     449  4096 Jan 18 12:58 pkcs11-dump-0.3.3

root@pearcely2 src

#
```

```
# ls -la /boot

total 26552

drwxr-xr-x  5 root root    4096 Jan 19 14:35 .

drwxr-xr-x 22 root root    4096 Jan  2 10:50 ..

lrwxrwxrwx  1 root root       1 Dec 23 14:56 boot -> .

-rw-rw-r--  1 root root   71479 Jan 19 14:03 config-2.6.35-gentoo-r15

-rw-rw-r--  1 root root   71479 Jan 19 10:38 config-2.6.35-gentoo-r15.old

-rw-rw-r--  1 root root   71254 Jan 19 14:35 config-2.6.36-gentoo-r5

drwxr-xr-x  2 root root    4096 Jan 18 15:52 grub

drwxrwxr-x  8 root root     136 Jan 13 18:05 initramfs

-rw-r-----  1 root root 3643726 Dec 27 15:41 initramfs_gentoo_crypt_cpio.backup.gz

-rw-r-----  1 root root 3682444 Jan 13 18:05 initramfs_gentoo_crypt_cpio.gz

-rw-r--r--  1 root root       0 Dec 24 14:48 .keep

drwxr-x---  2 root root       6 Jan 19 14:46 src

-rw-rw-r--  1 root root 2174276 Jan 19 14:03 System.map-2.6.35-gentoo-r15

-rw-rw-r--  1 root root 2174276 Jan 19 10:38 System.map-2.6.35-gentoo-r15.old

-rw-rw-r--  1 root root 2197331 Jan 19 14:35 System.map-2.6.36-gentoo-r5

lrwxrwxrwx  1 root root      24 Jan 19 14:35 vmlinuz -> vmlinuz-2.6.36-gentoo-r5

-rw-rw-r--  1 root root 4419632 Jan 19 14:03 vmlinuz-2.6.35-gentoo-r15

-rw-rw-r--  1 root root 4419632 Jan 19 10:38 vmlinuz-2.6.35-gentoo-r15.old

-rw-rw-r--  1 root root 4223072 Jan 19 14:35 vmlinuz-2.6.36-gentoo-r5

lrwxrwxrwx  1 root root      25 Jan 19 14:03 vmlinuz.old -> vmlinuz-2.6.35-gentoo-r15

root@pearcely2 src

# 
```

----------

## DONAHUE

```
umount /boot

ls -l /boot
```

Anything returned other than total 0? If so you have occasionally written to /boot when the /boot partition was not mounted. If so, you should 

```
mkdir /wrongboot

mv /boot/* /wrongboot/
```

 with the /boot partition NOT MOUNTED to clean up. Then 

```
ls -l /boot #to check it empty

mount /boot
```

 and move any useful files from /wrongboot to /boot. Remove /wrongboot when convenient. 

Why not rm the symlinks and put your files where they belong?

Then use gparted to shrink the boot partition to 200M, apply the operation, move the next file on the right (swap?) to claim the empty space, apply the operation, move the next partition on the right (root?)  to claim the empty space, apply the operation, expand that file to use the empty space, apply the operation.

----------

## lyallp

I have method in my madness and mistakes.

I can resize the boot partition but I don't think I can add that size to the other partition on my disk.

You see, it's a single encrypted partition, on which LVM has been configured for all my other partitions, including swap.

Rather than risk losing the lot, I simply figured I would make use of the mistake and kernel sources seemed like a good choice.

Regarding boot, I have /boot automount. 

/boot is fine.

I managed to install the virtualbox-modules and nvidia-drivers by completely removing all versions of the kernel, installing a different version to what I want to run in, booting it, reverting my /usr/src/linux link back to the version I want to use, build and install then emerge nvidia-drivers.

----------

## DONAHUE

from https://bugs.gentoo.org/show_bug.cgi?id=27636

 *Quote:*   

> I don't exactly see the problem here. The kernel headers in your /usr/src/...
> 
> directory should match the kernel you are building, and the headers in
> 
> /usr/include should ideally match those you built glibc with. There is no link
> ...

 

 *Quote:*   

> Anyways, from my understanding, part of what allows this odd mix of kernel
> 
> versions and header versions is the fact that /usr/include/linux and /usr/include/asm
> 
> are not symlinks to their respective directories in /usr/src/linux/include*,
> ...

 

The moral being: if you do something unusual and something weird happens there is sometimes a connection from one to the other.

----------

## lyallp

The problem has resurfaced.

Every time there is an update to the nvidia-drivers, I end up with the 

```
*** Unable to determine the target kernel version. ***
```

 error.

Having to boot different versions of kernel just to build the new nvidia-drivers is insane.

I can re-build my nvidia-drivers of the version I currently have installed, no problems.

Stupid... mumble... mumble...

----------

## Jaglover

 *Quote:*   

> Having to boot different versions of kernel just to build the new nvidia-drivers is insane. 

 

AFAIK drivers are built against sources that linux symlink points to. Only when /usr/src/linux is not present it will attempt to build against running kernel.

----------

## Anon-E-moose

what does "uname -r" return 

what does "ls -l /lib/modules/`uname -r`/build" return

what does "ls -l /usr/src/linux" return

----------

## lyallp

```
# uname -a

Linux pearcely2 2.6.35-gentoo-r15 #4 SMP Mon Feb 7 15:51:09 CST 2011 x86_64 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz GenuineIntel GNU/Linux

```

```
# ls -l /lib/modules/`uname -r`/build

lrwxrwxrwx 1 root root 33 Jan 21 10:01 /lib/modules/2.6.35-gentoo-r15/build -> /boot/src/linux-2.6.35-gentoo-r15

```

```
# ls -la /usr/src

lrwxrwxrwx 1 root root 9 Jan 21 09:55 /usr/src -> /boot/src

```

```
# eselect kernel list

Available kernel symlink targets:

  [1]   linux-2.6.35-gentoo-r15 *

  [2]   linux-2.6.36-gentoo-r5
```

```
# ls -la /usr/src/linux

lrwxrwxrwx 1 root root 23 Jan 19 14:57 /usr/src/linux -> linux-2.6.35-gentoo-r15

```

----------

## Anon-E-moose

If you point /usr/src/linux to 36-r5 and reboot in the 36-r5 kernel

what do the commands above return?

----------

## Section_8

Just grasping at straws here - maybe having /usr/src a symlink screws something up.  Have you tried a bind mount instead?

----------

## Anon-E-moose

 *Section_8 wrote:*   

> Just grasping at straws here - maybe having /usr/src a symlink screws something up.  Have you tried a bind mount instead?

 

I thought about that, but the nvidia config finds things by looking at the running kernel (I think) to get the name

then the /lib/modules directory to find what the build symlink points at.

----------

## Jaglover

I just pointed the symlink to old sources and it definitely follows the link, not the running kernel which is 2.6.37-gentoo.

```
>>> Emerging (1 of 1) x11-drivers/nvidia-drivers-260.19.36

 * NVIDIA-Linux-x86_64-260.19.36.run RMD160 SHA1 SHA256 size ;-) ...                                   [ ok ]

 * Package:    x11-drivers/nvidia-drivers-260.19.36

 * Repository: gentoo

 * Maintainer: 

 * USE:        acpi amd64 elibc_glibc gtk kernel_linux multilib userland_GNU

 * FEATURES:   ccache preserve-libs sandbox

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.36-gentoo-r6/build

 * Found sources for kernel version:

 *     2.6.36-gentoo-r6

 * Checking for MTRR support ...                                                                       [ ok ]

>>> Unpacking source...

```

----------

## lyallp

nvidia-drivers would not compile when booted under the new kernel, whichever one was eselected.

I have not tried a bind mount, I will have to research how to do that.

What get's me is I can compile my existing nvidia-drivers version just fine, it's on upgrade that I have the issue.

Last time I ended up deleting all modules and the entire kernel source tree, and re-installing the kernel and nvidia-drivers from scratch - I even needed to be booted into a different version of the kernel.

I will try the mount option.

```
2.6.36-gentoo-r5

lrwxrwxrwx 1 root root 32 Feb  8 11:47 /lib/modules/2.6.36-gentoo-r5/build -> /boot/src/linux-2.6.36-gentoo-r5

drwxr-x---  4 root    root     4096 Feb  8 11:51 .

drwxr-xr-x  5 root    root     4096 Feb  8 11:47 ..

lrwxrwxrwx  1 root    root       22 Feb  8 11:51 linux -> linux-2.6.36-gentoo-r5

drwxr-xr-x 23 portage portage  4096 Feb  8 11:43 linux-2.6.35-gentoo-r15

drwxr-xr-x 24 portage portage  4096 Feb  8 11:47 linux-2.6.36-gentoo-r5

-rw-rw-r--  1 root    root    73800 Dec 27 17:19 LyallsConfig-nouveau.txt

-rw-r-----  1 root    root    71479 Jan 19 13:27 LyallsConfig-nvidia-35.txt

-rw-r-----  1 root    root    71254 Jan 19 13:28 LyallsConfig-nvidia-36.txt

```

----------

## Anon-E-moose

what does "emerge -pv nvidia-drivers" return and are you using custom flags for it.

You shouldn't have to completely delete everything, something is misconfigured, just not sure what.

edit to add: it may be some interaction between 

SYSSRC=/usr/src/linux SYSOUT=/lib/modules/2.6.35-gentoo-r15/build

though they should ultimately point to the same place

----------

## lyallp

```
mount --bind /boot/src /usr/src
```

 did not make any difference.

I did a full eselect/clean/compile/install/modules_install of my current 2.6.35 kernel prior to attempting an install of nvidia-drivers.

nvidia-drivers still fails to compile.

When I could be bothered, I will do what I did last time, which is boot to another version of the kernel, completely delete everything of the target version (2.6.35), re-install it all and rebuild it all with the new nvidia-drivers.

----------

## Anon-E-moose

Doing a little googling finds others with problems similar to you and many were using non-standard places for the kernel sources.

So I'm guessing some interaction with symlinks is your problem.

But I don't know what the solution is.

Edit to add: From the gentoo nvidia guide

Kernel module packages use the /usr/src/linux symlink to determine which kernel they should build against. If this link is already correct, move on to Required Kernel Settings.

Usually kernel modules should be built against the currently running kernel, so find out what that is by running:

I'm guessing that even though eselect sets /usr/src/linux properly, the ebuild is getting confused when it comes to resolving against /boot/src/*

----------

## dwbowyer

For 6 months now, I've been getting this same problem with linux sources in /usr/src.

I can rebuild the existing nvidia-drivers, but not upgrade without first rebooting to another kernel.

My feeling has been that more recent nvidia-drivers are not respecting the /usr/src/linux symlink.

I also suspect there may be some relation to "emerge --depclean" having removed sources to the

running (and symlinked) kernel sources which forced me to then reinstall that version before building

new nvidia-drivers. I've not been happy that upgrading nvidia-drivers had been forcing me to reboot.

So orginal poster is not the only one being hit by this. and his /boot/src, may likely have NOTHING

to do with the issue.

----------

## DONAHUE

emerge -uND world will bring in the latest kernel source regardless of usr/src/linux symlink

emerge --depclean will gut all but the latest kernel source removing the makefiles regardless of usr/src/linux symlink; without makefiles at /usr/src/linux nvidia-drivers will not build 

for example, emerge =sys-kernel/gentoo-sources-2.6.36 will restore the 2.6.36 make files even though 2.6.36-r5 is the latest gentoo-sources, this would allow nvidia-drivers to build against 2.6.36 if /usr/src/linux points to 2.6.36

the depclean problem may be lyall's problem if he is a frequent depcleaner; I like moose's theory

----------

## lyallp

I think that I used 

```
mount --bind /boot/src /usr/src
```

 which effectively made the location the sources invisible, even to me, since the mount did not even show up in 'df'.

Even with this, the build did not work.

----------

## lyallp

With regards to how I get the build to work, 

I boot up another version of the kernel (typically 2.6.36-gentoo-r5)

```

eselect kernel set linux-2.6.36-gentoo-r5

# throw away every trace of the required kernel

emerge --unmerge gentoo-sources-2.6.35-r15

# Note the asterisk due to modules existing in /lib and /lib64, but not in /lib32

rm -fr /lib*/modules/2.6.35-gentoo-r15

# ditch directory that is left over

rm -fr /usr/src/linux-2.6.35-gentoo-r15

# obtain nice clean kernel sources

emerge =gentoo-sources-2.6.35-r15

eselect kernel set linux-2.6.35-gentoo-r15

cd /usr/src/linux

# nice fast build, with quad core, hyperthreading

make -j10 && make modules_install && make install

emerge nvidia-drivers

emerge virtualbox-modules

reboot

```

Now, I am able to rebuild the existing nvidia-drivers, until the next update.

I do use depclean but not often, this is a quite new install and depcleans have not been required very often, so far. Additionally, when I do depclean, I generally do a close examination of the list and do a revdep-rebuild -i afterwards, just to be sure.

----------

## DONAHUE

revdep-rebuild will not restore make files removed by depclean, been there tried that, the error message is something like "missing rule to make nvidia-drivers".

you might try just

```
emerge =gentoo-sources-2.6.35-r15
```

 without the preliminaries next time the problem occurs.

----------

## lyallp

Been there, tried that.

I wasn't able to build the nvidia-drivers until I got desperate and completely started the particular kernel version from scratch.

I tried make clean

I tried throwing the whole source tree away and starting again.

It wasn't until I blew the modules away and started the source tree from scratch, that the problem went away, till next time.

----------

## Anon-E-moose

 *dwbowyer wrote:*   

> For 6 months now, I've been getting this same problem with linux sources in /usr/src.
> 
> I can rebuild the existing nvidia-drivers, but not upgrade without first rebooting to another kernel.
> 
> My feeling has been that more recent nvidia-drivers are not respecting the /usr/src/linux symlink.

 

I've not had that problem, and I've run all the latest including the 270 series now.

----------

## Anon-E-moose

 *lyallp wrote:*   

> With regards to how I get the build to work, 
> 
> I boot up another version of the kernel (typically 2.6.36-gentoo-r5)
> 
> ```
> ...

 

when you do the emerge nvidia-drivers are you doing it from within /usr/src/linux?

In other words, what is the difference between where you are when updating vs a complete kernel/nvidia rebuild?

And

are you doing a "modprobe -r nvidia" before you try and do any nvidia update?

Note: I always go back to the command line (stopping X) and modprobe -r nvidia before trying to update.

----------

## lyallp

I do the emerge nvidia-drivers wherever, just like any other package, although, I am pretty sure I have failed in /usr/src/linux as well as elsewhere.

I don't do modprobe -r nvidia prior to emerging, I see no reason why that should be required.

I can understand unloading/reloading or rebooting to activate it, but not to compile it, as linux filesystems are not like NTFS, you can delete and re-create a file that is open, the inodes remain until the last accessor closes it, then the allocations are removed.

----------

## Anon-E-moose

 *lyallp wrote:*   

> I do the emerge nvidia-drivers wherever, just like any other package, although, I am pretty sure I have failed in /usr/src/linux as well as elsewhere.
> 
> I don't do modprobe -r nvidia prior to emerging, I see no reason why that should be required.
> 
> I can understand unloading/reloading or rebooting to activate it, but not to compile it, as linux filesystems are not like NTFS, you can delete and re-create a file that is open, the inodes remain until the last accessor closes it, then the allocations are removed.

 

I'm aware that there shouldn't be a problem with compiling a newer driver while the old one is still in memory (modprobe)

but I have learned to err on the side of caution and I've avoided many of the problems that seem to crop up periodically for others.

The reason for all my questions is to try and find and differences between when it works and when it doesn't.

You absolutely should not have to completely remove all traces of the kernel source and modules before updating.

So if you remove a kernel source and all traces, and rebuild the nvidia drivers, can you then turn around an re-emerge the nvidia drivers or does that cause a problem also?

Edit to add: 

And what does "ls -ld /lib/modules/*/video" and "ls -l /lib/modules/*/video" return

and what does "ls -l /usr/src/linux/Kbuild /usr/src/linux/Makefile" return

----------

## Anon-E-moose

You get this 

```
make -j8 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/2.6.35-gentoo-r15/build HOST_CC=x86_64-pc-linux-gnu-gcc clean module

If you are using a Linux 2.4 kernel, please make sure

you either have configured kernel sources matching your

kernel or the correct set of kernel headers installed

on your system.

If you are using a Linux 2.6 kernel, please make sure

you have configured kernel sources matching your kernel

installed on your system. If you specified a separate

output directory using either the "KBUILD_OUTPUT" or

the "O" KBUILD parameter, make sure to specify this

directory with the SYSOUT environment variable or with

the equivalent nvidia-installer command line option. 
```

Because of not being able to find "linux/version.h" or Makefile and .config

This is from the check that generates the above message with lots of stuff deleted for readability

```
    select_makefile)

        #

        # Select which Makefile to use based on the version of the

        # kernel we are building against: use the kbuild Makefile for

        # 2.6 and newer kernels, and the old Makefile for kernels older

        # than 2.6.

        #

        rm -f Makefile

        RET=1

        VERBOSE=$7

        FILE="linux/version.h"

        SELECTED_MAKEFILE=""

        if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE ]; then

            #

            # We are either looking at a configured kernel source

            # tree or at headers shipped for a specific kernel.

            # Determine the kernel version using a compile check.

...

        else

            MAKEFILE=$HEADERS/../Makefile

            CONFIG=$HEADERS/../.config

            if [ -f $MAKEFILE -a -f $CONFIG ]; then

                #

                # This source tree is not configured, but includes

                # a Makefile and a .config file. If this is a 2.6

                # kernel older than 2.6.6, that's all we require to

                # build the module.

...

        if [ "$RET" = "0" ]; then

            ln -s $SELECTED_MAKEFILE Makefile

            exit 0

        else

            echo "If you are using a Linux 2.4 kernel, please make sure";

```

It looks for either /usr/include/linux/version.h or /usr/src/linux/include/linux/version.h

OR

it looks for a Makefile and .config file in /usr/src/linux

IF it can't find either then the message is generated.

Hope this helps

----------

## lyallp

ok, I thought it may be a permissions thing.

After all, I build using root.

I edit .config as root (either in an editor or using make menuconfig)

I emerge, which uses portage.

I have speculated, in the past, about ownership/permissions and one of my previous resolution attempts was to simply change ownership of the entire /usr/src/linux directory to portage.

Whilst this used to work in some cases, it seems not to now.

```
root@pearcely2 pearcely

# cd /usr/src

root@pearcely2 src

# ls -la linux/version.h

ls: cannot access linux/version.h: No such file or directory

root@pearcely2 src

root@pearcely2 src

# ls -la linux/*akefile linux/.config

-rw-r----- 1 root    root    74001 Feb  7 15:45 linux/.config

-rw-r--r-- 1 portage portage 51265 Jan 19 13:41 linux/Makefile

root@pearcely2 src

# cd linux

root@pearcely2 linux

# find . -name version.h -exec ls -la {} \;

-rw-r--r-- 1 portage portage 838 Aug  2  2010 ./arch/x86/math-emu/version.h

-rw-r--r-- 1 portage portage 1824 Aug  2  2010 ./drivers/net/cxgb3/version.h

-rw-r--r-- 1 portage portage 95 Aug  2  2010 ./fs/btrfs/version.h

-rw-r--r-- 1 portage portage 1016 Aug  2  2010 ./include/linux/dvb/version.h

-rw-rw-r-- 1 portage portage 97 Jan 19 13:50 ./include/linux/version.h

-rw-r--r-- 1 portage portage 87 Aug  2  2010 ./include/sound/version.h

-rw-r--r-- 1 portage portage 1654 Aug  2  2010 ./include/xen/interface/version.h

root@pearcely2 linux

# 

```

I changed .config to have world read, no luck.

I tried ownership of .config to portage, still no luck.

----------

## Anon-E-moose

On my system

```
-rw-r--r-- 1 root root 59009 Dec 29 12:42 /usr/src/linux/.config
```

I do emerges and kernel building as root.

----------

## lyallp

SOLVED !!!!!

My problem was that /usr/src directory was owned by root, user=rwx,group=rx,other=NOTHING

The actual /usr/src/linux-2.6.35-gentoo-r15 directory was world readable/executable, and obviously, so was the linux symlink.

I changed my /usr/src directory to be world read/execute and nvidia-drivers built!

(actually, in my case, /usr/src is a symlink to /boot/src, as described in earlier posts).

I also found my /lib/modules/2.6.??-gentoo-r? directory with the same user/group permissions. Fixing those to have world access helped.

----------

## lyallp

Another Solved.

I found my /lib64/modules directory contained a 'build' and 'source' symlink and a 'kernel' directory, when they should be inside the 2.6.xx-gentoo-rx directory.

I blew those away and that also seemed to help!

----------

