[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg 1.17.24 trashing files



Hi!

On Thu, 2015-04-02 at 21:09:44 +0200, Peter Gervai wrote:
> After installing dpkg_1.17.24_amd64 everything started crashing really hard.
> 
> It turned out that most files had 0x00 appended at their end, like
> bash_completion.sh (making it non-exacutable), READMEs and possibly
> others. I've tried to strace it but I dont' see  obvius obvious
> problem.

That's very strange.

> This is one file I have tested the problem on:
> 
> lstat("/usr/share/doc/bc/README", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> rmdir("/usr/share/doc/bc/README.dpkg-new") = -1 ENOENT (No such file
> or directory)
> rmdir("/usr/share/doc/bc/README.dpkg-tmp") = -1 ENOENT (No such file
> or directory)
> open("/usr/share/doc/bc/README.dpkg-new", O_WRONLY|O_CREAT|O_EXCL, 0) = 11
> fallocate(11, 0, 0, 3522)               = 0
> read(10, "GNU bc version 1.06:\n\nExtra configuration options:\n\n
> .... value of\neach print as the number is
> printed.\n-----------------------------------------------------------------------\n",
> 3522) = 3522
> write(11, "GNU bc version 1.06:\n\nExtra configuration options:\n\n
> ....... print as the number is
> printed.\n-----------------------------------------------------------------------\n",
> 3522) = 3522
> 
> So far it looks good, there are no \0 at the end.
> 
> lseek(10, 62, SEEK_CUR)                 = -1 ESPIPE (Illegal seek)
> read(10, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
> 62) = 62

This should simply be the trailing 0s read from the tar archive entry
for that file (from a dpkg-deb pipe, that's why lseek does not work
there), which are skipped by reading and *discarding* them, as can be
seen that there's no other write before the close later on.

> sync_file_range(11, 0, 0, SYNC_FILE_RANGE_WRITE) = 0
> fchown(11, 0, 0)                        = 0
> fchmod(11, 0644)                        = 0
> close(11)                               = 0
> utimes("/usr/share/doc/bc/README.dpkg-new", {{1428000304, 0},
> {1254697207, 0}}) = 0
> link("/usr/share/doc/bc/README", "/usr/share/doc/bc/README.dpkg-tmp") = 0
> 
> I don't spot what happens, but I believe at this point there are
> approximately 62 x \0 at the end of the file.

I don't see how that's possible with this trace. Did you hexdump the
affected files and saw that?

> Downgrading to 1.16.15 seems to have fixed the problem.

You downgraded only dpkg or more packages, and reinstalled what other
packages too?

It would be nice to track this down (in case it's not a hardware
problem, or an issue in a lower level package, like glibc or kernel).
With dpkg 1.17.x you can run «dpkg -V» to see what filesystem files
have changed compared to the files in the .deb.

Thanks,
Guillem


Reply to: