Bug 168844

Summary: postuninstall scriptlet broken in xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1.*.rpm; cannot remove package
Product: [Fedora] Fedora Reporter: D. Hugh Redelmeier <hugh>
Component: xorg-x11Assignee: Mike A. Harris <mharris>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: roozbeh, shiva, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: xorg-x11-6.8.2-37.FC4.49.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-22 17:46:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description D. Hugh Redelmeier 2005-09-20 17:12:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
When you try to remove this package, the scriptlet fails with this message:
 /sbin/ldconfig: relative path `1' used to build cache
 error: %postun(xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1.i386) scriptlet failed, exit status 1

The reason is that the scriptlet uses ldconfig as if it were a shell.  Here's the scriptlet

 # rpm -q --scripts xorg-x11-Mesa-libGLU
 postinstall program: /sbin/ldconfig
 postuninstall scriptlet (using /sbin/ldconfig):
 
 ##### xfs scripts ####################################################
 # Work around a bug in the XFree86-xfs postun script, which results in the
 # special xfs user account being inadvertently removed, causing xfs to run as
 # the root user, and also resulting in xfs not being activated by chkconfig,
 # This trigger executes right after the XFree86-xfs postun script, and ensures
 # that the xfs user exists, and that the xfs initscript is properly chkconfig
 # activated (#118145,118818)

The previous RPM got this right:
  # rpm -q --scripts xorg-x11-Mesa-libGLU-6.8.2-37.FC4.45
  postinstall scriptlet (using /bin/sh):
  /sbin/ldconfig
  postuninstall scriptlet (using /bin/sh):
  /sbin/ldconfig

  ##### xfs scripts ####################################################
  # Work around a bug in the XFree86-xfs postun script, which results in the
  # special xfs user account being inadvertently removed, causing xfs to run as
  # the root user, and also resulting in xfs not being activated by chkconfig,
  # This trigger executes right after the XFree86-xfs postun script, and ensures
  # that the xfs user exists, and that the xfs initscript is properly chkconfig
  # activated (#118145,118818)

Doing an strace on the attempted removal
  # strace -o 0 -f rpm -e --verbose xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1
You can see the exec of /sbin/ldconfig:
  execve("/sbin/ldconfig", ["/sbin/ldconfig", "/var/tmp/rpm-tmp.60280", "1"], [/* 27 vars */]) = 0

The first and second arguments to /sbin/ldconfig make no sense
according the the ldconfig(8) manpage.



Version-Release number of selected component (if applicable):
xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1.*.rpm

How reproducible:
Always

Steps to Reproduce:
1. try to remove the package

  

Actual Results:  you get the error message

Expected Results:  Silence is golden

Additional info:

This bug affects the RPM being tested by Mike.

[hugh@redsky tba]$ rpm -qp --scripts xorg-x11-Mesa-libGLU-6.8.2-37.FC4.49.1.i386.rpm
postinstall program: /sbin/ldconfig
postuninstall scriptlet (using /sbin/ldconfig):

##### xfs scripts ####################################################
# Work around a bug in the XFree86-xfs postun script, which results in the
# special xfs user account being inadvertently removed, causing xfs to run as
# the root user, and also resulting in xfs not being activated by chkconfig,
# This trigger executes right after the XFree86-xfs postun script, and ensures
# that the xfs user exists, and that the xfs initscript is properly chkconfig
# activated (#118145,118818)

Comment 1 Mike A. Harris 2005-09-20 17:41:42 UTC
Thanks for the report.  I've investigated things a bit deeper, and it turns
out that this is a horrible bug (or feature some might argue, who knows)
in rpm it seems.  I am reverting things back to using scripts instead of
-p /sbin/ldconfig.



Comment 2 Mike A. Harris 2005-09-21 03:09:41 UTC
Unfortunately, the fedora update got pushed out the door before this issue
got fixed.  For the time being, we are going to fix it in CVS but not
push another update, until a number of issues are fixed to make doing another
update worthwhile.  Also, pushing 3 X updates in a short period of time would
not make users too happy.



Comment 3 Mike A. Harris 2005-09-21 21:25:31 UTC
It turns out that the fedora update accidentally went to updates-testing
instead of an official update - an err that works in our favour this time.

I'm adding the fix for this issue, and respinning a new build for the
final update for FC4.  The FC3 update did go out as an official update
though, so it will wait for a future update to receive the fix for this.



Comment 4 Fedora Update System 2005-09-22 04:37:05 UTC
From User-Agent: XML-RPC

xorg-x11-6.8.2-37.FC4.49.2 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 5 Mike A. Harris 2005-09-22 17:46:25 UTC
IMPORTANT NOTICE:  The xorg-x11-6.8.2-37.FC4.49.2 does fix this issue,
however users upgrading from the previous update xorg-x11 that had this
problem will still experience this error.

The reason for that is that it is the %postun script of the *OLD* package
with the bug that gets executed on upgrade as it gets uninstalled.

Once you have upgraded to the xorg-x11-6.8.2-37.FC4.49.2, and the old
broken script has executed once during the upgrade, your rpm database
will have the new script in it for future upgrades.

This means everyone upgrading to xorg-x11-6.8.2-37.FC4.49.2, will still
see this error, and that is both expected and unavoidable.

Setting status to ERRATA

Comment 6 Mike A. Harris 2005-09-22 18:23:39 UTC
UPDATE: An additional problem caused by this bug has been discovered.

When upgrading to the new "fixed" packages using 'yum', and the above
unavoidable error occurs, it causes the old xorg-x11-Mesa-libGLU package
to *NOT* get uninstalled, however yum still installs the new package
anyway.

That seems to be a bug in yum ignoring rpm postun script errors, or
in rpmlib or something.

The net result is that you will end up with multiple copies of GLU
installed.  We've explored this problem and it does not seem that there
is any way to avoid this problem automatically.  This is very unfortunate.

As such, users will have to run the following commands either before or
after the upgrade in order to remove the bad package, and install the
latest fixed version:

rpm -e --allmatches --nodeps --noscripts xorg-x11-Mesa-libGLU
yum install xorg-x11-Mesa-libGLU



Comment 7 Mike A. Harris 2005-09-22 21:07:28 UTC
*** Bug 169079 has been marked as a duplicate of this bug. ***

Comment 8 Kenneth Porter 2005-09-22 21:42:51 UTC
I'd recommend putting out an advisory on fedora-announce with instructions on
how to clean out the old package, for those not experienced with RPM's less
common features.

Comment 9 Rahul Sundaram 2005-09-23 02:35:13 UTC
Announcements have been made to the Fedora Forum and users list. More
information available at

http://fedoraproject.org/wiki/Bugs/XorgUpdateFix

Comment 10 Jerry 2005-09-23 02:36:49 UTC
Please Note:  On my system, this bug completely hosed X.  I had to boot with 3
in the boot command to come up in run level 3 and manually delete the packages
and update to the new packages.

In trying to figure it out myself i saw the script error and did the delete
--noscripts just guessing.

The other odd behavior is that update decided it needed to install ati-fglrx
from livna.  I am not sure why.  That resulted in a boot time error looking for
the kernel module.  I suspect there are some dependancy issues going on.

At least get the word out that this is recoverable.  Howvever users that rely on
a single linux box, may not be able to get their systems running well enough to
view mail or web pages to find out how to fix this.  This is most unfortunate.




Comment 11 Fedora Update System 2005-09-23 15:44:17 UTC
From User-Agent: XML-RPC

xorg-x11-6.8.2-1.FC3.45.2 has been pushed for FC3, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 12 Mike A. Harris 2005-09-23 17:15:05 UTC
(Actually don't make a note of it in this bug report, as you are guaranteed
to see the error message once more when upgrading, and that is unavoidable
as it is the old postun script that is broken getting executed.)

Comment 13 D. Hugh Redelmeier 2005-09-25 17:24:46 UTC
I searched in my mirror of FC4 updates for examples of this problem.  Here is
the script I used:
find * -name '*.rpm' -print | while read n
  do
    if rpm -qp --scripts "$n" | grep  '^postuninstall scriptlet .using
/sbin/ldconfig'
    then echo "$n"
    fi
  done

It only found variants of xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1

Conclusion: even though this problem was caused by an unexpected feature of rpm,
it has only hit this one package (so far in FC4).

Comment 14 Mike A. Harris 2005-09-26 16:31:24 UTC
(In reply to comment #13)
> I searched in my mirror of FC4 updates for examples of this problem.  Here is
> the script I used:
> find * -name '*.rpm' -print | while read n
>   do
>     if rpm -qp --scripts "$n" | grep  '^postuninstall scriptlet .using
> /sbin/ldconfig'
>     then echo "$n"
>     fi
>   done
> 
> It only found variants of xorg-x11-Mesa-libGLU-6.8.2-37.FC4.48.1
> 
> Conclusion: even though this problem was caused by an unexpected feature of rpm,
> it has only hit this one package (so far in FC4).

This "unexpected feature" of rpm, is aparently not a new problem.  The
issue here is that the %post and %postun scripts in xorg-x11 were removed
and replaced by the "%post -p /sbin/ldconfig" variants upon the suggestion
of another developer.  Immediately following the last %postun script
in the spec file was a comment separating and preceding the next section
concerning xfs and the triggerscript that immediately followed.

rpm interpreted that comment as being a shell script that was part of
the %postun, and that is what triggered this bug.  You are very unlikely
to find another package exhibiting this problem unless someone else updated
another package with the same optimization, and a similar problem with
a comment being interpreted in shell context.

This was a single case random fluke of a problem, rather than a new
problem being introduced at large across the distribution, however
perhaps your script could be added to our test suite as a way of
detecting such "unexpected rpm feature" failures in beehive in the
future.

I'll pass it along, thanks!