Hey guys!
I’d like to install the NVIDIA Linux driver 375.39 (GeForce 840m) on my laptop (kernel 4.10.0).
During “Building Kernel Modules” the installation aborts. The log shows “linux/fence.h - no such file or directory”.
Any suggestions?
Just found the fence.h here: http://lxr.free-electrons.com/source/include/linux/fence.h
Thx!
Install kernel-devel
are installed
Am Tue, 14 Feb 2017 20:36:01 GMT
schrieb Reiti <Reiti@no-mx.forums.microfocus.com>:
> Hey guys!
>
> I’d like to install the NVIDIA Linux driver 375.39 (GeForce 840m) on my
> laptop (kernel 4.10.0).
Either
don’t use unreleased kernels from other repos (TW is at 4.9.x and not on
4.10.x at the moment!)
http://download.opensuse.org/tumbleweed/repo/oss/suse/x86_64/
shows:
kernel-default-4.9.8-1.1.x86_64.rpm
kernel-default-4.9.9-1.1.x86_64.rpm
kernel-default-base-4.9.8-1.1.x86_64.rpm
kernel-default-base-4.9.9-1.1.x86_64.rpm
kernel-default-devel-4.9.8-1.1.x86_64.rpm
kernel-default-devel-4.9.9-1.1.x86_64.rpm
or
https://devtalk.nvidia.com/default/topic/981993/linux/-patches-included-4-10-kernel-staging-/
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
Addendum:
Am Tue, 14 Feb 2017 20:56:02 GMT
schrieb Miuku <Miuku@no-mx.forums.microfocus.com>:
> Install kernel-devel
That would not be sufficient, a suitable build environment also needs
kernel-$FLAVOR-devel depending on the kernel installed (most likely default).
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
Although in a previous post in another thread Wolfi said it should not work,
For many years and with several kernel flavors, I’ve found that it’s not necessary to specify the flavor…
Simply specifying “-devel” without the flavor has installed the correct packages for me.
Same has worked for me when installing for openjdk, no matter the major or minor version, zypper has been smart enough to find what’s appropriate and install it for me…
TSU
Am Wed, 15 Feb 2017 18:26:01 GMT
schrieb tsu2 <tsu2@no-mx.forums.microfocus.com>:
> For many years and with several kernel flavors, I’ve found that it’s not
> necessary to specify the flavor…
> Simply specifying “-devel” without the flavor has installed the correct
> packages for me.
This is just plain wrong, kernel-devel does not pull in flavor specific
packages, it is just the other way around.
Check yourself with rpm -q --requires $PACKAGE.
Installing kernel-$FLAVOR-devel pulls in kernel-devel automatically and without
kernel-$FLAVOR-devel your environment will miss the kernel config, Makefile
amongst other things.
uname -r
4.9.9-1.g6c5120c-default
kernel-devel-4.9.9-1.1.g6c5120c.noarch.rpm
warning: kernel-macros-4.9.9-1.1.g6c5120c.noarch.rpm: Header V3 RSA/SHA256
Signature, key ID 03579c1d: NOKEY
Preparing… ################################# [100%]
Updating / installing…
1:kernel-macros-4.9.9-1.1.g6c5120c ################################# 50%]
2:kernel-devel-4.9.9-1.1.g6c5120c ################################# [100%]
cd r8168-8.043.02/src/
make modules
make -C /lib/modules/4.9.9/build SUBDIRS=/tmp/r8168-8.043.02/src clean
make[1]: *** /lib/modules/4.9.9/build: No such file or directory. Stop.
Makefile:99: recipe for target ‘clean’ failed
make: *** [clean] Error 2
So much for that theory.
But after …
warning: kernel-default-devel-4.9.9-1.1.g6c5120c.x86_64.rpm: Header V3
RSA/SHA256 Signature, key ID 03579c1d: NOKEY
Preparing… ################################# [100%]
Updating / installing…
1:kernel-default-devel-4.9.9-1.1.g6################################# [100%]
make -C /lib/modules/4.9.9-1.g6c5120c-default/build
SUBDIRS=/tmp/r8168-8.043.02/src modules make[1]: Entering directory
‘/usr/src/linux-4.9.9-1.g6c5120c-obj/x86_64/default’ CC
[M] /tmp/r8168-8.043.02/src/r8168_n.o CC
[M] /tmp/r8168-8.043.02/src/r8168_asf.o CC
[M] /tmp/r8168-8.043.02/src/rtl_eeprom.o CC
[M] /tmp/r8168-8.043.02/src/rtltool.o LD [M] /tmp/r8168-8.043.02/src/r8168.o
Building modules, stage 2.
MODPOST 1 modules
CC /tmp/r8168-8.043.02/src/r8168.mod.o
LD [M] /tmp/r8168-8.043.02/src/r8168.ko
make[1]: Leaving directory ‘/usr/src/linux-4.9.9-1.g6c5120c-obj/x86_64/default’
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
Could be I’m wrong, and might have been misled by admittedly my experiences…
I should maybe say then that for a decade I’ve just never run into a problem where the headers I’ve pulled in have been insufficient to make the kernel modules necessary for the applications <I’ve> had to build…
Which have been mainly VMware and Virtualbox (no longer needed for VMware) and various others I can’t name off the top of my head.
I generally am aware I have a problem only if the kernel module can’t be built,
And that admittedly might have been because of the specific modules I’ve built and may not be representative of the whole universe of modules.
TSU
Let me get this straight and let me be short and to the point.
If you want to build any (external) kernel module for an openSUSE Kernel, you will need
and
No more, but certainly no less.
The package kernel-devel contains all the shared stuff independent of the target kernel’s flavor while kernel-$FLAVOR-devel contains the flavor specific stuff and most importantly the .config, Module.symvers and other data needed to build a functioning module for that target kernel.
If you only have “kernel-devel” installed and “kernel-$FLAVOR-devel” is missing, your build will fail.
AK
Forgot one important thing to add and please keep this in mind.
There actually could be a way to make this “work” even without the kernel-$FLAVOR-devel.
Something like “run make mrproper ; make cloneconfig” or similar “advise”.
Notice the “”?
I’ve read it several times in this forum and I am also sure I answered serveral times with the same link I am posting now.
Yes, this blogpost is 10 years old and yes it says something about “kernel-source” which does not apply any more but the main point still is true.
And for some extra entertainment, notice the example for an “insane” Makefile?
That also still holds true after 10 years, still the same insane Makefile with SYSOUT and all the other confusing “extras”.
In short:
“make modules, not config/prepare/mrproper/etc…”
AK
Thank you for your answers so far.
Installed are:
**➜ ****~** uname -r
4.10.0-rc7-1.gd9294c3-default
**➜ ****~** rpm -qa | grep kernel
**kernel**-default-devel-4.10.rc7-1.1.gd9294c3.noarch
**kernel**-devel-4.10.rc7-1.1.gd9294c3.noarch
My devel packages match my kernel, don’t they? So with the given libraries there shouldn’t be a problem with building the kernel modules, but still fence.h is missing.
Am Thu, 16 Feb 2017 00:06:01 GMT
schrieb Reiti <Reiti@no-mx.forums.microfocus.com>:
> Thank you for your answers so far.
>
Being thankful is appreciated, however it would be even more appreciated if you
(re)read all the answers, especially the one directly addressing your issue and
giving you two direct options (hint: = my first answer in this thread).
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
I’m going to confirm that making sure that the proper flavors are installed, fence.h is indeed missing from 4.10
cassidy:~ # rpm -qa | grep kernel
kernel-firmware-20170223-1.1.noarch
nfs-kernel-server-2.1.1-1.2.x86_64
kernel-syms-4.10.1-1.2.x86_64
kernel-default-4.10.1-1.2.x86_64
kernel-default-4.9.11-1.2.x86_64
kernel-source-4.10.1-1.2.noarch
texlive-l3kernel-doc-2016.113.svn_6512svn41246-29.1.noarch
kernel-docs-4.10.1-1.2.noarch
kernel-default-devel-4.10.1-1.2.x86_64
texlive-l3kernel-2016.113.svn_6512svn41246-29.1.noarch
kernel-default-devel-4.9.11-1.2.x86_64
patterns-openSUSE-devel_kernel-20170206-2.1.x86_64
kernel-devel-4.10.1-1.2.noarch
kernel-devel-4.9.11-1.2.noarch
kernel-syms-4.9.11-1.2.x86_64
kernel-source-4.9.11-1.2.noarch
kernel-macros-4.10.1-1.2.noarch
cassidy:~ # cd /
cassidy:/ # find . -name fence.h -print
find: File system loop detected; ‘./.snapshots/1/snapshot’ is part of the same file system loop as ‘.’.
./.snapshots/2/snapshot/usr/src/linux-4.9.11-1/include/linux/fence.h
./.snapshots/2/snapshot/usr/src/linux-4.9.11-1/include/trace/events/fence.h
./.snapshots/3/snapshot/usr/src/linux-4.9.11-1/include/linux/fence.h
./.snapshots/3/snapshot/usr/src/linux-4.9.11-1/include/trace/events/fence.h
./usr/src/linux-4.9.11-1/include/linux/fence.h
./usr/src/linux-4.9.11-1/include/trace/events/fence.h
find: ‘./run/user/1000/gvfs’: Permission denied
cassidy:/ #
Dan
Hi
So, a couple of things with the newer kernels and proprietary drivers, seems they need patching at the moment (looks like fence changed to dma_fence), so the error (anyone posted logs?) could be a red herring so to speak…
Go to the Nvidia forums as this is the most likely place to find an up to date thread on drivers and patches.
https://devtalk.nvidia.com/default/topic/994087/linux/387-13-patch-for-4-10-0-rc8-linus-master-/
If it’s not for your nvidia blob version, look at the patch and modify for your driver, or else ask on their forums if there is a patch available.
T’is true - I installed TW on my test box with nVidia 1070, needed to manually patch the nVidia driver to work on 4.10+.
If needed I can throw the patch here although it’s available at nVidia here; https://devtalk.nvidia.com/default/topic/995429/failed-installed-nvidia-with-kernel-4-10/
I’ve tried two different patches for the 378.13 nvidia driver and the 4.10 kernel, one from the German openSUSE forums and one from nvidia.devtalk and neither one worked for me. If anyone has successfully patched the 378.13 driver can you give me a link to that patch? Thanks.
This should work:
https://devtalk.nvidia.com/default/topic/995429/linux/failed-installed-nvidia-with-kernel-4-10/post/5092135/#5092135
Here on Leap 42.2 and Kernel 4.10:
linux64:~ # nvidia-settings -v
nvidia-settings: version 378.13 (buildmeister@swio-display-x86-rhel47-05) Tue Feb 7 19:35:55 PST
2017
The NVIDIA X Server Settings tool.
This program is used to configure the NVIDIA Linux graphics driver.
For more detail, please see the nvidia-settings(1) man page.
linux64:~ # lsb-release -id
Distributor ID: openSUSE project
Description: openSUSE Leap 42.2
linux64:~ # uname -a
Linux linux64 4.10.1-3.g8c10701-default #1 SMP PREEMPT Thu Mar 2 13:05:23 UTC 2017 (8c10701) x86_64 x86_64 x86_64 GNU/Linux
linux64:~ #
Not sure what to make of this since others are having success. I’ve tried two different patches and both times nothing happened. I execute the patch command in the terminal and the cursor goes to the next line and nothing happens. I waited 20 minutes two different times with no output. Kind of hard to troubleshoot when there’s no output from the patch command.
Hi
If there is no output then all is good and the patch was successful.
If you want to see what it will do, add the --dry-run option (man patch)
When I say there was no output, I mean the patch command did nothing. I had to use ctl>c to stop the command after 20 minutes. The 378.13 hasn’t been patched and will not build.