[LU-5614] use %kernel_module_package for weak-updates

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.9.0
• Labels: llnl patch
• Severity: 3
• Assignee: Minh Diep
• Reporter: Stephen Champion

Description

The correct way to support weak-updates in rpm packages is the vendor defined %kernel_Module_package. This does the right thing on all distributions.

We have used this feature in SGI Lustre for several years, and I plan to work this feature back into the master branch.

Issue Links

• is blocking: LU-7643 Remove kernel version string from Lustre release field
• is related to: LU-8343 build failures on SLES
• is related to: LU-8519 build is broken on sles12
• is related to: LU-8383 Wrong tests package dependencies
• is related to: LU-6677 Package lustre correctly for Fedora/RHEL
• is related to: LU-7722 Install/uninstall of Lustre RPMs is slow due to regenerating of initramfs
• is related to: LU-8377 lustre fail to build on el7
• is related to: LU-3956 Eliminate lbuild's nonstandard build process
• is related to: LU-3953 lustre build system improvments

Comments

[Minh Diep]

it worked on el7. I'll verify on el6 as you did next

[root@onyx-21vm5 lustre-release]# uname -a
Linux onyx-21vm5.onyx.hpdd.intel.com 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
sh ./autogen.sh
./configure --disable-server --with-linux=/usr/src/kernels/3.10.0-327.18.2.el7.x86_64/
make rpms

scp kmod-lustre-client-2.8.54_61_gcc7a8c9-3.10.0_327.18.2.el7.x86_64.x86_64.rpm root@onyx-24:/root
scp lustre-client-2.8.54_61_gcc7a8c9-3.10.0_327.18.2.el7.x86_64.x86_64.rpm root@onyx-24:/root

[root@onyx-24 ~]# uname -a
Linux onyx-24.onyx.hpdd.intel.com 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@onyx-24 ~]# rpm -hiv ./kmod-lustre-client-2.8.54_61_gcc7a8c9-3.10.0_327.18.2.el7.x86_64.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:kmod-lustre-client-2.8.54_61_gcc7################################# [100%]
[root@onyx-24 ~]# modprobe lustre
[root@onyx-24 ~]# modinfo lustre
filename: /lib/modules/3.10.0-327.18.2.el7.x86_64/extra/lustre-client/fs/lustre.ko
license: GPL
version: 2.8.54_61_gcc7a8c9
description: Lustre Client File System
author: OpenSFS, Inc. <http://www.lustre.org/>
rhelversion: 7.2
srcversion: F6CD34A134CF6E45A10B0DB
depends: obdclass,ptlrpc,libcfs,lnet,lmv,mdc,lov
vermagic: 3.10.0-327.18.2.el7.x86_64 SMP mod_unload modversions
[root@onyx-24 ~]#

[James A Simmons]

So I created the most basic test to show the problem. This is with building just the patchless client. Currently our build machine is at RHEL6.7 and my test node is running RHEL6.8. So we have very different kernels running on both. On the build machine I as non-root installed the RHEL6.8 development tree in /tmp so I have /tmp//usr/src/kernels/2.6.32-642.1.1.el6.x86_64. Then I went into my lustre tree containing this patch and did:

cd lustre_release
./autogen.sh
./configure --disable-server --with-linux=/tmp/usr/src/kernels/2.6.32-642.1.1.el6.x86_64
make rpm

Then I went to install the rpms into the image and got the ksyms errors still. This points to the current patch for LU-5614 breaks --with-linux for configure. Note this is very common process our admins use to prepare our client rpms. You can say well just build on the local node. In that case the patch for LU-5614 need to be updated to remove --with-linux support. Also if you recommend using mock to work around this problem then please update this patch to ensure configure failed unless ./configure runs in a mock environment and the source rpm has a hard dependency on mock. In any case I have a reproducer of this problem.

[James A Simmons]

No the target kernel rpm is not installed on the build system. That would be a big no no since the machine is used for other purposes. The target kernel source tree is installed in a special directory which is not /usr/src to build against. I will be looking into why the dependency generation is done against the wrong kernel. I wonder if we have to do a OFED style build process in which we tell the location of the symver.

[Stephen Champion]

Is the target kernel installed on the build system (or environment)?
Can you verify that dependency generation is done with the right kernel?

[James A Simmons]

Remove --without kabichk and still gives me the ksym issues.

[James A Simmons]

Nope, but looking at how I build our kernel I might know why. When building the kernel rpm I used --without kabichk. Would that be the reason it doesn't work? This is all done using RHEL6.7.

[Minh Diep]

James, are you able to build and install it. Please let me know if you have any problem. if not could you re-review that patch?

[James A Simmons]

Okay, for some reason my initial build didn't produce the kmod-* rpms. I had to delete the source tree and do it over again. Now I see

ksym(snprintf) = 0x9edbecae is needed by kmod-lustre-2.8.54_60_g2a55f34_dirty-2.6.32_573.12.1.el6.head.x86_64.x86_64
ksym(sscanf) = 0x42224298 is needed by kmod-lustre-2.8.54_60_g2a55f34_dirty-2.6.32_573.12.1.el6.head.x86_64.x86_64
....

When I go to install kmod-lustre-*.x86_64.rpm

[Stephen Champion]

Thank you for picking this up and following through with it.

My complaint is that I'm still the owner and can't give you a +1!

Edit: I won't bother nitpicking changes to lbuild.

[Bob Glossman (Inactive)]

James,
If you carefully read the commit header it says how the packages have been renamed.

[James A Simmons]

I just tried the latest patch and I don't see lustre-module-* anymore. Is this expected?

I also tried installing them RPMs and got:

rpm Uvh --force tmp/RPMS/lustre/lustre*
error: Failed dependencies:
kmod-lustre = 2.8.54_60_g2a55f34_dirty is needed by lustre-2.8.54_60_g2a55f34_dirty-2.6.32_573.12.1.el6.head.x86_64.x86_64
kmod-lustre = 2.8.54_60_g2a55f34_dirty is needed by lustre-tests-2.8.54_60_g2a55f34_dirty-2.6.32_573.12.1.el6.head.x86_64.x86_64