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-1559 Lustre <p>When trying to update an EL 6.2 system with the Whamcloud e2fsprogs release 1.42.3.wc1-7.el6 only the e2fsprogs and e2fsprogs-libs packages actually get updated:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">Resolving Dependencies --&gt; Running transaction check ---&gt; Package e2fsprogs.x86_64 0:1.41.12-11.el6 will be updated ---&gt; Package e2fsprogs.x86_64 0:1.42.3.wc1-7.el6 will be an update --&gt; Processing Dependency: e2fsprogs-libs = 1.42.3.wc1-7.el6 <span class="code-keyword">for</span> <span class="code-keyword">package</span>: e2fsprogs-1.42.3.wc1-7.el6.x86_64 --&gt; Running transaction check ---&gt; Package e2fsprogs-libs.x86_64 0:1.41.12-11.el6 will be updated ---&gt; Package e2fsprogs-libs.x86_64 0:1.42.3.wc1-7.el6 will be an update --&gt; Finished Dependency Resolution Dependencies Resolved =========================================================================================================================================== Package Arch Version Repository Size =========================================================================================================================================== Updating: e2fsprogs x86_64 1.42.3.wc1-7.el6 chroma 695 k Updating <span class="code-keyword">for</span> dependencies: e2fsprogs-libs x86_64 1.42.3.wc1-7.el6 chroma 157 k </pre> </div></div> <p>This results in a broken e2fsck, mke2fs (and probably other tools):</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"># e2fsck e2fsck: symbol lookup error: e2fsck: undefined symbol: set_com_err_gettext # mke2fs mke2fs: symbol lookup error: mke2fs: undefined symbol: set_com_err_gettext </pre> </div></div> <p>This appears to be because the packaging is not specifying the upgrade of libcom_err as being necessary. When I manually force that package to be upgraded e2fsck and mke2fs work again:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"># e2fsck Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume <span class="code-quote">"yes"</span> to all questions -c Check <span class="code-keyword">for</span> bad blocks and add them to the badblock list -f Force checking even <span class="code-keyword">if</span> filesystem is marked clean -v Be verbose -b superblock Use alternative superblock -B blocksize Force blocksize when looking <span class="code-keyword">for</span> superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list [root@localhost yum.repos.d]# mke2fs Usage: mke2fs [-c|-l filename] [-b block-size] [-C cluster-size] [-i bytes-per-inode] [-I inode-size] [-J journal-options] [-G flex-group-size] [-N number-of-inodes] [-m reserved-blocks-percentage] [-o creator-os] [-g blocks-per-group] [-L volume-label] [-M last-mounted-directory] [-O feature[,...]] [-r fs-revision] [-E extended-option[,...]] [-t fs-type] [-T usage-type ] [-U UUID] [-jnqvDFKSV] device [blocks-count] </pre> </div></div> <p>Ultimately it appears that between 1.41.12 1.42.3 the ABI of libcom_err has changed. Such a change should force an increase in the version of the shared library which will in turn tell yum and rpm to upgrade libcom_err when it upgrades e2fsprogs.</p> e2fsprogs 1.42.3.wc1-7.el6 LU-1559

e2fsprogs doesn't properly update on EL 6.2 systems

Bug Major Resolved Fixed Andreas Dilger Brian Murrell Sat, 23 Jun 2012 14:44:54 +0000 Thu, 16 Aug 2012 12:25:27 +0000 Thu, 9 Aug 2012 05:37:41 +0000 Lustre 2.1.0 0 2 <p>Brian, what command did you use to upgrade the e2fsprogs packages? I had done it myself with "rpm -Fvh <b>1.42.3</b>", which of course included libcom_err explicitly.</p> <p>Should we add a "Requires: libcom_err &gt;= 1.42.3.wc1" in the .spec file for e2fsprogs?</p> <blockquote> <p>Brian, what command did you use to upgrade the e2fsprogs packages?</p></blockquote> <p>I created a yum repository from them with createrepo. In doing so, yum analyses all of the requires/provides to ensure sure that dependencies are met. This is where the problem started. Because the version of the libcom_err library did not get bumped the one installed by the stock EL packages met the dependency of the WC e2fsprogs, when it appears that the libraries are not in fact ABI compatible. Such a change usually necessitates the bumping of the shared libraries version. I guess that didn't happen.</p> <blockquote> <p>I had done it myself with "rpm -Fvh 1.42.3", which of course included libcom_err explicitly.</p></blockquote> <p>Indeed.</p> <blockquote> <p>Should we add a "Requires: libcom_err &gt;= 1.42.3.wc1" in the .spec file for e2fsprogs?</p></blockquote> <p>Well, that would work, but it's a bit of a hack IMHO. It would be better if the shared library was just versioned properly which would help rpm/yum do it's job properly.</p> <p>What is interesting is that the versioning of shared libs is something that really ought to be done by a given package's build system. So the question is did an ABI change get leaked out of the upstream e2fsprogs project without a version bump?</p> <p>Can you reassign as appropriate?</p> <p>I've just installed e2fsck RPMs from Master build. Previously I needed to include <tt>libcom_err</tt> <tt>libss</tt> from build.whamcloud.com, but now I don't.</p> <p>I might be tempted to say that this problem has been fixed - but I would like a second opinion.</p> <p>If you previously upgraded your e2fsprogs to 1.42.x then the proper libcom_err is already installed and doesn't need to be upgraded again.</p> <p>I have a patch for adding the trivial Requires: line, but don't recall if it has been submitted yet. I think it is still tied up in my rebase to 1.42.4. A separate patch to add this would also be easily done. </p> <p>While an explicit Requires: sounds like it probably will work (around the problem), it doesn't sound like it's addressing the root problem which seems to be a lack of proper version incrementation of the shared libs. This sounds like something that should have been done upstream. It seems like it would be worthwhile investigating this and getting upstream to fix if my suspicion is correct.</p> <p>For now I've added "Requires: libcom_err &gt;= 1.42.2" to the RHEL6 .spec file, since I'm only making minimal changes for the 1.42.3.wc3 release.</p> <p>I'm reluctant to change the version of the library itself, otherwise this will potentially cause errors with upstream version changes.</p> <p>Andreas,</p> <p>I don't want to beat a dead horse, but my concern here is that upstream <b>should</b> be bumping the DSO version and they are not. i.e. something's fallen between the cracks.</p> <p>Can we get an opinion from upstream whether the DSO should in fact be bumped or not?</p> <p>Some interesting discussion with Ted on (and off) the ext4 devel list yields that while bumping the DSO would solve the problem for RPM's packaging, it would cause other problems and is strictly not necessary for the purposes of versioning DSOs. Indeed, Ted points out how Debian's package manager, dpkg, gets this right, and automagically. It effectively automates the solution that was applied in this ticket and specifies a "Depends: " on the DSO needed.</p> <p>The parallel effect in RPM, unfortunately has to be done manually &#8211; exactly as Andreas has mentioned he did two comments ago.</p> <p>What is still interesting though is that looking at the most recent RHEL6 e2fsprogs.spec from e2fsprogs-1.41.12-12.el6.src.rpm, they actually do specify this dependency manually already:</p> <p>Requires: libcom_err = %</p> {version}-%{release}<br/> Requires: libss = %{version} <p>-%</p> {release} <p>for the e2fsprogs main package, and other dependencies on libcom_err for other subpackages which our e2fsprogs-RHEL-6.spec<span class="error">&#91;.in&#93;</span> doesn't have.</p> <p>Perhaps it's worthwhile to do a refresh on our e2fsprogs-RHEL-6.spec<span class="error">&#91;.in&#93;</span> against the latest RHEL 6 spec.</p> Development Rank 1|hzvgtb: Rank (Obsolete) 6373 Severity