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

Re: Final ISO of correct size BUT incorrect MD5SUM



Hi Anne,

First of all, let me compliment you for this great piece of software you wrote (I'm talking about the Pseudo Image Kit of course!  :)

Second, let me thank you for the lightning-quick and on-the-money answer you gave me. Read on...


On Tue, 12 Sep 2000, J.A. Bezemer wrote:

> [snip very fine report -- more people should do that ;-]

Thank you very much for the compliment. I really appreciate it :)
RANT: I try to be detailed when I describe the problems I face. This way, the people who could help me know what has and has not been done, and can mention the possible solutions. It really avoids 
the "e-mail ping-pong" ("So, what is your platform?" <-> "My platform is Windows?"; "So, what were the commands you typed" <-> "I typed this and then that"). With the "e-mail ping-pong", it can take two to three days until someone actually gets all the relevant information to help the person who asks for help. It makes you wonder: who is doing a favour to whom? END OF RANT.


[snip] 
> (...) if it were [the proxy´s fault], rsync should have corrected 
> it no matter what. [snip]

Yeah, I thought so. Specially because I used _NO_ proxies when rsync'ing. 
Thanks for the information.

[snip] 
> Very likely your image is 99% correct, but rsync doesn`t spot 
> where the problem is. The trick in these cases is to use a 
> (much) larger, and possibly "weird" --block-size, like 20000 instead 
> of 8192,  or even 123456. I think you`ll then see a literal download 
> of exactly one block, after which the md5sum should be okay.

J-A-C-K-P-O-T! :)

I tried exactly that, and it worked. This time, I rsync'ed with "no less" than cdimage.debian.org itself:
rsync --verbose --progress --stats --block-size=20000 cdimage.debian.org::debian-cd/2.2_rev0/i386/binary-i386-1.iso .

After some minutes, I got the "99% error message, but this time there was 20 000 bytes 
of Literal Data. That is, exactly one block of Literal Data, just like you said:

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 
binary-i386-1.iso 
658920000 (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: 20000 bytes 
Matched data: 658909664 bytes 
File list size: 40 
Total bytes written: 197806 
Total bytes read: 152610
wrote 197806 bytes read 152610 bytes 451.86 bytes/sec 
total size is 658929664 speedup is 1880.42 
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

So, I ran md5sum again... and this time it checked!

D:\debian\pik2>md5sum -b binary-i386-1.iso 
c4435b6a6b8dd91ea51bd69bfb8642df *binary-i386-1.iso

Next thing, I opened "Easy CD Creator" and burned the ISO image file. I still didn't try to boot from it, but I can access the CD from Windows Explorer and opened successfully some .html files that are in the /install/doc directory in the CD. 

By the way, the /install/doc file has the working documentation in HTML, but the /doc/install has more or less the same filenames, but all of its files have 0 bytes. As the md5sum checked alright, I assume this is the case with ALL the Official 2.2r0 CD images... or is it NOT?


Maybe this "99% error message problem-and-solution" (change block size to 20000, and don't bother if md5sum checks alright) could be added to the online FAQ http://cdimage.debian.org/faq.html and also to the README file?


Thanks again for all the help, Anne :)   And keep up with your great work!

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: