https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5086 Lustre <p>During RPM creation on host incorrect dependencies from Phi kernel is included in host RPMs.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>kernel = 2.6.38.8+mpss3.2.1 </pre> </div></div> <p>This prevents install those RPMs on host without disabling dependency checking.</p> Xeon Phi LU-5086

Incorrect dependencies for Xeon Phi RPMs

Bug Major Closed Won't Fix Dmitry Eremin Dmitry Eremin Mon, 19 May 2014 14:45:27 +0000 Thu, 23 Jul 2015 16:53:18 +0000 Thu, 23 Jul 2015 16:53:18 +0000 Lustre 2.6.0 Lustre 2.5.1 0 5 <p>The patch is <a href="http://review.whamcloud.com/10364/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10364/</a></p> <p>Can you explain a bit why this happens as I don't see how/why the patch you propose fixes it.</p> <p>Agreed, more description needed in the patch.</p> <p>During RPM build the dependencies are automatically searched by rpmbuild according host configuration.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">%<span class="code-keyword">package</span> modules Summary: Kernel Lustre modules <span class="code-keyword">for</span> Linux %{kversion} %<span class="code-keyword">if</span> %{defined cross_requires} Requires: %{cross_requires} AutoReqProv: no %<span class="code-keyword">else</span> # <span class="code-keyword">for</span> SLES11, we need nothing here %<span class="code-keyword">if</span> %{_vendor}==<span class="code-quote">"redhat"</span> || %{_vendor}==<span class="code-quote">"fedora"</span> # <span class="code-keyword">for</span> 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 </pre> </div></div> <p>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.</p> <blockquote> <p>As you can see the kernel version from host will be found.</p></blockquote> <p>Not exactly. Yes, a <tt>kernel = $version</tt> requirement is added but that is not "auto search"ed. Rather <tt>$version</tt> comes from <tt>%krequires</tt> which is defined previously as:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>%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$//'") </pre> </div></div> <p>which is based on <tt>%kversion</tt> which itself is previously defined as:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>%{!?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)} </pre> </div></div> <p>Which is just a long/complicated way of saying that <tt>%kversion</tt> 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 <tt>%kversion</tt> comes out of instead of all of this <tt>%if %{defined cross_requires</tt>} hackery?</p> <blockquote> <p>I just disable this auto search for cross build because it's not able to find them correctly.</p></blockquote> <p>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.</p> <p>Sorry, the dependency of Phi RPM is the following:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>kernel = 2.6.38.8+mpss3.2.1 </pre> </div></div> <p>and when I install this RPM on <b>host</b> I got the error that kernel version is wrong because this version from Phi.</p> <p>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.</p> <p>I don't follow that last comment. We don't check runtime requirements during install time, neither <em>should</em> we check runtime requirements at install time.</p> <p>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.</p> <p>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.</p> Related Development Rank 1|hzwmr3: Rank (Obsolete) 14022 Severity