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-3173 Lustre <p>The problem is in AS_VERSION_COMPARE(<span class="error">&#91;$LINUXRELEASE&#93;</span>,<span class="error">&#91;2.6.32-343&#93;</span> in ldiskfs-build.m4. The result of string comparison of "2.6.32.lustremaster" and "2.6.32-343" give a great and series for rhel6.4 are chosen.</p> <p>The value of EXTRAVERSION in kernel Makefile should be chosen careful for subsequent string comparison or we need to change the code of series selection.</p> LU-3173

Incorrect detection of ldiskfs series to use

Bug Minor Resolved Fixed Dmitry Eremin Dmitry Eremin Mon, 15 Apr 2013 13:17:58 +0000 Mon, 4 Nov 2013 00:18:16 +0000 Thu, 11 Jul 2013 10:30:44 +0000 Lustre 2.5.0 Lustre 2.4.2 0 4 <p>The fix for selection of ldiskfs series to use is <a href="http://review.whamcloud.com/6056" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6056</a></p> <p>I sounds like the Lustre build of the Linux kernel is currently converting the upstream kernel string from 2.6.32-343 to 2.6.32.lustremaster. That new version string is kind of horrible. How about you just fix that?</p> <p>According <a href="https://wiki.hpdd.intel.com/display/PUB/Walk-thru-+Build+Lustre+MASTER+on+RHEL+6.3+from+Whamcloud+git" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/PUB/Walk-thru-+Build+Lustre+MASTER+on+RHEL+6.3+from+Whamcloud+git</a> we recommend to edit kernel sources Makefile and modify line 4:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>EXTRAVERSION = .lustremaster </pre> </div></div> <p>Therefore, the kernel version produced from those sources will be:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>#define UTS_RELEASE "2.6.32.lustremaster" </pre> </div></div> <p>So, we try to use this version as upstream kernel version. I don't know how we produce pre-built RPMs packages but WiKi recommendation about building Lustre master from git sources is not correct.</p> <p>Anyway we try to rely on string representation which is not a kernel version only. The kernel version is "2.6.32". The suffix "-358.2.1.el6" is a release.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ rpm -qi kernel Name : kernel Relocations: (not relocatable) Version : 2.6.32 Vendor: CentOS Release : 358.2.1.el6 Build Date: Wed 13 Mar 2013 05:35:54 AM MSK </pre> </div></div> <p>Now we use "AS_VERSION_COMPARE(<span class="error">&#91;$LINUXRELEASE&#93;</span>,<span class="error">&#91;2.6.32-343&#93;</span>," which is not robust as I mentioned above.</p> <p>In the current patch I try to use RHEL_RELEASE_CODE which is just encoding of RHEL_MAJOR and RHEL_MINOR. Probably we could use RHEL_RELEASE which is more precise. But anyway I think we should not rely on string which user can easily change with his custom version.</p> <blockquote><p>According <a href="https://wiki.hpdd.intel.com/display/PUB/Walk-thru-+Build+Lustre+MASTER+on+RHEL+6.3+from+Whamcloud+git" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/display/PUB/Walk-thru-+Build+Lustre+MASTER+on+RHEL+6.3+from+Whamcloud+git</a> we recommend to edit kernel sources Makefile and modify line 4</p></blockquote> <p>I would strongly recommend changing those instructions. Replacing the very useful release string from upstream with the very vague string ".lustremaster" is just bad advice.</p> <p>Case in point: <em>you</em> guys aren't following that advice! Check your kernel packages.</p> <p>LLNL certainly doesn't choose to rename our kernels that way, and never will.</p> <p>In summary, I think that using the version+release field is plenty robust, if we simply stop giving users bad advice about trashing the release field.</p> <p>The Version+Release string is simple and straight forward to understand. It is easy for a human to match up with rpm names.</p> <p>The Version+Release also more uniquely identifies a kernel. Multiple differing kernels can have the same RHEL_RELEASE_CODE, and that could be a problem for properly idenifying which patches are needed.</p> <p>Honestly, if a user is building their own kernel, they can quite easily change <em>any</em> of the numbers. Lets not worry about all of the crazy things people <em>might</em> do, and focus on the things we normally do.</p> <p>I don't propose to change this approach. I just would like to make this approach more stable regardless user changes.</p> <p>My patch #3 (<a href="http://review.whamcloud.com/6056" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6056</a>) just extract correct upstream kernel release for RHEL kernels and form it into $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)-$(RHEL_RELEASE). It's exactly Version+Release (2.6.32-358) format like you propose to follow without any additional info and it not depends from EXTRAVERSION which user can change.</p> <p>If EXTRAVERSION is not empty kernel script remove all RHEL release information from kernel version. So, user should carefully write the same RHEL release version as he see in original kernel package. It's not convenient I think. For example:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ rpm -qi kernel Name : kernel Relocations: (not relocatable) Version : 2.6.32 Vendor: CentOS Release : 358.2.1.el6 Build Date: Wed 13 Mar 2013 05:35:54 AM MSK # Therefore write to Makefile EXTRAVERSION = -358.2.1.el6_lustre </pre> </div></div> <p>Moreover the directory name with produced kernel will be <b>~/rpmbuild/BUILD/kernel-2.6.32358.2.1.el6_lustre.x86_64</b>. It looks confusing at least for me but user should use it in Lustre configure script.</p> <p>So, what is wrong with my #3 patch? Are you insist on WiKi change only?</p> <p>Yes, I think that a Wiki-only change is the appropriate fix for this problem. I don't see much value in the additional complexity that the patch introduces.</p> <p>Hi, Christopher, I think this change is needed. I have received many guys encountered issue when they are build kernel and lustre on local box. The version come from utsrelease.h is depend on environment. But RHEL_RELEASE is stable always. So i think we use it more reasonable.</p> <p>Isn't that because you guys are giving them bad instructions right now? With proper instructions, doesn't that problem go away?</p> <p>It obviously not. Not everyone build kernel from spec file. It also not necessary step. We haven't this problem in past, at least we should restore the behavior before.</p> <p>Additional drawback of approach to play with EXTRAVERSION only is incorrect specification of the kernel version for dependencies. For example, if I set the following in Makefile:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 32 EXTRAVERSION = -358.6.2.lum </pre> </div></div> <p>I will got a kernel RPM with following information:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Name : kernel Relocations: (not relocatable) Version : 2.6.32358.6.2.lum Vendor: The Linux Community Release : 1 Build Date: Tue 21 May 2013 04:24:59 PM MSK </pre> </div></div> <p>But a lustre-modules will required dependency from "kernel = 2.6.32-358.6.2.lum". So, additional thing we need to fix is "krequires" macro value from lustre.spec file.</p> <p>You know, more and more I think this is just completely the wrong approach to the problem. We are trying to do two things that are conceptually in conflict:</p> <ul> <li>Decide which patch series to apply based mainly on the kernel versions string (also looking at distro name).</li> <li>Allow the user to change the version string in ways that throw out needed version resolution.</li> </ul> <p>How about this instead: If a user wishes to change the kernel version number, they need to use a configure option to specify which patch set they wish to use. They chose to throw away information, so make them tell ldiskfs which patch set to use. Adding complexity to try to guess when they are making it hard for us seems counterproductive to me.</p> Related LU-3516 Development Rank 1|hzvo3r: Rank (Obsolete) 7733 Severity