[LU-5086] Incorrect dependencies for Xeon Phi RPMs

• Status: Closed
• Project: Lustre
• Affects Version/s: Lustre 2.6.0, Lustre 2.5.1
• Type: Bug
• Priority: Major
• Reporter: Dmitry Eremin (Inactive)
• Assignee: Dmitry Eremin (Inactive)
• Resolution: Won't Fix

Environment

Xeon Phi

• Severity: 3

Description

During RPM creation on host incorrect dependencies from Phi kernel is included in host RPMs.

kernel = 2.6.38.8+mpss3.2.1

This prevents install those RPMs on host without disabling dependency checking.

Comments

[Dmitry Eremin (Inactive)]

The patch is http://review.whamcloud.com/10364/

[Brian Murrell (Inactive)]

Can you explain a bit why this happens as I don't see how/why the patch you propose fixes it.

[Christopher Morrone]

Agreed, more description needed in the patch.

[Dmitry Eremin (Inactive)]

During RPM build the dependencies are automatically searched by rpmbuild according host configuration.

%package modules
Summary: Kernel Lustre modules for Linux %{kversion}
%if %{defined cross_requires}
Requires: %{cross_requires}
AutoReqProv: no
%else
# for SLES11, we need nothing here
%if %{_vendor}=="redhat" || %{_vendor}=="fedora"
# for RHEL we need to require the specific kernel still since weak-modules
# support on RH is, well, weak, to be punny about it
Requires: kernel = %{krequires}
%endif
%endif

As you can see the kernel version from host will be found. I just disable this auto search for cross build because it's not able to find them correctly.

[Brian Murrell (Inactive)]

As you can see the kernel version from host will be found.

Not exactly. Yes, a kernel = $version requirement is added but that is not "auto search"ed. Rather $version comes from %krequires which is defined previously as:

%define krequires %(bash -c "echo %{kversion} | sed -e 's/\.x86_64$//' -e 's/\.i[3456]86$//' -e 's/-smp$//' -e 's/-bigsmp$//' -e 's/-ppc64$//' -e 's/-default$//'")

which is based on %kversion which itself is previously defined as:

%{!?kversion: %global kversion %(if test -s %kobjdir/include/generated/utsrelease.h ; then LINUXRELEASEHEADER=%kobjdir/include/generated/utsrelease.h ; elif test -s %kobjdir/include/linux/utsrelease.h ; then LINUXRELEASEHEADER=%kobjdir/include/linux/utsrelease.h ; else LINUXRELEASEHEADER=%kobjdir/include/linux/version.h; fi; sed -ne '/^#define UTS_RELEASE/s/.*"\\(.*\\)"$/\\1/p' $LINUXRELEASEHEADER)}

Which is just a long/complicated way of saying that %kversion is derived from the Linux kernel tree that was used to build Lustre. I don't know much about this Xeon Phi stuff, but it seems that there is a kernel for it that we are building Lustre against, right? Shouldn't it be that kernel tree that %kversion comes out of instead of all of this %if %{defined cross_requires} hackery?

I just disable this auto search for cross build because it's not able to find them correctly.

But the question is why not? I'm certainly willing to have it explained to me but it doesn't seem obvious at this point.

[Dmitry Eremin (Inactive)]

Sorry, the dependency of Phi RPM is the following:

kernel = 2.6.38.8+mpss3.2.1

and when I install this RPM on host I got the error that kernel version is wrong because this version from Phi.

[Dmitry Eremin (Inactive)]

The issue is we install the RPM in one place but a code work in other place. So, we cannot check runtime requirements during install because we don't know them.

[Christopher Morrone]

I don't follow that last comment. We don't check runtime requirements during install time, neither should we check runtime requirements at install time.

All of this sounds like Intel is packaging the Intel Phi environment rather brokenly. I wonder if perhaps Intel should then have to maintain out-of-Lustre-tree patches for its broken environment rather than dirtying up the build and packaging system of the Lustre community tree.

[Dmitry Eremin (Inactive)]

I agree that this is strange way to install packages on Phi. But it was only way originally before MPSS 3.0. In a new MPSS 3.x release they change build system completely. In this new build system RPMs for Phi produced for new architecture and should be installed directly on Phi card rather on host. Current solution is deprecated and for compatibility only. I'd like this way work until new build system will be supported and for compatibility with old releases.