Bug 348961 - update failed and client said to report it.
update failed and client said to report it.
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Luke Macken
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-23 12:03 EDT by Kim D. Dimick
Modified: 2016-09-19 22:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-16 22:43:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
0001-Catch-unknown-errors-when-parsing-the-update-metadat.patch (1.83 KB, patch)
2008-05-12 23:27 EDT, Luke Macken
no flags Details | Diff
0001-Catch-unknown-errors-when-parsing-the-update-metadat.patch (1.92 KB, patch)
2008-05-12 23:40 EDT, Luke Macken
no flags Details | Diff
An updated patch to catch struct.error when parsing the update metadata. (2.07 KB, patch)
2008-05-30 14:36 EDT, Luke Macken
no flags Details | Diff

  None (edit)
Description Kim D. Dimick 2007-10-23 12:03:21 EDT
Description of problem:

Update failed see attached output.

Version-Release number of selected component (if applicable):

How reproducible:

Use the update client and try to update the only update from 10-23-07

Steps to Reproduce:
Actual results:

Component: pirut
Summary: TB01d293f7 struct.py:87:unpack:error: unpack requires a string argument
of length 4

Traceback (most recent call last):
  File "/usr/sbin/pup", line 650, in <module>
  File "/usr/sbin/pup", line 646, in main
  File "/usr/sbin/pup", line 470, in run
  File "/usr/sbin/pup", line 295, in doRefresh
  File "/usr/sbin/pup", line 351, in populateUpdates
  File "/usr/lib/python2.5/site-packages/yum/update_md.py", line 253, in add
    for event, elem in iterparse(infile):
  File "<string>", line 61, in __iter__
  File "/usr/lib/python2.5/gzip.py", line 227, in read
  File "/usr/lib/python2.5/gzip.py", line 275, in _read
  File "/usr/lib/python2.5/gzip.py", line 308, in _read_eof
    crc32 = read32(self.fileobj)
  File "/usr/lib/python2.5/gzip.py", line 40, in read32
    return struct.unpack("<l", input.read(4))[0]
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
    return o.unpack(s)
error: unpack requires a string argument of length 4

Local variables in innermost frame:
fmt: <l
o: <Struct object at 0xb4ea660>

Expected results:

Additional info:
Comment 1 Peter van Egdom 2007-11-14 14:13:48 EST
Thank you for the report. However this has been reported to the incorrect
component. Reassigning from "up2date" to "pirut". Feel free to report any
further bugs you find to our bug tracking system.
Comment 2 Jeremy Katz 2007-11-15 20:03:41 EST
We should probably fail more gracefully on bad files
Comment 3 Seth Vidal 2007-12-06 22:40:58 EST
you've got an ioerror catch in update_md.py for this one - do you want a more
generic exception catch or just additional exceptions?
Comment 4 Seth Vidal 2008-03-12 11:04:13 EDT
Jeremy,  Can we still make this happen? I can't seem to get it to fallover on a
bad file in this way anymore but I may not be trying hard enough.

Comment 5 Luke Macken 2008-05-12 23:27:21 EDT
Attaching a patch that catches unknown exceptions while parsing the update
metadata, and throws an UpdateNoticeException.  This will allow pup to fail more
Comment 6 Luke Macken 2008-05-12 23:27:44 EDT
Created attachment 305194 [details]
Comment 7 Luke Macken 2008-05-12 23:40:29 EDT
Created attachment 305195 [details]

Patch to catch unknown exceptions while parsing the update metadata
(potentially due to corruption), spit out the traceback, and throw an
Comment 8 Luke Macken 2008-05-12 23:42:17 EDT
Seth, what do you think about this patch?  I'm not quite sure of a better way
that we can handle unknown updateinfo corruption, other than spitting out the
traceback and masking the exception...
Comment 9 Bug Zapper 2008-05-14 10:50:25 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Seth Vidal 2008-05-30 11:32:31 EDT
Luke, the global except is just going to get us in trouble. If we could isolate
the type of exceptions a bit more I'd be happier with it.
Comment 11 Luke Macken 2008-05-30 14:36:47 EDT
Created attachment 307226 [details]
An updated patch to catch struct.error when parsing the update metadata.
Comment 12 Luke Macken 2008-05-30 14:37:27 EDT
Updated patch attached, which catches struct.error, and throws an
UpdateNoticeException mentioning that the metadata is corrupted.
Comment 13 Bug Zapper 2008-06-16 22:43:30 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.