On Mon 22 Oct 2007, Andreas Ley wrote: > > At least when syncing the 2007-10-20T13:49:53 version of > security.debian.org::debian-security/dists/etch/updates/main/binary-i386/Packages.gz > on etch (2.6.9-2etch1) or sarge (2.6.4-6) to an nfs destination, rsync writes > zeroes from 4c00 to 4fff in the destination file. Local destinations work > fine, > as does rsync on woody (2.5.5-0.6). Other source files haven't been tested > yet. > The same applies to a self-compiled (on woody) 2.6.9 with sources from > rsync.samba.org - works on woody, fails on sarge and etch.
I've tried it on a number of different systems, both with and without transferring to an NFS system, on different architectures, but I cannot reproduce the problem you're seeing. I'm wondering whether perhaps one of the security mirror sites has a bad copy of the Packages.gz file. When I lookup the IP address, I get three answers: security.debian.org A 128.31.0.36 security.debian.org A 212.211.132.32 security.debian.org A 212.211.132.250 The first gives a connection refused, the other two give the correct file (verified with the md5sum as listed in http://security.debian.org/dists/stable/updates/Release.gpg ) If you repeat the transfer with -vic options added, does it in fact report that the checksum is wrong and attempt to update? Otherwise, a transcript of the output given by -vvvvv while it goes wrong would be helpful, including an strace log as well (dont' forget -f option to strace, as rsync forks). thanks Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
