Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-7961

Problem with kernel location detection on CentOS 6

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.9.0
    • None
    • 3
    • 9223372036854775807

    Description

      CentOS 6 installed the kernel source in to the following path which differs slightly from the RHEL version. We should expand the search pattern to encompass both the CentOS and RHEL paths.

      /usr/src/debug/*/linux-2.6.32-x.y.z.el6.centos.plus.x86_64

      Attachments

        Activity

          [LU-7961] Problem with kernel location detection on CentOS 6

          Patch has landed to master for 2.9.0

          jgmitter Joseph Gmitter (Inactive) added a comment - Patch has landed to master for 2.9.0

          Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/19248/
          Subject: LU-7961 build: Fix ldiskfs source autodetect for CentOS 6
          Project: fs/lustre-release
          Branch: master
          Current Patch Set:
          Commit: 2ad5491d6822bd2e813c4e428aee987e71781713

          gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/19248/ Subject: LU-7961 build: Fix ldiskfs source autodetect for CentOS 6 Project: fs/lustre-release Branch: master Current Patch Set: Commit: 2ad5491d6822bd2e813c4e428aee987e71781713

          Bob, actually, no normal kernel modules should ever need to install the kernel .src rpm. The vast majority of modules are going require the kernel-devel and be perfectly happy with just that. Lustre is almost entirely happy (or should be) with kernel-devel as well. The only problem is ldiskfs.

          ldiskfs is, of course, very unusual. It isn't a complete kernel module on its own. The lustre tree needs to go make a copy of the ext4 source and then apply a bunch of patches to turn it into the ldiskfs source code. Then it can actually do the build.

          This is problematic because with rpms there is no way (to the best of my knowledge) to express a dependency on a .src.rpm package!

          So how, on an rpm-based system would you make the lustre .src.rpm express this odd dependency on the kernel .src.rpm? You pretty much can't.

          So while it is kind of dirty in its own right, the best that we have come up with at LLNL is to make the lustre .src.rpm BuildRequires the kernel-debuginfo package.

          morrone Christopher Morrone (Inactive) added a comment - - edited Bob, actually, no normal kernel modules should ever need to install the kernel .src rpm. The vast majority of modules are going require the kernel-devel and be perfectly happy with just that. Lustre is almost entirely happy (or should be) with kernel-devel as well. The only problem is ldiskfs. ldiskfs is, of course, very unusual. It isn't a complete kernel module on its own. The lustre tree needs to go make a copy of the ext4 source and then apply a bunch of patches to turn it into the ldiskfs source code. Then it can actually do the build. This is problematic because with rpms there is no way (to the best of my knowledge) to express a dependency on a .src.rpm package! So how, on an rpm-based system would you make the lustre .src.rpm express this odd dependency on the kernel .src.rpm? You pretty much can't. So while it is kind of dirty in its own right, the best that we have come up with at LLNL is to make the lustre .src.rpm BuildRequires the kernel-debuginfo package.

          Christopher,
          Most of the build methods and environments i know of get additional needed sources by installing and expanding the kernel .src rpm, not by installing kernel-debuginfo. Not claiming that what you say is invalid, just saying that I haven't run into it.

          bogl Bob Glossman (Inactive) added a comment - Christopher, Most of the build methods and environments i know of get additional needed sources by installing and expanding the kernel .src rpm, not by installing kernel-debuginfo. Not claiming that what you say is invalid, just saying that I haven't run into it.

          There are build environments outside of the HPDD bubble.

          Yes, you will often find contents under /usr/src/kernel on a CentOS or RHEL system. But where do those files usually come from? The come from the "kernel-devel-*" package. The kernel-devel package contains header files, Makefiles, and smattering of other files.

          What should be noticeably absent are the the .c files. What does Lustre need .c file for? To copy ext4's source code so that it can patch it and build ldiskfs.

          So how then does a person easily obtain .c files for a CentOS kernel? That person runs "yum install kernel-debuginfo".

          Great! Now we've got everything we need to build lustre, including ldiskfs.

          Some of us have been building Lustre this way, or something similar, for many years.

          Pretty soon we're hoping to go full patchless kernel for servers (see LU-20), and this kind of build pattern will become more of the norm rather than the exception.

          morrone Christopher Morrone (Inactive) added a comment - There are build environments outside of the HPDD bubble. Yes, you will often find contents under /usr/src/kernel on a CentOS or RHEL system. But where do those files usually come from? The come from the "kernel-devel-*" package. The kernel-devel package contains header files, Makefiles, and smattering of other files. What should be noticeably absent are the the .c files. What does Lustre need .c file for? To copy ext4's source code so that it can patch it and build ldiskfs. So how then does a person easily obtain .c files for a CentOS kernel? That person runs "yum install kernel-debuginfo". Great! Now we've got everything we need to build lustre, including ldiskfs. Some of us have been building Lustre this way, or something similar, for many years. Pretty soon we're hoping to go full patchless kernel for servers (see LU-20 ), and this kind of build pattern will become more of the norm rather than the exception.
          bogl Bob Glossman (Inactive) added a comment - - edited

          Joe,
          I can't tell if this patch makes any sense or not. All the build environments I'm aware of or have access to find the ext4 sources under $linux_src/fs/ext4. Where alternate source might live under /usr/src/debug/* is a don't care.

          If Chris M. insists this patch is needed I see no harm in it, but can't reproduce or test needing it at all.

          bogl Bob Glossman (Inactive) added a comment - - edited Joe, I can't tell if this patch makes any sense or not. All the build environments I'm aware of or have access to find the ext4 sources under $linux_src/fs/ext4. Where alternate source might live under /usr/src/debug/* is a don't care. If Chris M. insists this patch is needed I see no harm in it, but can't reproduce or test needing it at all.

          Hi Bob,
          Can you please have a look at the patch?
          Thanks.
          Joe

          jgmitter Joseph Gmitter (Inactive) added a comment - Hi Bob, Can you please have a look at the patch? Thanks. Joe

          People

            bogl Bob Glossman (Inactive)
            morrone Christopher Morrone (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: