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-10858 Lustre <p>This issue was created by maloo for James Nunez &lt;james.a.nunez@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="https://testing.hpdd.intel.com/test_sets/199f17d0-3149-11e8-b74b-52540065bddc" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/199f17d0-3149-11e8-b74b-52540065bddc</a></p> <p>lustre-initialization failed with the following error:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>'lustre-initialization failed' </pre> </div></div> <p>&lt;&lt;Please provide additional information about the failure here&gt;&gt;<br/> Looking at the autotest log, we see that the Lustre tests are not installed</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>2018-03-26T21:56:49 trevis-18vm1: /usr/lib64/lustre/tests/cfg/: No such file or directory 2018-03-26T21:56:49 pdsh@trevis-18vm1: trevis-18vm1: ssh exited with exit code 1 2018-03-26T21:56:49 trevis-18vm3: /usr/lib64/lustre/tests/cfg/: No such file or directory 2018-03-26T21:56:49 pdsh@trevis-18vm1: trevis-18vm3: ssh exited with exit code 1 2018-03-26T21:56:49 trevis-18vm4: /usr/lib64/lustre/tests/cfg/: No such file or directory 2018-03-26T21:56:49 pdsh@trevis-18vm1: trevis-18vm4: ssh exited with exit code 1 2018-03-26T21:56:49 trevis-18vm2: /usr/lib64/lustre/tests/cfg/: No such file or directory 2018-03-26T21:56:49 pdsh@trevis-18vm1: trevis-18vm2: ssh exited with exit code 1 </pre> </div></div> <p>Yet, looking at the node console logs, I don’t see any failure relating to loading RPMS. Looking at the console logs for all the nodes, they all end with </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Welcome to SUSE Linux Enterprise Server 12 SP3 (x86_64) - Kernel 4.4.114-94.11-default (ttyS0). trevis-18vm2 login: [ 80.209414] random: nonblocking pool is initialized &lt;ConMan&gt; Console [trevis-18vm2] disconnected from &lt;trevis-18:6001&gt; at 03-26 22:56. </pre> </div></div> <p>This failure started with master build #3731.</p> <p>Another test session that failed in this way is at<br/> <a href="https://testing.hpdd.intel.com/test_sessions/fb84aaa9-888e-4d17-9a76-1cfd67d415aa" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sessions/fb84aaa9-888e-4d17-9a76-1cfd67d415aa</a></p> <p>VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV<br/> lustre-initialization-1 lustre-initialization - 'lustre-initialization failed'</p> LU-10858

lustre-initialization-1 lustre-initialization fails for SLES12 SP2 and SP3

Bug Minor Resolved Fixed Bob Glossman Maloo Tue, 27 Mar 2018 18:45:59 +0000 Thu, 29 Mar 2018 21:00:03 +0000 Thu, 29 Mar 2018 21:00:03 +0000 Lustre 2.11.0 0 8 <p>Test to see if reverting <a href="https://jira.whamcloud.com/browse/LU-10556" title="lustre client rebuild not building lnetctl" class="issue-link" data-issue-key="LU-10556"><del>LU-10556</del></a> patch <a href="https://review.whamcloud.com/#/c/31710/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/31710/</a> will fix this issue.</p> <p>Revert patch at <a href="https://review.whamcloud.com/#/c/31800/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/31800/</a></p> <p>Bob</p> <p>Can you please investigate?</p> <p>Peter</p> <p>Really? That is just adding in build requirements when building from the lustre source rpms. Are those rpms named differently on SLES12SP4?</p> <p>yes, this is a problem with naming conventions.<br/> In RHEL the user level libyaml .rpm is named "libyaml" and Provides the symbol libyaml<br/> in SLES the user level libyaml .rpm is named "libyaml-0-2" and has no Provides of the name "libyaml". It only Provides the symbol "libyaml-0-2"</p> <p>would suggest removing the dependency this mod just added.</p> <p>Yes, James.<br/> I just found 'zlib' package was named as 'libz1' on SLES 12.</p> <p>Oh crap. At least it is a easy fix. Its still zlib-devel tho?</p> <p>the zlib dependency isn't a problem. the SLES .rpm libz1 has a Provides for the name "zlib"</p> <blockquote><p>Its still zlib-devel tho?</p></blockquote> <p>Yes. It's still zlib-devel.</p> <p>-devel .rpms are fine. both libyaml-devel &amp; zlib-devel exist in both RHEL and SLES.<br/> I question the strategy of enforcing this in the .spec file though.<br/> I thought there are already autoconf tests to check for and enforce the right build environment in these cases.</p> <p>Its about pulling in the right rpms when you install a lustre binary rpm. Currently you can install rpm a prepackage lustre rpm on a system that could be lacking libyaml and/or libzlib. In that case you think it installed right but then when you go to run it you see a nice crash. Using yum you can grab libyaml and zlib when installing lustre binary rpm with this patch.</p> <p>wasn't questioning the additional Requires, although if you want that it will need to be conditional due to the different names in different distros.<br/> I was questioning the need for added Build-Requires.</p> <blockquote><p>I was questioning the need for added Build-Requires.</p></blockquote> <p>Since the package names of libyaml-devel and zlib-devel are both correct on RHEL and SLES, I wonder if the following line in lustre.spec.in can cause any issue:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>BuildRequires: libtool libyaml-devel zlib-devel </pre> </div></div> <p>Since the names are the same I don't see any harm.<br/> I just question the need for it at all.<br/> I'm of the "if it's not broke, don't fix it" school of thought.</p> <p>The BuildRequires were added to make people use use mock and other build system like that happy.  FOr somethingf like mock you drop in the source rpm which will use BuildRequires to pull down the needed development rpms to build the packages.</p> <p>libtool appears to the same. The issues is the logs from the failure are pretty useless. Do you have something better?</p> <p> </p> <p>if having the extra BuildRequires makes mock behave better I have no major objection.<br/> for manual builds I have found examining the config.log of failed builds usually gives enough clues to figure it out.</p> <p>If you insist on in I suggest something like the following to adapt to different names:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>--- a/lustre.spec.in +++ b/lustre.spec.in @@ -81,12 +81,14 @@ %global modules_fs_path /lib/modules/%{kversion}/%{kmoddir} %if %{_vendor}=="redhat" || %{_vendor}=="fedora" + %global requires_yaml_name libyaml %global requires_kmod_name kmod-%{lustre_name} %if %{with lustre_tests} %global requires_kmod_tests_name kmod-%{lustre_name}-tests %endif %global requires_kmod_version %{version} %else #for Suse + %global requires_yaml_name libyaml-0-2 %global requires_kmod_name %{lustre_name}-kmp %if %{with lustre_tests} %global requires_kmod_tests_name %{lustre_name}-tests-kmp @@ -132,7 +134,8 @@ Source6: kmp-lustre-osd-zfs.files Source7: kmp-lustre-tests.files URL: https://wiki.hpdd.intel.com/ BuildRoot: %{_tmppath}/lustre-%{version}-root -Requires: %{requires_kmod_name} = %{requires_kmod_version} libyaml zlib +Requires: %{requires_kmod_name} = %{requires_kmod_version} zlib +Requires: %{requires_yaml_name} BuildRequires: libtool libyaml-devel zlib-devel %if %{with servers} Requires: lustre-osd </pre> </div></div> <p>I don't say this is the best fix, but I think it will work.</p> <p>Hi Bob,<br/> For SLES 11, the package name is 'zlib'. And for SLES 12, the name is 'libz1'.</p> <p>Don't think the exact package name matters. As long as the .rpm has a Provides of "zlib" in it, it will be found and installed if required as a dependency.</p> <p>In any case support for SLES11 has been stopped or is going to be going away soon on master.</p> <p>Actually that fix looks good Bob. I'm going to try it.</p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/31815" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/31815</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10858" title="lustre-initialization-1 lustre-initialization fails for SLES12 SP2 and SP3" class="issue-link" data-issue-key="LU-10858"><del>LU-10858</del></a> build: handle yaml library packaging on SLES systems<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: fc4a9793c5ef2a3abd260474fc9f9dc2e9102673</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/31815/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/31815/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10858" title="lustre-initialization-1 lustre-initialization fails for SLES12 SP2 and SP3" class="issue-link" data-issue-key="LU-10858"><del>LU-10858</del></a> build: handle yaml library packaging on SLES systems<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 20ad3ed15c321c7740988728c49a97105c59a3c4</p> <p>Landed for 2.11</p> Related LU-10556 Development Rank 1|hzzuvj: Rank (Obsolete) 9223372036854775807 Severity