Bug#812994: apt 1.2.1 fails to configure packages
On 4 February 2016 at 23:44, Guillem Jover <guillem@debian.org> wrote:
> On Thu, 2016-02-04 at 08:39:30 -0500, James McCoy wrote:
>> On Thu, Feb 04, 2016 at 12:56:53AM +0100, Guillem Jover wrote:
>> > On Wed, 2016-02-03 at 09:22:51 -0500, James McCoy wrote:
>> > > I had a similar problem today.
>> >
>> > > ...
>> > > Selecting previously unselected package libn32atomic1-mips64el-cross.
>> > > Preparing to unpack .../libjpeg62-turbo_1%3a1.4.2-2_amd64.deb ...
>> > > Unpacking libn32atomic1-mips64el-cross (5.3.1-7cross1) ...
>> > > ...
>> > > dpkg: error processing package libjpeg62-turbo:amd64 (--configure):
>> > > package libjpeg62-turbo:amd64 is already installed and configured
>> > > ...
>> >
>> > The first and third lines come supposedly from the .deb control file,
>> > the second from the filename.
>> >
>> > If this is just a problem with wrong strings, then libjpeg62-turbo:amd64
>> > in theory would not be already configured, just unpacked (but I might be
>> > missing context here).
>>
>> Well, version 1:1.4.1-2 of libjpeg62-turbo was already configured and
>> since the newer version wasn't unpacked (libn32atomic1-mips64el-cross
>> was instead), there was nothing to configure.
>
> My reasoning was all based on conjectures. But this is my thinking,
> since libjpeg62-turbo_1%3a1.4.2-2 is the version shown on the string,
> assuming that was the correct package being processed, if that was
> actually being unpacked, then I'd assume it would be upgrading from an
> older version than 1:1.4.1-2, and then the package would end up in the
> unpacked state. (But the log you provided might be missing other
> context, I assume the package was not previously configured too.)
>
> If the wrong string was libjpeg62-turbo_1%3a1.4.2-2_amd64.deb, and the
> correct information was coming from the .deb control file, then I guess
> you should have libn32atomic1-mips64el-cross installed? In which case
> that would be a very strong hint that the .deb provided by apt was not
> what it was supposed to be.
>
>> > > >From /var/log/dpkg.log:
>> > >
>> > > 2016-02-03 08:53:33 startup archives unpack
>> > > ...
>> > > 2016-02-03 08:53:40 install libn32atomic1-mips64el-cross:all <none> 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status half-installed libn32atomic1-mips64el-cross:all 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 5.3.1-7cross1
>> > > 2016-02-03 08:53:40 status unpacked libn32atomic1-mips64el-cross:all 5.3.1-7cross1
>> >
>> > Just to make sure, if you have the libjpeg62-turbo_1%3a1.4.2-2_amd64.deb
>> > around could you check that it really contains the libjpec62-turbo
>> > package inside with say dpkg-deb, or manually with ar+tar?
>>
>> I don't, but I've now disabled apt's automatic removal of the .deb when
>> a package is installed. I'll do this on all my hosts so next time I hit
>> the issue I'll be able to answer this question.
>
> Perfect thanks!
>
>> > If you have the previous status file in /var/backups, and you could
>> > try to reproduce this that would be great, otherwise, sending it here
>> > or to me and the apt maintainers in case of privacy concerns might help
>> > too.
>>
>> I downgraded libjpeg62-turbo and performed an upgrade again, but that
>> specific scenario didn't reproduce.
>
> Assuming this is not dependent on the state of the apt cache or
> something similar, what I'd do would be either debootstrap a new
> system and place the backed up status there before the issue, and try
> to upgrade using a snapshot from the same time. Or the slighly more
> dangerious option, for which I don't want to be responsible, ;) would
> be to backup your current status file, replace it with the one from
> before the issue and perform the above snapshotted upgrade. Once you
> are done you should be able to restore the status file, and reinstall
> any affected package.
>
>> > > I'm not sure if this is something to do with how apt is driving dpkg or
>> > > dpkg itself is getting confused, but hopefully this helps.
>> >
>> > (It could well be dak being confused perhaps? But… :)
>>
>> That would have broader visibility, though, wouldn't it?
>
> Yeah, and would mean that it can be easily reproduced. A compromised
> mirror does not seem likely either. Just grasping at straws I guess.
>
> Thanks,
> Guillem
>
On IRC it was mentioned that bug #813000 mentions that the update can
generate Packages files in the APT dir with messed up contents. I'm
not entirely sure it's related, but maybe it is. That must be a very
unlikely incarnation of that bug though (two packages would need their
Filename and various hash sum fields replaced by that of another
package).
We cannot reproduce that one yet, but I'm working on it (running apt
update manually now, and backing up lists before update).
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: