Uploaded image for project: 'XenServer Org'
  1. XenServer Org
  2. XSO-912

kernel-devel directory names break kernel detection in rpm macros and drivers builds

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 7.6
    • Fix Version/s: None
    • Component/s: other
    • Labels:
      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              stormi Samuel Verschelde
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: