Hi, On Tue, Jan 05, 2016 at 11:46:57PM +0100, Gábor Gombás wrote: > The file on disk is corrupt, it contains just some binary garbage: > > # ls -l /var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-amd64_Packages > -rw-r--r--. 1 root root 256 Jan 3 16:24 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-amd64_Packages > > I noticed that when this error happens, usually multiple files get corrupted; > that turned out to be true this time as well: > > -rw-r--r--. 1 root root 311 Jan 4 09:52 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_contrib_binary-i386_Packages > -rw-r--r--. 1 root root 438 Jan 3 16:14 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_non-free_i18n_Translation-en > -rw-r--r--. 1 root root 256 Jan 3 16:24 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-amd64_Packages > -rw-r--r--. 1 root root 248 Jan 3 16:26 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-i386_Packages > -rw-r--r--. 1 root root 29 Jan 3 16:24 /var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_i18n_Translation-en > > Looking at the beginning of the corrupted files, there's a pattern which looks > like some kind of binary header - that might help figuring out where the > garbage is coming from: > > 0000000 1f 8b 08 00 b0 32 8a 56 02 03 4d 90 bd 6a 03 31 > 0000000 1f 8b 08 00 bd 3a 89 56 02 03 6d 92 d1 6e a3 30 > 0000000 1f 8b 08 00 3a 3d 89 56 02 03 45 8f 3d 6b 03 31 > 0000000 1f 8b 08 00 9a 3d 89 56 02 03 45 8f b1 6a c4 30 > 0000000 1f 8b 08 00 23 3d 89 56 02 03 b3 34 30 d6 b1 34 "1f 8b 08" is the gzip magic, but they aren't the compressed contents of the files they claim to be (they are simply too small for that). The hexdumps you provided are pretty short, but the last one reveals some content: "903,9". That looks like a pdiff patch and indeed: http://ftp.debian.org/debian/dists/stretch/contrib/i18n/Translation-en.diff/2016-01-03-1513.00.gz has a filesize of 29 and the complete content is "903,913d". So, for some reason the compressed pdiff file ends up in the location the patched up file should be placed in. Sorry for the obscenity, but "What the hell?!?". That doesn't make a whole lot of sense. :/ > This time, a btrfs snapshot just happened to be created about ~10 minutes > before running the above "apt update" command, and in that snapshot both the > file sizes and their contents look sensible: > > -rw-r--r--. 2 root root 239585 Jan 4 09:52 @.20160105/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_contrib_binary-i386_Packages > -rw-r--r--. 2 root root 383764 Jan 3 16:14 @.20160105/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_non-free_i18n_Translation-en > -rw-r--r--. 2 root root 224053 Jan 3 16:24 @.20160105/var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-amd64_Packages > -rw-r--r--. 2 root root 216925 Jan 3 16:26 @.20160105/var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_binary-i386_Packages > -rw-r--r--. 2 root root 168951 Jan 3 16:24 @.20160105/var/lib/apt/lists/ftp.at.debian.org_debian_dists_stretch_contrib_i18n_Translation-en > > I wasn't really doing anything else on the host, and "btrfs scrub" did not find > any inconsistency, it looks like the files were corrupted by apt itself. I don't know btrfs (as in I never used it), but I have to note that the modification times hint that the files are already up-to-date. And the filesize seems to indicate the same as its the size of the most current version of the file. The patching shouldn't have been started at all in this case… mmhhh. Now that I look again I see that you have two mirrors configured fetching the exact same stuff. apt 1.1 tries to be clever and if it notices that it is trying to work on the same file at the same time (literally, no deeper planing is performed yet) twice it works on it only once and hardlinks the result around (That is meant mostly for work=download, but merges also other actions). I have the feeling now that this is a bit too generic and gets confused here by pdiffs, unchanged files and different mirror states… Now that I have an idea I will try to reproduce this later (~ weekend) and figure out how to solve this then hopefully without reverting the merges entirely. As a "workaround" I would suggest using just one mirror for the time being – and depending on why you have this multimirror setup you might want to look into httpredir.debian.org as mirror. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature