Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
Lustre 2.10.0
-
None
-
9223372036854775807
Description
If one is building in a build [ch]root such as mock provides, one may not have the kernel installed which corresponds to $(uname -r).
In such a case, also try to look for the kernel-devel in /usr/src/kernels/ and just build for the latest one. Ideally there is only one installed in any case.
Attachments
Activity
Don't think this particular patch is good or useful. In the common case where links in /lib/modules are missing and it would go to picking one from /usr/src/kernels, the one it picks is fairly arbitrary. It isn't the case that there is only one most of the time.
If you must pick from there it would be better to first look for a match on 'uname -r', first an exact match and then a close match if no exact match.
In general I think putting in appropriate symlinks in /lib/modules as Dmitry suggests even if the correct kernel-devel isn't installed would be better.
btw, kernel-devel of pristine, unpatched upstream linux is insufficient for building ldiskfs. In RHEL distros it doesn't include ext4 sources, needed for building ldiskfs. kernel source or debuginfo is needed
Brian J. Murrell (brian.murrell@intel.com) uploaded a new patch: https://review.whamcloud.com/28064
Subject: LU-9775 Look for kernel-devel in /usr/src/kernels
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 48edcc4bb7a7985d9fdb90e45aa01e2fc3c405bf
dmiter: Not all build environments provide the ability to "fiddle" with the build [ch]root that the build is being done in. Probably for good reason. You "taint" the "clean room" by allowing it to be fiddled with before the build.
Copr is one such type build environment.
If appropriate kernel-devel is installed into /usr/src/kernels/<kver>/ directory it will always have a correct symbolic link from /lib/modules/<kver>/build. So, probably it will be better to just create those links for kernel-devel's without appropriate kernel's. Many scripts use those links instead of direct location.
/usr/src/kernel is very RHEL specific.
Agreed, which is why I put it at the end of the search list.
Would this break non-RHEL systems?
None that I am aware of. I don't know of any other systems using /usr/src/kernels/. If there were, and they were doing it in an incompatible way, of course we could make this search dependent on the distro configure is being run on. That just doesn't seem necessary at this point so the complexity seems unnecessary at this point also.
On a system we could also end up with variants like PAE or XEN so it can be even more complex.
I'm not sure this is very likely. /usr/src/kernels/ is at the end of the search list and so only applies to a system that doesn't actually have a kernel matching $(uname -r) installed and as such the /lib/modules/$(uname -r)/{source,build} links are missing. – hence the need to keep looking for some kernel source. I can't imagine a system that this would be true on other than a mock-style (i.e. chroot) build environment and in such an environment, you would only populate it with the kernel-devel of the kernel you are wishing to build for.
Maybe there are cases I am not thinking of?
/usr/src/kernel is very RHEL specific. Would this break non-RHEL systems? On a system we could also end up with variants like PAE or XEN so it can be even more complex.
Brian J. Murrell (brian.murrell@intel.com) uploaded a new patch: https://review.whamcloud.com/28046
Subject: LU-9775 Look for kernel-devel in /usr/src/kernels
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 59dd5a89fcde9f5ec48656591a4401e9219028ec
On a test with symlinks deleted from /lib/modules to see what would happen this patch doesn't even work. I get the following failure:
It appears the current logic looks in /usr/src/linux first and if there is no such dir it doesn't even get as far as looking in /usr/src/kernels.
There isn't any /usr/src/linux in RHEL/Centos installs