[#LU-407] RPM scriptlets broken because module name is not valid

[LU-407] RPM scriptlets broken because module name is not valid Created: 10/Jun/11 Updated: 04/Aug/11 Resolved: 04/Aug/11
Status:	Resolved
Project:	Lustre
Component/s:	None
Affects Version/s:	Lustre 2.1.0
Fix Version/s:	None

Type:

Bug

Priority:

Minor

Reporter:

Christopher Morrone

Assignee:

Brian Murrell (Inactive)

Resolution:

Fixed

Votes:

Labels:

None

Environment:

RHEL 6.1

Severity:

Rank (Obsolete):

4934

Description

The lustre-modules rpm is neither upgradeable nor uninstallable without forcing on RHEL6.1 (probably all redhat systems). In the %preun script the the name of the lustre-modules rpm is missing the architecture from the end of the name. The scriptlet does the following:

rpm -ql %{name}-modules-%{version}-%{release}

But rpm will only allow one of the following forms:

rpm -ql %{name}-modules
rpm -ql %{name}-modules-%{version}
rpm -ql %{name}-modules-%{version}-%{release}.%{_arch}

The %post script has the same problem, but the subsequent commands in the scripts hide the error code and allow the script to exit normally.

I am not sure why no one else noticed this, so I made a patch that only fixes this for %{_vendor}==redhat. But it may very well be needed on all architectures.

Comments

Comment by Christopher Morrone [ 10/Jun/11 ]

Example patch here:

http://review.whamcloud.com/934

I'm happy to update it to be the default behavior for all distros if that is correct.

Comment by Peter Jones [ 13/Jun/11 ]

Brian will look into this one

Comment by Brian Murrell (Inactive) [ 13/Jun/11 ]

But rpm will only allow one of the following forms:
rpm -ql %{name}-modules
rpm -ql %{name}-modules-%{version}
rpm -ql %{name}-modules-%{version}-%{release}.%{_arch}

This doesn't appear to be the case on RHEL 5:

# rpm -q lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7.x86_64
lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7
# rpm -q lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7
lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7
# rpm -q lustre-modules-2.0.59
lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7
# rpm -q lustre-modules
lustre-modules-2.0.59-2.6.18_194.17.1.el5_lustre.g0091fc7_g0091fc7

So this new behavior seems to be a RHEL 6ism. I will test it further.

Comment by Brian Murrell (Inactive) [ 13/Jun/11 ]

Hrm. RHEL 6 behaves the same as RHEL 5:

For the package:

# rpm -qi lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64
Name        : lustre-modules               Relocations: (not relocatable)
Version     : 2.0.62                            Vendor: (none)
Release     : 2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661   Build Date: Mon 13 Jun 2011 04:10:02 PM EEST
Install Date: Mon 13 Jun 2011 10:28:41 PM EEST      Build Host: rhel6-64-build.lab.whamcloud.com
Group       : Development/Kernel            Source RPM: lustre-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.src.rpm
Size        : 143107327                        License: GPL
Signature   : (none)
URL         : http://wiki.whamcloud.com/
Summary     : Kernel Lustre modules for Linux 2.6.32-131.2.1.el6_lustre.gc25aafb.x86_64
Description :
Lustre file system, server and network drivers for Linux 2.6.32-131.2.1.el6_lustre.gc25aafb.x86_64.

I am able to query for the package using any subset of components in the name-version-release.distro path:

# rpm -q lustre-modules
lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64
# rpm -q lustre-modules-2.0.62
lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64
# rpm -q lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661
lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64
# rpm -q lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64
lustre-modules-2.0.62-2.6.32_131.2.1.el6_lustre.gc25aafb.x86_64_g5f64661.x86_64

Is this problem unique to only RHEL6.1 then? We/I don't have a RHEL6.1 here to test with so if you could complete the set of proofs and provide the output of the same tests as the above two but for RHEL6.1, we could get a better picture of the platforms affected. Thanx.

Comment by Andreas Dilger [ 29/Jun/11 ]

This is also failing on my FC13 installed client, preventing me from being able to uninstall this RPM without passing "--nopreun".

rpm -e --nodeps lustre-modules
error: %preun(lustre-modules-1.8.6-2.6.32.26_175.fc12.x86_64.x86_64) scriptlet failed, exit status 1

rpm -q lustre-modules
lustre-modules-1.8.6-2.6.32.26_175.fc12.x86_64.x86_64

note strange double-arch suffix ^^^^^^
It doesn't make sense to include the arch in the %

{version}, which is what I would assume happened here.

# rpm -ql lustre-modules-1.8.6-2.6.32.26_175.fc12
package lustre-modules-1.8.6-2.6.32.26_175.fc12 is not installed
# rpm -ql lustre-modules-1.8.6-2.6.32.26_175.fc12.x86_64
package lustre-modules-1.8.6-2.6.32.26_175.fc12.x86_64 is not installed
# rpm -ql lustre-modules-1.8.6-2.6.32.26_175.fc12.x86_64.x86_64 {lists modules}

It probably makes sense to add "|| true" at the end of this line, so at least in case of failure it doesn't break the RPM uninstall. Alternately, if the RPM version is not well defined between distros, something like:

%post modules
:
:
# "weak modules" support
rpm -ql $(rpm -q %{name}-modules | grep "%{version}

{release}") |
grep '\.ko$' > /var/run/%{name}-modules
# Suse
if [ -x /usr/lib/module-init-tools/weak-modules ]; then
cat /var/run/%{name}-modules |
/usr/lib/module-init-tools/weak-modules --add-modules
fi
# RedHat
if [ -x /sbin/weak-modules ]; then
cat /var/run/%{name}-modules |
/sbin/weak-modules --add-modules
fi
rm -f /var/run/%{name}-modules

%preun modules
rpm ~~ql $(rpm -q %{name}-modules | grep "%{version}~~%{release}

") |
grep '\.ko$' > /var/run/%

{name}

-modules || true

On a minor side note, there is no need to grep '\.ko$' when calling weak-modules, it was already done during "rpm -ql".

Comment by Christopher Morrone [ 29/Jun/11 ]

We also see the double .x86_64 in the name, and I can explain that. A standard RHEL/fedora (at least the latest versions, it might have been different previously) kernel has a version string like so:

1.8.6-2.6.32.26_175.fc12.x86_64

It actually includes the .x86_64 in the version string compiled into the kernel, not just as part of the rpm name. So when lustre includes the kernel version into its packages name, that first .x84_64 really is part of the kernel version string. Only the second one was added as the rpm package architecture designation.

I also kind of suspect that this is the reason why you and I see this problem, but Brian Murrell does not when he uses the his kernel string that does NOT end in ".x86_64". I kind of suspect that rpm is doing something stupid where is munges the user's input on the command line before checking it against the canonical package name in the database. So I suspect sees .x86_64 on the end, and strips it off thinking it it just part of the rpm name, when really it IS part of the package name. It should only strip it off when there are two...but I haven't looking into the rpm source yet to see if that is really the case.

If rpm were well behaved (and my assumption is correct), it should really try the lookup on the user string first, and only munge it into another form (strip off the trailing part that looks like the architecture designation), if the first lookup fails and then try again.

Comment by Christopher Morrone [ 25/Jul/11 ]

I updated http://review.whamcloud.com/934 with Andreas' suggestions.