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-x11 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | 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
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. 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. 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. 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. 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 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 *** Bug 169079 has been marked as a duplicate of this bug. *** 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. Announcements have been made to the Fedora Forum and users list. More information available at http://fedoraproject.org/wiki/Bugs/XorgUpdateFix 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. 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. (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.) 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). (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! |