forcemerge 499070 497041 thanks On Tue, 2008-09-16 at 01:06:05 +0200, Alexander Prinsier wrote: > Package: dpkg > Version: 1.14.22 > Severity: serious > > I was installing php5 while my system ran out of disk space. dpkg > breaks, and leaves the system in a state where I can no longer use dpkg. > To find out the version number of dpkg I used /var/log/dpkg.log, as I > couldn't use dpkg to find it's own version number... Hope it's the > correct one.
> This is what happened: > > [...] > Selecting previously deselected package libjpeg62. > Unpacking libjpeg62 (from .../libjpeg62_6b-14_i386.deb) ... > dpkg: error processing /var/cache/apt/archives/libjpeg62_6b-14_i386.deb > (--unpack): > failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during > `./usr/share/doc/libjpeg62/copyright': Disk quota exceeded > Selecting previously deselected package libdjvulibre21. > Unpacking libdjvulibre21 (from .../libdjvulibre21_3.5.20-8_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/libdjvulibre21_3.5.20-8_i386.deb (--unpack): > failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during > `./usr/lib/libdjvulibre.so.21.0.0': Disk quota exceeded > dpkg-deb: subprocess paste killed by signal (Broken pipe) > Selecting previously deselected package libxpm4. > Unpacking libxpm4 (from .../libxpm4_1%3a3.5.7-1_i386.deb) ... > Selecting previously deselected package libgd2-xpm. > Unpacking libgd2-xpm (from .../libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/libgd2-xpm_2.0.36~rc1~dfsg-3_i386.deb (--unpack): > unable to flush /var/lib/dpkg/updates/tmp.i after padding: Disk quota > exceeded Here's where the problem starts. That «tmp.i» file is the one that has been filled with '#padding' lines, the fflush() in createimptmp() fails, and it ohshite()s, but just before it has been able to rewind the file to the beginning. > Processing triggers for man-db ... > /usr/bin/mandb: can't write to /var/cache/man/19933: Disk quota exceeded > gdbm fatal: read error > dpkg: failed to write status record about `libcairo2' to > `/var/lib/dpkg/status': Disk quota exceeded > E: Sub-process /usr/bin/dpkg returned an error code (2) > A package failed to install. Trying to recover: > dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1: > newline in field name `#padding' > Press return to continue. The second problem is that even if the ohshite() called from createimptmp() is protected inside an onerr_abort section, the execution continues in archivefiles(), out of process_archive() but into process_queue(), which at some point calls a modstatdb_note(), moving the «tmp.i» file into the «0119» one, then another ohshite() is called and the onerr_abort is sensed again, making process_queue() terminate its loop. > # dpkg --configure -a > dpkg: parse error, in file `/var/lib/dpkg/updates/0119' near line 1: > newline in field name `#padding' > # But at the point that modstat_note() was called the function wrote at the end of it, preserving all the '#padding' lines, and making dpkg barf subsequently. So I think there's two things to fix here, one is that the fseek() in createimptmp() should be done just before the fwrite() in modstatdb_note_core() to guarantee that we are going to be always at the beginning, and we make proper use of the reserved space allocated previously with those '#padding' lines to avoid the out of space condition. That's a 4-liner patch, which should be fine for lenny, and prevents this bogus condition were the user most probably is going to remove that file to be able to continue, which might produce an inconsistent state in the dpkg db. And the real problem is that there might not be an easy manual fix by the users if the status data could not be completely written to the update file. The other is that when onerr_abort is signaled dpkg should not continue processing anything anymore, it should just do whatever cleanup is required and exit. But that can wait probably post-lenny. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]