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
| Fix Version/s | New: Lustre 2.10.1 [ 13090 ] | |
| Fix Version/s | New: Lustre 2.11.0 [ 13091 ] | |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Oleg Drokin (oleg.drokin@intel.com) merged in 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:
Commit: ad7e776c076108dfa2b64120cd80c8adb5dafda2
Oleg Drokin (oleg.drokin@intel.com) merged in 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:
Commit: 1a8c125e39f1a96c1afcbd5fac88c34e92d63eff
bogl Fair enough. But that's a future concern with a number of possible solutions, none of which have probably been decided on at this point. So it seems unreasonable to prevent solving today's problems just because of not yet knowing how we will solve tomorrow's problem.
Once tomorrow comes, and the solution for tomorrow's problem has been decided on, yes, today's solution might need altering. But so might so many others. That is part of developing solutions in lively project.
IMHO, when we do go to a patchless server and still need ldiskfs (i.e. because we cannot get ext* upstream to accept the patches that make ext4 linto diskfs), it's probably time for ldiskfs to be maintained as a standalone module built as a kmod and/or with DKMS. In the kmod case, hopefully we could get the module kABI compliant so that it doesn't need to keep being rebuilt for successive RHEL minor releases.
you said
This is not for building patched servers. It's for building the patchless client.
As I understand it future plans call for building unpatched servers too. Building any server, patched or unpatched, calls for building ldiskfs. Any build of ldiskfs requires ext4 source.
Don't think this particular patch is good or useful.
Have you ever built Lustre in a "clean-room" (i.e. with mock)? That's one case where it's useful.
To be contrarian, does adding another element to the list of places searched for kernel source cause any harm?
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's not actually. Even in the case of there being multiple entries in /usr/src/kernels/ – which I don't think is actually all that common at all for the use-cases that this patch is targeting – but in any case, it will pick the highest versioned kernel, which seems like the least surprising choice to me. If that is not what the user wants, then he can still use --with-linux to point at the one he wants, but using the most recent seems like a reasonable default when all other selection mechanisms have been exhausted.
It isn't the case that there is only one most of the time.
Even in environments where all of the other search locations have not found kernel source? I am doubtful that your assertion is true. I suspect environments that this patch is targeting are few and are particular, typically about clean-room isolated build environments.
If you must pick from there it would be better to first look for a match on 'uname -r',
As has been discussed previously in this ticket, if there was a match for $(uname -r) then the targeted kernel is what would be installed and booted already and the /lib/modules/$(uname -r)/{build,source} symlinks would be present. This patch is specifically targeting build environments where the booted kernel (the one that responds to $(uname -r)) is not the kernel you want to build for in your build chroot.
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.
In a "clean-room" build system (or BaaS – Builder as a Service) you are usually not allowed to mess with the "clean" room.
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
This is not for building patched servers. It's for building the patchless client.
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:
Bah. Good catch. That was due to an unfortunate nastiness with m4 macros. I've updated the patch. Now I get this:
$ ./configure --disable-server ... checking whether to build Lustre client support... yes checking whether mpitests can be built... no checking whether to build Linux kernel modules... yes (linux-gnu) checking for Linux sources... /usr/src/kernels/3.10.0-514.26.2.el7.x86_64 checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64... yes checking for Linux objects... /usr/src/kernels/3.10.0-514.26.2.el7.x86_64 checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/.config... yes checking for /boot/kernel.h... no checking for /var/adm/running-kernel.h... no checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/generated/autoconf.h... yes checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/linux/version.h... no checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/generated/uapi/linux/version.h... yes checking for /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/linux/kconfig.h... yes
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.
That's not how the code reads:
for DEFAULT_LINUX in /lib/modules/$(uname -r)/{source,build} /usr/src/linux $(find /usr/src/kernels/ -maxdepth 1 -name [0-9]\* | xargs -r ls -d | tail -n 1); do AS_IF([readlink -q -e $DEFAULT_LINUX >/dev/null], [break]) done
That says to iterate through the list of /lib/modules/$(uname -r)/{source,build} /usr/src/linux $(find /usr/src/kernels/ -maxdepth 1 -name [0-9]* | xargs -r ls -d | tail -n 1) and stop (break) when a list item is valid. If /usr/src/linux is not valid, whatever $(find /usr/src/kernels/ -maxdepth 1 -name [0-9]* | xargs -r ls -d | tail -n 1) evaluates to will be tried next.
I believe the logic to look at /usr/src/linux is there to cater to SLES installs. In SLES /usr/src/linux is a symlink to the linux tree corresponding to the boot kernel.
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:
./configure --disable-server . . . checking whether to build Lustre client support... yes checking whether mpitests can be built... yes checking whether to build Linux kernel modules... yes (linux-gnu) checking for Linux sources... /usr/src/linux checking for /usr/src/linux... no configure: error: Kernel source /usr/src/linux could not be found.
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
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
removed unrelated gerrit upload message