[LU-9775] find kernel-devel even if the current kernel is not installed in the build root Created: 14/Jul/17 Updated: 18/Aug/17 Resolved: 24/Jul/17 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.10.0 |
| Fix Version/s: | Lustre 2.10.1, Lustre 2.11.0 |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Brian Murrell (Inactive) | Assignee: | Brian Murrell (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Rank (Obsolete): | 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. |
| Comments |
| Comment by Gerrit Updater [ 14/Jul/17 ] |
|
Brian J. Murrell (brian.murrell@intel.com) uploaded a new patch: https://review.whamcloud.com/28046 |
| Comment by James A Simmons [ 14/Jul/17 ] |
|
/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. |
| Comment by Brian Murrell (Inactive) [ 14/Jul/17 ] |
Agreed, which is why I put it at the end of the search list.
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.
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? |
| Comment by Dmitry Eremin (Inactive) [ 14/Jul/17 ] |
|
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.
|
| Comment by Brian Murrell (Inactive) [ 14/Jul/17 ] |
|
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. |
| Comment by Gerrit Updater [ 17/Jul/17 ] |
|
Brian J. Murrell (brian.murrell@intel.com) uploaded a new patch: https://review.whamcloud.com/28064 |
| Comment by Bob Glossman (Inactive) [ 21/Jul/17 ] |
|
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. |
| Comment by Bob Glossman (Inactive) [ 21/Jul/17 ] |
|
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 |
| Comment by Bob Glossman (Inactive) [ 21/Jul/17 ] |
|
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. |
| Comment by Brian Murrell (Inactive) [ 21/Jul/17 ] |
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?
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.
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.
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 a "clean-room" build system (or BaaS – Builder as a Service) you are usually not allowed to mess with the "clean" room.
This is not for building patched servers. It's for building the patchless client.
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
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. |
| Comment by Bob Glossman (Inactive) [ 21/Jul/17 ] |
|
you said
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. |
| Comment by Brian Murrell (Inactive) [ 24/Jul/17 ] |
|
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. |
| Comment by Gerrit Updater [ 24/Jul/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/28064/ |
| Comment by Gerrit Updater [ 24/Jul/17 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/28046/ |
| Comment by Gerrit Updater [ 17/Aug/17 ] |
|
removed unrelated gerrit upload message |