[LU-8519] build is broken on sles12 Created: 19/Aug/16 Updated: 08/Oct/16 Resolved: 08/Oct/16 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.9.0 |
| Fix Version/s: | Lustre 2.9.0 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Bob Glossman (Inactive) | Assignee: | Minh Diep |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
I don't know when it broke, but currently server builds on sles12 generate .rpm packages that can't install without --nodeps or --force. The problem appears to be with the Provides and Requires strings in the various kmp packages. They don't match. I'm guessing it's been broken for a while and just hasn't been noticed. Maybe not noticed because we seldom test with sles12 server builds or maybe our test framework installs with --force options or something. Here is what I see in packages from a recent sles12 server build in lustre-reviews: rpm -q --provides -p lustre-kmp-default-2.8.56_34_gf7472b3_k3.12.60_52.54-1.x86_64.rpm | grep lustre-kmp rpm -q --requires -p lustre-osd-ldiskfs-kmp-default-2.8.56_34_gf7472b3_k3.12.60_52.54-1.x86_64.rpm | grep lustre-kmp Note the Requires string has '41_lustre' on the end and the Provides string has '_52.54'. They don't match at all. I'm guessing this has something to do with one of the many recent changes in the lustre.spec.in file. |
| Comments |
| Comment by Bob Glossman (Inactive) [ 19/Aug/16 ] |
|
the current kernel version of sles12 is supposed to be 3.12.59-60.41 looks like rpm names are kind of mashed up too. |
| Comment by Bob Glossman (Inactive) [ 19/Aug/16 ] |
|
I'm guessing the 'k3.12.60_52.54' showing up in some strings and package names is coming from the kernel version of the kernel running on the sles builder, not the kernel version of the kernel in lustre's '--with-linux=' configure option. I note that I can see quite varying package names even in client builds. for example lustre-client-kmp-default-2.8.56_42_g7ac162e_k3.12.57_60.35-1.x86_64.rpm in That has '3.12.57' in the name, even farther from what I think should be there. |
| Comment by Christopher Morrone [ 20/Aug/16 ] |
|
The lustre source code and the %kernel_module_package macro used by the lustre.spec file determine which kernel to compile against using different methods. For RHEL-like systems we override a variable that used internally in RHEL's kernel_module_package macro: 26 # We set this because kernel_module_package has its own method of identifying
27 # which kernel to build against, and it is unlikely that its decision will
28 # match with Lustre's method of selecting which kernel to build against.
29 # By setting this variable, we override kernel_module_package's kernel
30 # selection with our selection.
31 %{!?kernel_version: %global kernel_version %kversion}
We get away with this kludge because the RHEL kernel_module_package does this: %{!?kernel_version:%{expand:%%global kernel_version %{latest_kernel}}}
That allows kernel_version to be predefined elsewhere (by us in this case), overriding the function's own logic. This is also probably a problem largely created by lbuild. Because lbuild doesn't install Lustre prerequisites like the kernel packages in their proper location, none of the standard system rpm packaging tools will be able to find it. SLES's kernel_module_package does not seem to have the same easy kernel_version override like RHEL's kernel_module_package. It is probably going to be tricky to fix this in lbuild. |
| Comment by Gerrit Updater [ 13/Sep/16 ] |
|
Minh Diep (minh.diep@intel.com) uploaded a new patch: http://review.whamcloud.com/22484 |
| Comment by Gerrit Updater [ 08/Oct/16 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/22484/ |
| Comment by Peter Jones [ 08/Oct/16 ] |
|
Landed for 2.9 |