Red Hat Bugzilla – Full Text Bug Listing
|Summary:||3.7.1-2.fc18 - include/linux/version.h prevents kernel modules compiling|
|Product:||[Fedora] Fedora||Reporter:||leigh scott <leigh123linux>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||alekcejk, atu, belegdol, gansalmon, h.reindl, itamar, joachim.backes, johannes.lips, jonathan, kernel-maint, madhu.chinakonda, midgoon, mike, mkhaos7, nonamedotc, pdickeybeta, robatino, sergio|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-13 23:14:44 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description leigh scott 2013-01-06 18:15:49 EST
Description of problem: I'm unable to compile most thirdparty kernel modules due to an empty /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h file Version-Release number of selected component (if applicable): 3.7.1-2.fc18 How reproducible: Every compile fails Steps to Reproduce: Try and compile nvidia (310.19) or virtualbox (4.2.4) with kernel 3.7.1-2.fc18 Actual results: Expected results: I expect it to compile Additional info: deleting /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h fixes the compile issue. surely this file is obsolete now as it's been replaced by /usr/src/kernels/3.7.1-2.fc18.x86_64/include/generated/uapi/linux/version.h
Comment 1 Josh Boyer 2013-01-06 18:47:47 EST
fixed in git.
Comment 2 Josh Boyer 2013-01-07 08:49:09 EST
*** Bug 892138 has been marked as a duplicate of this bug. ***
Comment 3 Josh Boyer 2013-01-08 08:50:53 EST
*** Bug 892974 has been marked as a duplicate of this bug. ***
Comment 4 Josh Boyer 2013-01-08 09:20:17 EST
*** Bug 893039 has been marked as a duplicate of this bug. ***
Comment 5 Fedora Update System 2013-01-08 14:52:54 EST
kernel-3.7.1-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.7.1-5.fc18
Comment 6 Fedora Update System 2013-01-09 17:51:56 EST
Package kernel-3.7.1-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.7.1-5.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0518/kernel-3.7.1-5.fc18 then log in and leave karma (feedback).
Comment 7 Josh Boyer 2013-01-11 16:23:17 EST
*** Bug 894490 has been marked as a duplicate of this bug. ***
Comment 8 Harald Reindl 2013-01-12 08:47:02 EST
well the zero-byte file is now away, nice would be the symlink directly dunno what upstream thinks here by moving things around ln -s /usr/src/kernels/3.7.2-201.fc18.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/version.h
Comment 9 Fedora Update System 2013-01-12 10:06:33 EST
kernel-3.7.2-201.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.7.2-201.fc18
Comment 10 Fedora Update System 2013-01-13 23:14:47 EST
kernel-3.7.2-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Comment 11 Antonio Augusto Santos 2013-01-14 21:46:17 EST
I'm running 3.7.2-201.fc18.x86_64, and version.h is still missing from the kernel source tree (/usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/). I had to link version.h from the kernel-headers (/usr/include/linux/version.h) as Comment #8, before being able to recompile VMware modules. Any intention to fix this behavior?
Comment 12 Harald Reindl 2013-01-15 07:26:07 EST
correct, it would be fine to have this symlink in the package but now it is better than before where te location existed as zero-byte file leading any onlie-instructions for set the symlink to fail
Comment 13 leigh scott 2013-01-15 08:22:33 EST
(In reply to comment #11) > (/usr/include/linux/version.h) as Comment #8, before being able to recompile > VMware modules. Try filing a bug report against vmware as it's their issue now, they need to add 3.7 kernel support. > Any intention to fix this behavior? Should should ask the vmware developers.
Comment 14 Antonio Augusto Santos 2013-01-15 13:10:06 EST
Leigh, so you mean that version.h was moved in linux 3.7 ? I haven't heard of it, but if this is the case, then yyeah, vmware (and all others) should update their stuff.
Comment 15 leigh scott 2013-01-15 13:56:26 EST
(In reply to comment #14) > Leigh, so you mean that version.h was moved in linux 3.7 ? Yes. Sorry this is the best link I could find for the headers files move https://lkml.org/lkml/2012/7/20/419 > I haven't heard of it, but if this is the case, then yyeah, vmware (and all > others) should update their stuff.
Comment 16 Álvaro Castillo 2013-01-17 09:17:14 EST
*** Bug 896539 has been marked as a duplicate of this bug. ***
Comment 17 Patrick Dickey 2013-01-19 22:49:50 EST
I would think that if this has changed in the 3.7.x series that companies like AMD and VMWare would already have fixed it. However, I just downloaded the installer for the AMD ATI Driver (dated 1-9-2013) and it's still looking in the wrong location. In my case, they are looking in /lib/modules/3.7.2-201.fc18.x86_64/build/include/linux/version.h not /usr/include/linux/version.h directly. Wouldn't it be easier to just create the symlink when the headers and kernel source are installed? I realize that it's a workaround--not a fix, and that the "fix" falls on the various projects/applications. Have a great day:) Patrick.
Comment 18 Harald Reindl 2013-01-19 22:57:18 EST
technically this would be easy - but i gave up to hope that opensource-developers come up with pragmatic solutions because in context of software not in the repos they are infected by the NIH-syndrome (Not Invented Here)