Bug#670900: apt-get upgrade bails out with E: Internal Error, No file name for gcc-4.7-base
On Sun, Sep 2, 2012 at 6:29 PM, Guillem Jover <guillem@debian.org> wrote:
> On Mon, 2012-04-30 at 09:52:43 +0200, Martin Steigerwald wrote:
> I think this bug report should be serious, because once hit, apt cannot
> recover itself in any way, it is pretty easy to get into, and the only
> way to proceed is to run for example: «dpkg --configure --pending»,
> but that might not be enough if the dependencies are not satisfiable.
Predependency for reproducing this seems to be that the unpacked package
is (pseudo)essential. The thing is that APT tries to unpack a package,
which is already unpacked, but it earlier decided that it doesn't need
to download the package as it already here (unpacked) - so you see
this error as APT can't find the file as it didn't download it
(at least not in its usual location in your example).
There was a "similar" bug I fixed earlier last week in the not-pseudo-
essential path which was the reverse: APT never unpacked an already unpacked
package even if it wanted to install a different version usually screwing
your system further as you went from 'same file with different hash' to
'different versions of an M-A:same package should be configured'.
I will opportunistically close this bugreport with these two changes then,
even through I couldn't reproduce either.
(I am hopefully able to try a bit harder later today.)
The libpam-modules example above e.g. gives me a dpkg error on unpacking:
dpkg: error processing libpam-modules_1.1.3-7.1_amd64.deb (--unpack):
trying to overwrite shared '/etc/security/time.conf', which is
different from other instances of package libpam-modules:amd64
i386 is unpacked, unpacking amd64 -- the other way around same error with
a different file (/etc/security/limits.conf). I don't remember changing
these files - noting that :i386 wasn't installed on my system previously.
Best regards
David Kalnischkies
Reply to: