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

Bug#812994: apt 1.2.1 fails to configure packages



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


Reply to: