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

Final ISO of correct size BUT incorrect MD5SUM



Hi all,

I am using the Pseudo Image Kit for Windows. In my specific case,
it is Windows NT Workstation 4.0 (Service Pack 6).

In my network (an University LAN), it is usually quite faster to use a Squid proxy (like 10 times faster), so yesterday I set up the variables in a MS-DOS Prompt to use the proxy (I replaced the name of the proxy here):

set DONTUSENCFTP=DONTUSENCFTP
set FTP_PROXY=http://proxy.example.pt:3128/

Then, I downloaded the binary-i386-1.list (I don't remember where exactly, but I double-checked that it was for 2.2r0).

After this, I made the pseudo-image file with the following command:
make-pseudo-image binary-i386-1.list ftp://ftp.ua.pt/bigdisk/debian

I noticed that this would take quite some time, so I went home and returned here today.

When I saw the size of the ISO file, I noticed it was about 20 Megs shorter than the real size. So I ran rsync, this time without using a proxy (I ran rsync after a reboot, so I ran "SET" in a DOS
prompt, to see the environment variables, and noticed that the variables DONTUSENCFTP and FTP_PROXY disappeared - before the reboot, they were there).

So, I typed the following command:
rsync --verbose --progress --stats --block-size=8192 aurolinux.mit.edu::debian-cd/2.2_rev0/i386/binary-i386-1.iso .

Then, after rsync'ing for some hours (maybe 3 or 4 hours, in a really slow connection),  I had the - already mentioned in this mailing list - "99% corruption message":

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
binary-i386-1.iso
658896896 (99%)
ERROR: file corruption in binary-i386-1.iso. File changed during
transfer?

Number of files: 1
Number of files transferred: 1
Total file size: 658929664 bytes
Total transferred file size: 658929664 bytes
Literal data: 32258048 bytes
Matched data: 626671616 bytes
File list size: 40
Total bytes written: 463923
Total bytes read: 32569185

wrote 463923 bytes  read 32569185 bytes  2906.95 bytes/sec
total size is 658929664  speedup is 19.95
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


I thought - "Well, at least the file is now the correct size: 658 929 664 bytes". I will rsync'it again with the same server. But nope: same error message!

So, I changed server now (now on to cdimage.at.debian.org), and it rsyncs with 100% matched data:
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
binary-i386-1.iso
658923520 (99%)
ERROR: file corruption in binary-i386-1.iso. File changed during
transfer?

Number of files: 1
Number of files transferred: 1
Total file size: 658929664 bytes
Total transferred file size: 658929664 bytes
Literal data: 0 bytes
Matched data: 658929664 bytes
File list size: 40
Total bytes written: 482739
Total bytes read: 322252

wrote 482739 bytes  read 322252 bytes  578.92 bytes/sec
total size is 658929664  speedup is 818.56
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


Then I thought... "Hmmm, maybe this is a false error message, let's check it with MD5SUM":
D:\DEBIAN> md5sum -b binary-i386-1.iso

but the resulting md5 is *incorrect* :
b37f2769ce446a3b243fdea5cff4d6c6 *binary-i386-1.iso


And suddenly it struck me: "The proxy! Could it be a proxy's fault? Let's check the pseudo-image.log file"

Well, in that log, some of the files end with "Length: <size of file> [text/plain]" like this:

--20:24:28--

ftp://ftp.ua.pt:21/bigdisk/debian/dists/potato/main/binary-i386/admin/at_3.1.8-10.deb

           => `pseudo-image.download.5'
Connecting to proxy.example.pt:3128... connected!
HTTP proxy request sent, fetching headers... done.
Length: 37,472 [text/plain]

    0K -> .......... .......... .......... ......


However, other files look OK in the log (ending with "correct" mime types like application/x-tar):

--04:08:00--

ftp://ftp.ua.pt:21/bigdisk/debian/doc/package-developer/maint-guide.ru.html.tar.gz

           => `pseudo-image.download.25'
Connecting to proxy.example.pt:3128... connected!
HTTP proxy request sent, fetching headers... done.
Length: 27,963 [application/x-tar]

    0K -> .......... .......... .......


So, basically my questions are:

1) Was this problem the proxy's fault?

2) Is there any way to patch the ISO file to only re-download the files that were - apparently - downloaded in text mode, instead of binary?


Please help me! It's quite frustrating to have a 650 Meg ISO file that doesn't you any good   :(

Best wishes,

Ricardo Dias Marques
ricmarques@spamcop.net


--  
To UNSUBSCRIBE, email to debian-cd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: