Red Hat Bugzilla – Bug 186945
Yum reports Updated/Complete even when its failed with errors
Last modified: 2014-01-21 17:53:53 EST
Description of problem:
When an update fails, yum still reports that its updated this package and that
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum update (assuming you have a problem package)
Updating : kde-i18n-Polish ######################### [1/2]
error: unpacking of archive failed on file /usr/share/doc/HTML/pl/common: cpio:
Updated: kde-i18n-Polish.noarch 1:3.5.1-0.1.fc4
Report a fail, or an error, rather than claiming to have updated
The kde-i18n-Polish bug lives in bug 176357
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
*** Bug 217762 has been marked as a duplicate of this bug. ***
Wouldn't this be an issue of rpm's callback not giving us the information of a
I'm going to reassign it over to rpm - see what paul and panu have to say.
*** Bug 251236 has been marked as a duplicate of this bug. ***
I'm not convinced my bug #251236 is an actual dup - this bug reports "rpm XYZ
fails to actually install, but gets reported as correct". My bug is "XYZ
properly fails, and then *other* things fail to install as well".
*** Bug 246037 has been marked as a duplicate of this bug. ***
Yum can catch the error by checking for RPMCALLBACK_CPIO_ERROR /
RPMCALLBACK_UNPACK_ERROR in the callback and report failure based on that.
And over to yum...
Is this the case in all versions of rpm or just newer ones?
Been there since rpm 4.1 according to hg. And no, I hadn't noticed it either
until now... :)
(In reply to comment #7)
> Yum can catch the error by checking for RPMCALLBACK_CPIO_ERROR /
> RPMCALLBACK_UNPACK_ERROR in the callback and report failure based on that.
> And over to yum...
You wouldn't happen to know what the fourth option passed to the callback will
look like in the case of these two would you?
I'm having trouble gleaning this from the rpm source.
AFAICT it's a header you can access normally.
okay - and one last question - do you happen to have some intentionally broken
rpms I can use to test this?
Seth: You don't need an intentionally broken RPM, just an intentionally broken
system config. If you have a machine that has a separate /usr or /usr/share,
just do this:
1) mount -o remount,ro /usr
2) Try to install an RPM that has files on /usr.
*** Bug 255281 has been marked as a duplicate of this bug. ***
Okay yum is now outputting a clearer error message in this case. However, it is
still not fatal to the whole transaction and probably shouldn't be. Is that enough?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here: