From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040923 MultiZilla/1.6.4.0b Description of problem: When downloading the public beta of RHEL4, some files seem to download past the 100% point. According to people on #rhel and #centos on freenode, the problem is intermittant, and seems linked to certain files. It's been seen with: nahant-i386-disc2.iso nahant-i386-disc3.iso nahant-i386-WS-disc1.iso According to the RedHat site: nahant-i386-disc2.iso 20-Sep-2004 19:24 618M nahant-i386-disc3.iso 20-Sep-2004 19:25 636M However, after downloading: # ls -alh -rw------- 1 jmore jmore 1.2G Sep 27 19:42 nahant-i386-disc2.iso -rw------- 1 jmore jmore 1.3G Sep 27 19:52 nahant-i386-disc3.iso Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Download file with wget or lftpget 2. Compare file size to correct size Actual Results: Expected Results: Additional info: Oddly enough, mounting with -o loop seems to work fine: # mount -o loop nahant-i386-disc2.iso /mnt/iso # du -h /mnt/iso 617M /mnt/iso/RedHat/RPMS 617M /mnt/iso/RedHat 617M /mnt/iso dd does not seem to solve the problem $ dd if=nahant-i386-disc2.iso of=nahant-i386-disc2.iso.fixed bs=647761920 count=1 $ md5sum nahant-i386-disc2.iso.fixed d226e418fe3636e8fa269095fdd47499 nahant-i386-disc2.iso.fixed This does not match the published sum. Workaround: As the only problem files for me were disc2 and disc3, you can work around this problem by mounting the iso image and generating a new iso image from the mount: # mount -o loop nahant-i386-disc2.iso /mnt/iso # cd /mnt/iso # mkisofs -o ~/isos/rhel3.94/nahant-i386-disc2.iso.fixed -R -J -V -T . If the problem occurs on a bootable CD, the command: mkisofs -o ~/isos/rhel3.94/nahant-i386-disc2.iso.fixed -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -R -J -V -T . Should probably be used. Since these methods do not modify the .discinfo file, expect these 'fixed' iso images to fail the disc check.
This is actually a problem on the server-side with gettimeofday() going backwards. Details in #132439. *** This bug has been marked as a duplicate of 132439 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.