[LU-1272] lbuild-sles11 and kernel versioning

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Michael MacDonald (Inactive)
• Assignee: WC Triage
• Resolution: Fixed
• Severity: 3

Description

Sometimes the version/release string in SLES kernel RPMs doesn't match the version of the kernel they're associated with.

Case in point:

-rw-r--r-- 1 jenkins jenkins 10081544 2011-04-15 01:38 kernel-default-base-2.6.32.36-0.5.2.x86_64.rpm
-rw-r--r-- 1 root    root     2513871 2011-04-15 01:38 kernel-default-devel-2.6.32.36-0.5.2.x86_64.rpm
-rw-r--r-- 1 jenkins jenkins 72416640 2011-04-15 00:29 kernel-source-2.6.32.36-0.5.2.x86_64.rpm

The rpm %version is 2.6.32.36 and the %release is 0.5.2. The kernel /inside/ the kernel source RPM is versioned 2.6.32.36-0.5, and the source directory reflects this:

/var/lib/jenkins/workspace/lustre-reviews/arch/x86_64/build_type/client/distro/sles11/ib_stack/inkernel/BUILD/reused/usr/src/linux-2.6.32.36-0.5

This mismatch plays merry havoc with lbuild's ability to find the RPMs it needs to build lustre. It also seems to have caused confusion over on the provisioning side of things (TT-468).

Ideally, all of our code which deals with SLES kernels should be updated to deal with this crazy situation, because if it happened once it may happen again (who knows, it's SLES, maybe they always do it this way because ... it's SLES). As a simple workaround, we could try to find a kernel which doesn't have this ridiculous mismatch and standardize on it.

Comments

[Brian Murrell (Inactive)]

There is code in lbuild already to try to deal with this. It was landed in 16d51ff27b719f8ba31b18e64d9878843266fa8c. That patch only dealt with the SRPM however. It seems now that SUSE are now also playing games with the names of the binary RPMs that are produced from that SRPM.

[Michael MacDonald (Inactive)]

I've also created LU-1273 to describe an enhancement to lbuild-sles11 which would allow it to download kernel packages automatically rather than requiring manual intervention. This comment should also serve as a breadcrumb for someone looking to find out how to get at SLES kernel packages.