From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-2 i686) Description of problem: up2date seems to indicate that it has successfully installed packages which were corrupted. (md5sum mismatch) Here up2date was run with gpg turned off and asked to save packages to disk after install. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Run up2date with install setting on. 2.Watch for error messages in terminal 3.Double check the packages in /var/spool/up2date to make sure Actual Results: Here I tried updating 4 packages, emacs-20.7-41.i386.rpm emacs-X11-20.7-41.i386.rpm emacs-nox-20.7-41.i386.rpm exmh-2.4-2.noarch.rpm Of the 4 chosen, all 4 had md5sum mismatches, [root@yakuza up2date]# rpm -K e*rpm emacs-20.7-41.i386.rpm: MD5 NOT OK emacs-nox-20.7-41.i386.rpm: MD5 NOT OK emacs-X11-20.7-41.i386.rpm: MD5 NOT OK exmh-2.4-2.noarch.rpm: MD5 NOT OK But up2date went ahead and installed them anyway, but there were some error messages, error: unpacking of archive failed on file /usr/share/emacs/20.7/etc/DOC-20.7.1;3b841541: cpio: MD5 sum mismatch error: unpacking of archive failed: cpio: Bad magic error: unpacking of archive failed on file /usr/bin/emacs-nox;3b841541: cpio: MD5 sum mismatch error: unpacking of archive failed on file /usr/lib/exmh-2.4/bitmaps/address.xbm;3b841541: cpio: MD5 sum mismatch I checked if up2date had actually installed the packages (rpm should fail? if md5sum fails) and it seems that the packages were not installed. [root@yakuza up2date]# rpm -qa | grep emacs emacs-nox-20.7-40 emacs-20.7-40 emacs-X11-20.7-40 I tried running emacs, [root@yakuza up2date]# emacs Segmentation fault Expected Results: If packages don't pass the md5sum test, up2date should either try and download them again or give and indication of the fact. Then again, I am not sure why the update server consistently gives corrupted packages. The sample I did above was a bit abnormal. But in the packages I have in /var/spool/up2date right now, 11 out of 20 have md5sum mismatches. Additional info:
Okay, can you have a look at the file sizes? Can you look at the beginning or at the end of a corrupted file and see if it looks like data or it has some human-readable stuff attached? I will try to duplicate this too.
We (Red Hat) should really try to fix this before next release.
Here are the file sizes: [bharath@yakuza up2date]$ ls -l e*rpm | awk '{print $5 " " $9}' 8085113 emacs-20.7-41.i386.rpm 974973 emacs-nox-20.7-41.i386.rpm 1096255 emacs-X11-20.7-41.i386.rpm 729412 exmh-2.4-2.noarch.rpm The beginning of the file looks ok (file magic) I can read some text, the end looks like data.
These are perfectly valid file sizes. Could you please run md5sum on the files too? Thanks.
[bharath@yakuza up2date]$ md5sum e*rpm 082a935d9a4e4b6b4dcb3f13efe6da9f emacs-20.7-41.i386.rpm c5418d77e067a681115c83508b6bf46c emacs-nox-20.7-41.i386.rpm 0ded75ccf179251a7d9428fad2881641 emacs-X11-20.7-41.i386.rpm 1df8b1a082a04372ba8ad954752648e2 exmh-2.4-2.noarch.rpm
I'm not able to replicate the invalid MD5 sums here in the office, which would lead me to believe that it was probably a dirty connection which resulted in the corrupt RPMs. The bigger issue is if up2date should check the MD5 sum of everything that it downloads and retry stuff that fails X times. Probably a pretty good enhancement request.
That would be good. 1. Check each package downloaded for md5sum mismatch 2. Retry if user says ok 3. Install any packages which doesn't have conflicts or corruption if user decides not to retry instead of quitting completely 4. If files are saved to disk, check md5sum before using them. Download if needed.
md5sum signatures of the packages do get checked in normal operation, but not if "--nosig" is turned on. I'll take a look at seperating these checks into two steps so that md5sum sigs always get checked and "--nosig" only skips the gpg sig check. This is a bit of a "beta only" circumstance though...