Re: rsyncing images
On Fri, Sep 15, 2000 at 12:29:59AM +0200, J.A. Bezemer wrote:
> I just don't understand... I know by now that rsync does behave strangely
> sometimes, but I've never heard anything like this. You might try
> --block-size=20000 or even 123456 the next time, maybe that helps.
> (And I think starting from the pseudo-image+330M again (if you still have it)
> would work best.)
I tried the same mirror with 20000, skipped the 330M, then started
downloading diligently again... I know that they use an older rsync
though... now trying a mirror using same version of rsync, with 123456.
<time passes>
Interesting: I think it downloaded one block near the beginning...
(Whereabouts was the bad bit in the second image...?) but it is also
downloading everything from 330299209... I think I'll try regenerating
the pseudo image again. And then adding the 440Meg segment at the end...
(any reason whatsoever to rather add the 330? Even if the extra 110 is
corrupt, it will then simply be ignored?)
> Hmm. You were talking about a local mirror; if you're accessing it by FTP it
> just _might_ be that it decided to switch to serving in ASCII mode halfway
> making the pseudo-image. The easiest way to check that is to open the image in
> mc(1)'s viewer (F3), then F4 to switch to hex mode and use F5 to get somewhere
> `deep' in the offending part. There must be present both `single' 0A's and
> `single' 0D's. If you see too many OD-OA's, then that's the problem.
There are many sing 0D's, and many single 0A's, and a couple of 0D0A's.
I'll regenerate the pseudo image on Sunday.
$ hexdump binary-i386-2.iso | grep 0d0a | wc
This should give half of the 0d0a's, statistically. binary-i38602.iso is
my pseudo+9M+330M image. (If I want to use the +440M, I'll probably grab
the first 700M of the pseudo+9+330 image, and add the 440 to that - but
at this point I'll rather just take a new pseudo+440, seeing as my
pseudo is clearly very incorrect.)
Thanks,
Hugo
Reply to: