Re: rsyncing images
On Thu, 14 Sep 2000, Hugo van der Merwe wrote:
> On Thu, Sep 14, 2000 at 12:54:32AM +0200, J.A. Bezemer wrote:
> > BTW, it's usually needed to run twice for the 1_NONUS image, because most
> > servers don't have non-US in the place the .list file wants to have it;
> > however that should be fine since all non-US is nicely clustered together.
>
> I did that: although I actually downloaded the non-US stuff first.
>
> > > I'll redo the first image. The second one works perfectly. Skipped first
> > > 9 Megs, downloaded two to three megs, then started skipping most of it.
> >
> > Ah, that's at least behaving nicely.
>
> I struck disaster again... It ran fine until about 300 megs, I think
> there was a couple megs to download at 320 megs, at about 330 the modem
> cut me off. I resumed the d/l (again by adding the successful 330 megs
> to the end of the pseudo image - it's getting a little big... ;), the
> first 330 skipped nicely, then at around 340, it started d/ling
> virtually everything. After three hours, I gave up on it. It had
> progressed to "data recv 32768 at 409644469"... The modem downloaded
> 66725584 bytes in those 204 minutes (sent under two and a half). I
> didn't do very much else with the connection - I think just browsed the
> Debian web site for some mirroring info.
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.)
> It's really weird that my pseudo images are so "incorrect"... is there a
> way to verify them? (Other than the rsyncing process, which should be
> verification enough.)
Other than extracting individual files manually (which is terrible) and
checking its md5sum against the Packages file on some completely other mirror,
there's no verification method I can think of.
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.
Regards,
Anne Bezemer
Reply to: