[LU-1559] e2fsprogs doesn't properly update on EL 6.2 systems

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Type: Bug
• Priority: Major
• Reporter: Brian Murrell (Inactive)
• Assignee: Andreas Dilger
• Resolution: Fixed

Environment

e2fsprogs 1.42.3.wc1-7.el6

• Severity: 3

Description

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:

Resolving Dependencies
--> Running transaction check
---> Package e2fsprogs.x86_64 0:1.41.12-11.el6 will be updated
---> Package e2fsprogs.x86_64 0:1.42.3.wc1-7.el6 will be an update
--> Processing Dependency: e2fsprogs-libs = 1.42.3.wc1-7.el6 for package: e2fsprogs-1.42.3.wc1-7.el6.x86_64
--> Running transaction check
---> Package e2fsprogs-libs.x86_64 0:1.41.12-11.el6 will be updated
---> Package e2fsprogs-libs.x86_64 0:1.42.3.wc1-7.el6 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===========================================================================================================================================
 Package                             Arch                        Version                                 Repository                   Size
===========================================================================================================================================
Updating:
 e2fsprogs                           x86_64                      1.42.3.wc1-7.el6                        chroma                      695 k
Updating for dependencies:
 e2fsprogs-libs                      x86_64                      1.42.3.wc1-7.el6                       chroma                      157 k

This results in a broken e2fsck, mke2fs (and probably other tools):

# e2fsck
e2fsck: symbol lookup error: e2fsck: undefined symbol: set_com_err_gettext
# mke2fs 
mke2fs: symbol lookup error: mke2fs: undefined symbol: set_com_err_gettext

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:

# 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 "yes" to all questions
 -c                   Check for bad blocks and add them to the badblock list
 -f                   Force checking even if filesystem is marked clean
 -v                   Be verbose
 -b superblock        Use alternative superblock
 -B blocksize         Force blocksize when looking for 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]

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.

Comments

[Andreas Dilger]

Brian, what command did you use to upgrade the e2fsprogs packages? I had done it myself with "rpm -Fvh 1.42.3", which of course included libcom_err explicitly.

Should we add a "Requires: libcom_err >= 1.42.3.wc1" in the .spec file for e2fsprogs?

[Brian Murrell (Inactive)]

Brian, what command did you use to upgrade the e2fsprogs packages?

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.

I had done it myself with "rpm -Fvh 1.42.3", which of course included libcom_err explicitly.

Indeed.

Should we add a "Requires: libcom_err >= 1.42.3.wc1" in the .spec file for e2fsprogs?

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.

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?

[Jodi Levi (Inactive)]

Can you reassign as appropriate?

[Richard Henwood (Inactive)]

I've just installed e2fsck RPMs from Master build. Previously I needed to include libcom_err libss from build.whamcloud.com, but now I don't.

I might be tempted to say that this problem has been fixed - but I would like a second opinion.

[Andreas Dilger]

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.

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.

[Brian Murrell (Inactive)]

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.

[Andreas Dilger]

For now I've added "Requires: libcom_err >= 1.42.2" to the RHEL6 .spec file, since I'm only making minimal changes for the 1.42.3.wc3 release.

I'm reluctant to change the version of the library itself, otherwise this will potentially cause errors with upstream version changes.

[Brian Murrell (Inactive)]

Andreas,

I don't want to beat a dead horse, but my concern here is that upstream should be bumping the DSO version and they are not. i.e. something's fallen between the cracks.

Can we get an opinion from upstream whether the DSO should in fact be bumped or not?

[Brian Murrell (Inactive)]

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.

The parallel effect in RPM, unfortunately has to be done manually – exactly as Andreas has mentioned he did two comments ago.

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:

Requires: libcom_err = %

{version}-%{release}
Requires: libss = %{version}

-%

{release}

for the e2fsprogs main package, and other dependencies on libcom_err for other subpackages which our e2fsprogs-RHEL-6.spec[.in] doesn't have.

Perhaps it's worthwhile to do a refresh on our e2fsprogs-RHEL-6.spec[.in] against the latest RHEL 6 spec.