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-8530 Lustre <p>This bad code was snuck into a "kernel update" patch, in commit 6c9384678f5555f87bcc7311bb5bf73b1e4bf4e4.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>case x$LDISKFS_SERIES in x) # not set ;; *.series) # set externally ;; *) LDISKFS_SERIES= esac AS_IF([test -z "$LDISKFS_SERIES"], [ </pre> </div></div> <p>Not even a comment in the commit message to explain it's existence, so I'm left to guess at what the author intended. But whatever was intended, this isn't the right way to go about it.</p> <p>I'll submit a patch to revert this section.</p> LU-8530

Bad configure code snuck into ldiskfs LDISKFS_LINUX_SERIES macro

Bug Minor Resolved Incomplete Yang Sheng Christopher Morrone Tue, 23 Aug 2016 22:45:23 +0000 Tue, 14 Dec 2021 22:12:38 +0000 Tue, 14 Dec 2021 22:12:38 +0000 0 6 <p>Christopher J. Morrone (morrone2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/22086" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/22086</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8530" title="Bad configure code snuck into ldiskfs LDISKFS_LINUX_SERIES macro" class="issue-link" data-issue-key="LU-8530"><del>LU-8530</del></a> config: Remove bad side-effect configuration<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c58b7654a31d4bc82d47205d97173c288c1e2b32</p> <p>Yang Sheng</p> <p>Could you please review this patch?</p> <p>Thanks</p> <p>Peter</p> <p>as the author that put this in I confess to it not being desirable. However it was the only expeditious method I could come up with to force the correct selection of ldiskfs series on sles12 builds in our test framework. With only a small set of sles12 build servers with varied versions of sles12 and distinct and different series for sles12 vs sles12sp1 needed a quick and dirty way to impose a specific selection regardless of the underlying running sles12 version.</p> <p>I don't understand that explanation. The ldiskfs series detection code just determines which kernel to apply a series to from whatever kernel Lustre decides to compile against as decided in the LB_LINUX_RELEASE. I can't imagine that you would want to select a series file for a kernel that is different than the kernel that Lustre is compiling against.</p> <p>LB_LINUX_RELEASE auto detects the kernel version being compiled against 100% correctly only in the case of RHEL. On SLES, and particularly on SLES12, it guesses the kernel version based oh the version running on the builder, not the version being compiled for. Needed a way to override that selection. It became an acute problem trying to build lustre for sles12sp1 on builder nodes installed with base sles12.</p> <p>I'm not sure that is quite right. Looking a little more closely, it works like this:</p> <p>LB_LINUX_RELEASE just needs to decide if the platform is SUSE. This pretty much has to work, or lots of things will go wrong in packaging.</p> <p>LDISKFS_LINUX_SERIES, if SUSE_KERNEL=yes, just uses $LINUXRELEASE to decide which series file to apply.</p> <p>LINUXRELEASE is set in LB_LINUX_UTSRELEASE based off of $LINUX_OBJ. I don't think $LINUX_OBJ can be wrong, or the whole build will probably fail.</p> <p>So where exactly do you see it failing?</p> <p>Are you seeing the "Cannot determine Linux kernel version." error message?</p> <p>in LDISKFS_LINUX_SERIES there is the following for the SUSE case:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> [LDISKFS_SERIES="3.0-sles11.series"],[ PLEV=$(grep PATCHLEVEL /etc/SuSE-release | sed -e 's/.*= *//') case $PLEV in 2) LDISKFS_SERIES="3.0-sles11.series" ;; 3|4) LDISKFS_SERIES="3.0-sles11sp3.series" ;; esac ])],[LDISKFS_SERIES="3.12-sles12.series"],[ PLEV=$(grep PATCHLEVEL /etc/SuSE-release | sed -e 's/.*= *//') case $PLEV in 1) LDISKFS_SERIES="3.12-sles12sp1.series" ;; *) LDISKFS_SERIES="3.12-sles12.series" ;; sac </pre> </div></div> <p>thus for recent sles11 and all sles12 it chooses the ldiskfs series based on the content of /etc/SuSE-release. This comes from the installed SLES on the builder, not the kernel version lustre is being compiled against.</p> <p>Hi, Christopher,</p> <p>Anyway, Your patch broken ability that set ldiskfs series directly. Sometime we need it in our build system.</p> <blockquote><p>Anyway, Your patch broken ability that set ldiskfs series directly. Sometime we need it in our build system.</p></blockquote> <p>Fine, then do it correctly. Add a configure option. This method is not acceptable.</p> <p>And frankly, I question whether it is <em>really</em> necessary in your build system, or whether folks just don't understand how to do it correctly. If you give me more details about the necessary situation I might be able add some additional insight.</p> <p>But if you really need a configure option, the correct way to do it is to actually add an option to configure. Sneaking it in through environment variables is a recipe for an unmaintainable build system.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>in LDISKFS_LINUX_SERIES there is the following for the SUSE case:</pre> </div></div> <p>Ah, I see. I don't imagine it would be too difficult to correct that. It should be obvious now, I hope, that just looking at the host distro is not going to be a correct method of identifying which patch series should be applied to the <em>kernel</em> against which Lustre is compiling. The configuration logic should really be looking at the kernel in question instead.</p> <p>I don't claim the selection rules for SUSE are 100% correct or even the proper way to do things. Looking back at history I gather that when we abandoned using kernel version directly for RHEL and switched to using RHEL_RELEASE_NO instead we looked for a way to divorce selections in SUSE from kernel version numbers at the same time. Selecting he series based on the SLES SP version of the install offered a way to do that. I believe it was intended as a heuristic rather than a perfectly correct method. It served well for that for years and only broke down at the time of the introduction of sles12sp1. would have been much better if we could have identified a direct analog of RHLE_RELEASE_NO for SLES, but we couldn't find one.</p> <blockquote><p>I gather that when we abandoned using kernel version directly for RHEL and switched to using RHEL_RELEASE_NO instead</p></blockquote> <p>I think that was a mistake too. I already opened ticket <a href="https://jira.whamcloud.com/browse/LU-8533" title="Problems with ldiskfs patch series selection logic" class="issue-link" data-issue-key="LU-8533">LU-8533</a> on that topic.</p> <blockquote><p>It served well for that for years and only broke down at the time of the introduction of sles12sp1.</p></blockquote> <p>It probably wasn't really sles12sp1 that is the problem so much as lbuild's weird build environment.</p> <blockquote><p> would have been much better if we could have identified a direct analog of RHLE_RELEASE_NO for SLES, but we couldn't find one.</p></blockquote> <p>The newer sles kernel doesn't have a newer kernel version? In other words do major releases of SLES have the same $LINUXVERSION?</p> Development Rank 1|hzylvz: Rank (Obsolete) 9223372036854775807 Severity