Details
-
Bug
-
Resolution: Won't Fix
-
Major
-
None
-
7.6
-
None
Description
First a bit of context. Red Hat and CentOS have macros for kernel detection and kernel module building. See `kernel_module_package` in `/usr/lib/rpm/redhat/macros`.
An example of a vendor's source RPM making use of this macro: http://ldriver.qlogic.com/driver-srpms/netxtreme2/netxtreme2-7.14.46-1.rhel7u5.src.rpm
First issue:
$ ls /usr/src/kernels/ 4.4.0+10-x86_64
Per Red Hat's and CentOS' standards, this should end in .x86_64. Having it end in -x86_64 confuses the %kernel_module_package macro which then produces outputs such as:
$ rpm --eval "%kernel_module_package" %package -n kmod-%name Summary: %name kernel module(s) Group: System Environment/Kernel Version: %{version} Release: %{release} Provides: kernel-modules >= 4.4.0+10.x86_64 Provides: %name-kmod = %{version}-%{release} Requires(post): /usr/sbin/depmod Requires(postun): /usr/sbin/depmod BuildRequires: kernel-devel %description -n kmod-%name This package provides the %name kernel modules built for the Linux kernel 4.4.0+10.x86_64.x86_64 for the x86_64 family of processors. %post -n kmod-%name if [ -e "/boot/System.map-4.4.0+10.x86_64.x86_64" ]; then /usr/sbin/depmod -aeF "/boot/System.map-4.4.0+10.x86_64.x86_64" "4.4.0+10.x86_64.x86_64" > /dev/null || : fi modules=( $(find /lib/modules/4.4.0+10.x86_64.x86_64/extra/%name | grep '\.ko$') ) if [ -x "/sbin/weak-modules" ]; then printf '%s\n' "${modules[@]}" | /sbin/weak-modules --add-modules fi %preun -n kmod-%name rpm -ql kmod-%name-%{version}-%{release}.x86_64 | grep '\.ko$' > /var/run/rpm-kmod-%name-modules %postun -n kmod-%name if [ -e "/boot/System.map-4.4.0+10.x86_64.x86_64" ]; then /usr/sbin/depmod -aeF "/boot/System.map-4.4.0+10.x86_64.x86_64" "4.4.0+10.x86_64.x86_64" > /dev/null || : fi modules=( $(cat /var/run/rpm-kmod-%name-modules) ) rm /var/run/rpm-kmod-%name-modules if [ -x "/sbin/weak-modules" ]; then printf '%s\n' "${modules[@]}" | /sbin/weak-modules --remove-modules fi %files -n kmod-%name %defattr(644,root,root,755) /lib/modules/4.4.0+10.x86_64.x86_64
See all these paths that wrongly end in .x86_64.x86_64
Also, some third party source RPMs also rely on directory names in /usr/src/kernels to detect available kernel devel headers and sources and get confused, causing build failures for people trying to build drivers for their XenServer.
This can be fixed "manually" by creating a /usr/src/kernels/4.4.0+10.x86_64 symlink.
Second issue:
Even after adding a symlink, build issues still remain. Most of the time, the build process will look for files in /lib/modules/4.4.0+10.x86_64 (that is, in a directory that has the same name as the one in /usr/src/kernels). Unfortunately the kernel-devel package provides a /lib/modules/4.4.0+10 directory, so it doesn't match and builds often fail.
Proposed resolution:
Rename /usr/src/4.4.0+10-x86_64 to /usr/src/4.4.0+10.x86_64. Note that /usr/src/4.4.0+10 would not work because the depmod tool that is used in the above macro automatically adds `.x86_64` if missing.
Rename /lib/modules/4.4.0+10 to /lib/modules/4.4.0+10.x86_64
Update the Driver Developement Kit VM with these changes.