Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
None
-
None
-
3
-
10447
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.