Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 117054 - up2date gets permanently crippled by .hdr download error
Summary: up2date gets permanently crippled by .hdr download error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: 3
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact:
URL:
Whiteboard:
: 121090 (view as bug list)
Depends On:
Blocks: FC2Blocker up2date-fc2 FC3Target FC4Target
TreeView+ depends on / blocked
 
Reported: 2004-02-27 19:47 UTC by Alan Cox
Modified: 2007-11-30 22:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-05 06:34:24 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Alan Cox 2004-02-27 19:47:13 UTC 
If up2date is interrupted or otherwise gets a corrupt ".hdr" file then
it gets permanent indigestion. Every further use of it blows up (with
diagnostics to console and no apparent info to the user - which is
also bad) when the gzip library fails to handle the .hdr file. 

It ought I imagine to at least catch the gzip error and purge the
relevant cache entry, and preferably then re-fetch it and retry. Just
purging it, giving a sane error and letting the user rerun it would help.
Comment 1 Alan Cox 2004-03-12 22:31:15 UTC 
Raised to security since it seems I can cause this simply by hijacking
DNS or being a hostile package supplier. If you think about the 'break
into mirror, install broken .hdr file and cripple every user of the
mirror' case its not pretty...
Comment 2 Warren Togami 2004-04-18 20:27:32 UTC 
Uh oh... is Bug #121090 a case of this?
Comment 3 Terje Bless 2004-11-13 13:12:11 UTC 
Bug #121090 does look like a dup of this.

The easy fix is probably to catch the exception and notify the user
of the problem -- *including* the filename that caused it to barf! --
rather than trying to figure out a safe way to delete a file in
response to an exception, or to try to recover silently.

Granted I've not run into this since somewhere around FC2-ish, but
then tracking Rawhide tends to develop automated avoidance routines
like periodically purging the .hdr cache manually.
Comment 4 Alan Cox 2004-12-03 17:53:28 UTC 
Duplicated this with yum - still in FC3
Comment 5 Adrian Likins 2004-12-03 20:01:56 UTC 
need an example of a corrupt header, changes some
time in fc3 should eliminate getting stuck on gzip
errors with bogus headers (in up2date, no idea about yum)
Current versions should give an error about error loading
header and then automatically redownload it. RHEL4/FC3
should be do this. 

If you see otherwise, get me a copy of the traceback
and the bogus header (or if need be, a tar of all of
/var/spool/up2date).
Comment 6 Rahul Sundaram 2005-09-05 06:25:58 UTC 
*** Bug 121090 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.