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
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
