Details
-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
3
-
15704
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.
Attachments
Issue Links
- is blocking
-
LU-7643
Remove kernel version string from Lustre release field
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
LU-6677 Package lustre correctly for Fedora/RHEL
-
- Closed
-
- is related to
-
-
- Open
-
-
-
- Resolved
-
-
-
- In Progress
-
-
LU-3953 lustre build system improvments
-
- Closed
-
- mentioned in
-
Page Loading...
Activity
The patch landed to master, so I closing this ticket. Good work everyone!
If there is any fallout that we need to work through, we can open new tickets for that.
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/12063/
Subject: LU-5614 build: use %kernel_module_package in rpm spec
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 3b7d27ea22faf1c6d0a37afa724fd9b5c3240322
I discovered the kabi-whitelist issues with the following error during the build process:
Finding Provides: /usr/lib/rpm/redhat/find-provides
KERNEL ABI COMPATIBILITY WARNING
The kernel ABI reference files (provided by kabi-whitelists) were not found.
No compatibility check was performed. Please install the kABI reference files
and rebuild if you would like to verify compatibility with kernel ABI.
Finding Requires: /usr/lib/rpm/redhat/find-requires
Once I installed kabi-whitelish and the rpms started to work. Also 'rpm qp --release kmod-lustre*' prints out
kernel(__wake_up) = 0x642e54ac
kernel(add_wait_queue) = 0x650fb346
kernel(copy_from_user) = 0x3302b500
kernel(default_wake_function) = 0xffd5a395
kernel(kfree) = 0x037a0cba
So its working correct now.
In reply to James from gerrit:
I don't modify any RHEL build scripts. Its a simple rpm extract source and build. Nothing fancy. Forcing people to require things like mock to just build client rpms is not going to go over well with sites.
No one is requiring special things like mock. We just require that, when building rpms, the prerequisite BuildRequires must actually be installed. This is a completely normal thing to expect in the rpm packaging world, and it is what all of the behind-the-scenes scripts from the distro assume will be the case. Most people will be able to meet that requirement, I think. To avoid installing the prerequisites, you have to replace system-provided behind-the-scenes scripts with your own. We did that for lbuild, despite how icky I felt doing it. 
. If you refuse to meet that simple, accepted requirement, you are free to hack up your own solution as well.
I just recommend mock for the places where you don't have access to a system where the BuildRequires are installed, or you don't have the permissions to install those packages. mock is designed exactly for those situations: it sets up a clean base chroot environment, and then installs only the packages required by the source rpm's BuildRequires.
If none of those things will work for people, they can always just download prebuilt binaries. The prebuilt binaries are going to work on a much wider set of kernels once they are no longer tied to one specific kernel version.
Yes, some adaptation of process will be necessary for some people. I know, change is hard. I totally feel your pain. The Lustre community has gotten very used to its oddball way of building and packaging. But that means that Lustre just flat out doesn't build through the standard tools of major distros like Fedora and RHEL. I think the advantage of supporting those standard methods vastly outweighs the short term pain we will feel as we adapt our personal processes to the new packaging methods.
Minh said:
we need to install kabi-whitelists rpm don't we?
That is not a requirement for this ticket. It probably won't hurt, but you can track that activity in a separate ticket if you like. It does not need to be linked to this issue.
I'm back from work travel, so I can jump back into the conversation now.
James, I don't believe that kernel-abi-whitelists is required on either RHEL6 or RHEL7. Yes, there will be a warning about it being missing at build time, but that doesn't hurt the packaging process. Clean RHEL6.7 and RHEL7.2 images have been my main testing platforms (with some SLES 12.X on occasion). I checked both of my RHEL images just now, and neither have kernel-abi-whitelists installed. The rpm packages generated under this patch install just fine, and appear to have all required kernel symbols expressed in the rpm --requires section.
By the way, if your packages really lists this:
ksym(snprintf) = 0x9edbecae ksym(sscanf) = 0x42224298
then there is an additional problem that I didn't remember off the top of my head on the road. Those should not be "ksym" requirements; they should be "kernel" requirements. I would check the package with "rpm -qp --requires" and see how they look. Here are the requirements from the kmod-lustre package on my RHEL6.7
system:
kernel(snprintf) = 0x9edbecae kernel(sscanf) = 0x42224298
A "kernel" requirement on RHEL means that the RH build system knows that the symbol is provided by the kernel package itself. Any other kernel symbol provided by some external package (e.g. zfs) will be a "ksym" requirement instead of "kernel". So this still implies that Lustre was not built on a system with the prerequisite kernel rpms properly installed.
FYI, SUSE does not have a kernel-abi-whitelists package. They do not even employ the approach of having a symbol whitelist.
I found the source of the problem. This change now requires the package kabi-whitelist at least for RHEL6. Do you have this package for RHEL7 and SLES as well? Once I installed kaki-whitelist it appears to work. Well ZFS still gives trouble but it might be a simple case of rebuilding it.
"Are you ssh into the destination node and then installing the rpm on that node?"
yes
I am not familiar with chroot. For diskless node, I know that LLNL Chaos built the image with the set of rpms, then refresh/boot the node. I'll have to look into chroot more; but I am pretty sure that's the difference and causing the issue.
Can you attach or upload your kmod-lustre-client rpm so I can check its content?
FYI:
http://cdn.opensfs.org/wp-content/uploads/2016/04/LUG2016D1_Improved-Versioning_Morrone_DiNatale.pdf
https://www.youtube.com/watch?v=50VN9Q7BHYA&index=5&list=PLA5dHg1_l3V8r6eqrUnl8DiB-KH1K5yLH