Bug 186945 (yum-cpio-error)

Summary: Yum reports Updated/Complete even when its failed with errors
Product: [Fedora] Fedora Reporter: Chris Jones <rollercow>
Component: yumAssignee: Jeremy Katz <katzj>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: boris, james.antill, katzj, knolderpoor, michal, pmatilai, valdis.kletnieks
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: f9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-28 19:54:53 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:
Bug Depends On:    
Bug Blocks: 282951    

Description Chris Jones 2006-03-27 16:38:55 UTC
Description of problem:
When an update fails, yum still reports that its updated this package and that
its completed.

Version-Release number of selected component (if applicable):
yum.noarch 2.4.1-1.fc4

How reproducible:
Always

Steps to Reproduce:
1. yum update (assuming you have a problem package)
2. 
3.
  
Actual results:
Running Transaction
  Updating  : kde-i18n-Polish              ######################### [1/2]
error: unpacking of archive failed on file /usr/share/doc/HTML/pl/common: cpio:
rename

Updated: kde-i18n-Polish.noarch 1:3.5.1-0.1.fc4
Complete!


Expected results:
Report a fail, or an error, rather than claiming to have updated

Additional info:
The kde-i18n-Polish bug lives in bug 176357

Comment 1 Christian Iseli 2007-01-20 00:40:24 UTC
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 ?

Thanks.

Comment 2 Jeremy Katz 2007-04-25 18:51:07 UTC
*** Bug 217762 has been marked as a duplicate of this bug. ***

Comment 3 Seth Vidal 2007-08-03 19:26:06 UTC
Wouldn't this be an issue of rpm's callback not giving us the information of a
failure?

I'm going to reassign it over to rpm - see what paul and panu have to say.

Comment 4 Jeremy Katz 2007-08-07 21:52:03 UTC
*** Bug 251236 has been marked as a duplicate of this bug. ***

Comment 5 Valdis Kletnieks 2007-08-07 22:36:49 UTC
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".

Comment 6 Panu Matilainen 2007-08-10 07:05:45 UTC
*** Bug 246037 has been marked as a duplicate of this bug. ***

Comment 7 Panu Matilainen 2007-08-10 09:52:12 UTC
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...

Comment 8 Seth Vidal 2007-08-10 12:43:48 UTC
Is this the case in all versions of rpm or just newer ones?

Comment 9 Panu Matilainen 2007-08-10 12:49:50 UTC
Been there since rpm 4.1 according to hg. And no, I hadn't noticed it either
until now... :)

Comment 10 Seth Vidal 2007-08-10 13:24:51 UTC
(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.



Comment 11 Panu Matilainen 2007-08-10 13:33:16 UTC
AFAICT it's a header you can access normally.

Comment 12 Seth Vidal 2007-08-10 13:47:51 UTC
okay - and one last question - do you happen to have some intentionally broken
rpms I can use to test this?

Comment 13 Valdis Kletnieks 2007-08-10 14:44:23 UTC
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.

Ker-splat. :)

Comment 14 Jeremy Katz 2007-09-13 19:11:00 UTC
*** Bug 255281 has been marked as a duplicate of this bug. ***

Comment 15 Seth Vidal 2008-03-12 13:51:45 UTC
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?

Comment 16 Bug Zapper 2008-05-14 02:07:47 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping