Bug 152105
Summary: | yum checksum error results in double-sized rpm | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fred New <fred.new2911> |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | katzj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-03-24 21:29:12 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: |
Description
Fred New
2005-03-24 21:17:53 UTC
This is the reget functionality. You had already downloaded half so it only had to download another half. Reget isn't supposed to and cannot check the content. I disagree. Yum should not be using reget in this case. If this were rsync, it could use the old file and figure out where the problem is; I would have preferred this. But instead, yum ignored the fact that the original RPM was bad and appended a perfectly valid RPM to the end of it. After filing this bug, I used dd to split the 150 MB in two, creating a valid RPM from the second half. As indicated by the above error, the first half was bad: [fred@darth updates]$ l openoffice.org-core-1.9.87-2.i386.rpm.orig -rw-r--r-- 1 fred 157426750 Mar 24 23:46 openoffice.org-core-1.9.87-2.i386.rpm.orig [fred@darth updates]$ expr 157426750 / 2 / 125 629707 [fred@darth updates]$ dd if=openoffice.org-core-1.9.87-2.i386.rpm.orig of=openoffice.org-core-1.9.87-2.i386.rpm.part1 bs=125 count=629707 629707+0 records in 629707+0 records out [fred@darth updates]$ dd if=openoffice.org-core-1.9.87-2.i386.rpm.orig of=openoffice.org-core-1.9.87-2.i386.rpm.part2 bs=125 skip=629707 629707+0 records in 629707+0 records out [fred@darth updates]$ rpm -K openoffice.org-core-1.9.87-2.i386.rpm.part[12] openoffice.org-core-1.9.87-2.i386.rpm.part1: sha1 MD5 NOT OK openoffice.org-core-1.9.87-2.i386.rpm.part2: sha1 md5 OK [fred@darth updates]$ How is yum supposed to know that the previous parts are bad? Seriously, either you err on the side of caution and always a delete it, and you find out later if the file is good or not. Or you assume the part you have is good, just incomplete and you test it once it is done for validity. How do you think it should happen and still keep reget functionality? If the RPM gets downloaded to the point where yum decides that it is time to run sha1sum and the sha1sum fails, then it should delete the file and start again. If you are expecting 78713375 bytes of data and you have downloaded 78713375 bytes of data and the checksum doesn't work, then there is nothing you can add to the file that will correct the checksum and give you the correct number of bytes. to comment #4: what are you talking about? Remember, this is a reget. If you're expecting 150M and you have 75M then the bandwidth-sensitive assumption you make is that the first 75M are correct and you should only download the next 75M. I'm really confused as to what you think should be the correct behavior and when you think yum has all the information necessary to checksum the package and to KNOW it's corrupt and not just incomplete. Please describe, in detail, what you think correct behavior is. But I wasn't expecting 150 MB, I was expecting 75 MB. I agree completely with you if I was expecting 150 MB, but I wasn't. What I don't understand is in __init__.py, why doesn't cursize == totsize? Does os.stat(local)[6] return the number of bytes minus 1, while int(po.size()) returns the actual number of bytes? Or doesn't os.unlink delete the file? Please look at openoffice.org-core-1.9.87-2.i386.rpm on any mirror; you will see that it is 75 MB. Why is it 150 MB in my /var/yum/cache/development/packages directory? Changing summary to improve searchability. |