Re: Yum is not an .rpm package error message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 18 Nov 2003, BFD wrote:
> Jesse Keating wrote:
> >On Tuesday 18 November 2003 06:23, BFD wrote:
> >>For the file from my Fedora cd:
> >>
> >>$md5sum yum-2.0.4-2.noarch.rpm
> >>dd4249018c1674b73e9ddab08828303f  yum-2.0.4-2.noarch.rpm
> >>$sum yum-2.0.4-2.noarch.rpm
> >>29472   127
> >>
> >>For the file I downloaded
> >>$md5sum yum-2.0.4-2.noarch.rpm
> >>8a82c3f05fca0a615d1765394376f809  yum-2.0.4-2.noarch.rpm
> >>$sum yum-2.0.4-2.noarch.rpm
> >>47550   127
> >
> >Try actually using "file" on the file.  A file extension is by no means 
> >an indication as to what the file actually is.

I am now considering that the problem file was a misnamed .hdr
file.

Here are some random thoughts that got me there.

At this point it may be difficult to resolve the corruption. Some of
us were able to download this file correctly. This tells me that at
the correct file is on the repository and that the bogus files did 
not persist.

Since web browsers have large and strong caching resources it makes
sense that multiple downloads will result in the same bits for you.  
This can be tested by timing the first and second download of a new
file. A download of a cached file can be very quick.

Since the "file" command reports 'data' and not some flavor of text
like "HTML document text" or "ASCII C program text" I do not expect
that the download was cut off short at the end.

So what is in the bogus file you have?

It is useful to look at _copies_ of the good and bad files side by
side.
	"ls -l" and "wc"  will give us the character counts.
	It would be interesting to see if the files are the same 
	size.  	If the byte counts matched and if  an ftp 
	transfer was used I would look to see if there
	was a  binary .vs. ASCII mode transfer problem.  
	Tinkering I found that if an RPM file is ftp transfered in
	ASCII mode "file" still reports the file as an RPM but "cmp"
	will find that byte 151 differs on yum-2.0.4-2.noarch.rpm if
	this was the trouble.

	Wondering what the bogus file is I might first try:
	  "strings  bogus-yum-2.0.4-2.noarch.rpm | less"
	  "strings  bogus-yum-2.0.4-2.noarch.rpm | head -40"
	Since RPM files have a text rich header and other
	text rich structures this is often informative.
	"strings" on most files will result in some clue.

	Next I might look at the bogus file with "od":
	  "od -x -c bogus-yum-2.0.4-2.noarch.rpm | less"
	  "od -x -c bogus-yum-2.0.4-2.noarch.rpm | head -40"
	Things like byte swap is  easy to spot with od.

If you had used a squid or another proxy caching server I would
check the logs to see if the good and bad download came from the
same IP address.  Some load balancing tools and tricks will switch
from box to box by giving a different IP address at different times
to different requests.  Knowing which box can be useful if only one
of many boxes are involved.

I do not know how the Fedora folks update the site or build their
HTML but a browser-->view-->source glance at the HTML does not find
anything strange/magic/clever.

I am slightly curious what OS and hardware
download.fedora.redhat.com is running there is a very slim chance of
a file system object reuse bug on one end of the wire.  The odds are
against the server side of things.

Most serious 'public' web sites have refresh tricks to detect and
sweep up crud deposited by web site hackers or fat fingered admins.  
These tools might have quietly refreshed the site and fixed the
problem.

Hmmm... I just looked at an rpm "header" (.hdr) file with "file" and
the answer was 'data'.  I looked for but did not find a .hdr file
for yum-2.0.4-2.noarch so I cannot double check.  But up2date and
yum (Yellow dog Updater, Modified) take advantage of these headers
to be quick.

At this point my guess is that you have misnamed .hdr.

By chance was an older or experimental version of yum (indirectly?)  
being used to update yum?









[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux