Debugging Dpkg Problems

From Granizada

Jump to: navigation, search

Contents

About Dpkg

If you use distributions based on Debian, and especially if you use pre-release versions, you'll occasionally see dpkg problems such as an improper dependency or an installation problem due to some condition not being met. In the second half of 2006 pre-release includes Debian's Etch and Ubuntu's Edgy Eft.

The reason such problems are rare is that Debian's procedures and policies tend to produce fairly high quality packages, even in prerelease. They are usually simple to fix if you know apply a logical debugging strategy. Otherwise they can drive you mad.

Most errors encountered with apt-get manifest as dependency errors. However the root cause of the failure may be a bug in how the package works rather than the list of dependencies.

A good trick is to assume that if only you can get a broken apt-get cycle going again then everything will fix itself, so for example temporarily renaming a file is usually fine, and assuming that later versions of a packge fix the bug often works too.

If you don't like this sort of thing, don't use a development distribution!

If you have more basic dpkg questions, see this DebianHelp UK article.


Dan 09:23, 23 September 2006 (CST)

Dependency Error: Libc6 Upgrade Fails

This Ubuntu Edgy Eft problem looks like a package puts files in the wrong place but actually it is a bug in the dependency list for a different package. Here's the error:

# apt-get dist-upgrade
    :
    :
753 upgraded, 48 newly installed, 16 to remove and 3 not upgraded.
1 not fully installed or removed.
Need to get 342MB/423.8MB of archives.
After unpacking 24.1MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 255104 files and directories currently installed.)
Preparing to replace libc6 2.4-1ubuntu6 (using .../libc6_2.4-1ubuntu10_i386.deb) ...
Matching libraries: /usr/lib/libpthread.so.20 /lib/ld-linux.so.2

A copy of glibc was found in an unexpected directory.
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library and try again.
dpkg: error processing /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb (--unpack):
 subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

That's odd. For a start it's a special case; the GNU C library is required for every dynamically linked program (ie most of them) to run and the packagers are very careful about doing upgrades. So for example if I were to take a wild guess and rename /lib/ld-linux.so.2 to something else the mv command would be the last one I ran -- try it when running from a bootable CD to see what I mean!

This error message isn't very helpful, but then this is a very rare condition (at least I've never seen it before.) First step is to locate what is putting it out. On a Debian-based system apt-get uses dpkg underneath but it isn't likely that dpkg knows about a specific package, even glibc. So it must be information in the package itself (you can do a partial check with strings on `which dpkg` and searching the resulting text, where no match means string isn't compiled into the binary.)

Finding the Problem

Let's try to install just the offending package:

# dpkg -i  /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb
(Reading database ... 255104 files and directories currently installed.)
Preparing to replace libc6 2.4-1ubuntu6 (using .../libc6_2.4-1ubuntu10_i386.deb) ...
Matching libraries: /usr/lib/libpthread.so.20 /lib/ld-linux.so.2

A copy of glibc was found in an unexpected directory.
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library and try again.
dpkg: error processing /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb (--install):
 subprocess pre-installation script returned error exit status 1
sudo Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb

Normally the next step is to try forcing dpkg to install anyway, using the --force-thing options explained in the man page. But it won't work this time, the package returns a critical error before it starts processing the commandline logic.

Maybe there's a clue in the dpkg debugging messages. So turn maximum debugging on using:

$ dpkg --debug=3773 -i /var/cache /apt/archives/libc6_2.4-1ubuntu10_i386.deb

Nope, nothing helpful.

But at least we know just one package is involved here. Let's see if we can find the message, which must be in the data that makes up a Debian package.

Fixing the Problem

Check you have a sources line in your /etc/apt/sources.list and then in an empty directory run:

 $ apt-get source libc6

This will download everything required to create the .deb file that is ostensibly causing the trouble, in this case libc6_2.4-1ubuntu10_i386.deb. We could also unpack the .deb, but we're more likely to find explanatory files and documentation in the source than the destination .deb binary.

$ find . -exec grep -l "A copy of glibc was found in an unexpected directory" {} \; -print
./glibc-2.4/debian/debhelper.in/libc.preinst

In a Debian package, the preinst script is a bash program that is run before installing a package (see man dpkg for a description of the steps taken on in/deinstallation.) Looking at this script shows the string appears in a function called check_dirs, with this handy comment:

        # See if the found libraries are compatible with the system ld.so;
        # if they aren't, they'll be ignored.  Check e_ident, e_type (which
        # will just be ET_DYN), and e_machine.  If a match is found, there
        # is a risk of breakage.

The code in this function is reading the first 20 bytes of the current ld.so and comparing it with the first 20 bytes of other critical libraries. If there is a match, it means replacing ld_so will stop this other critical library from working. In this case the other library is libpthread, so all threaded applications would break after ld_so was upgraded.

This of course should never happen; someone didn't get the dependencies right in the libpthreads package! But this is easy to fix.

So, where does this library come from?

$ dpkg -l | grep libpthread
ii  libpthread20    2.0.7-2ubuntu2   The GNU Portable Threads (pthread emulation)

Ideally we would just uninstall this package, provided not much depends on it. Let's try:

# apt-get --purge remove  libpthread20
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
    :
    :
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

That isn't going to work because apt's dependencies can't be solved because we have a package being a critical block, and we can't alter package states without solving this block. It's a big circle.

What we need to do is forcibly install glibc, and then hopefully everything will resolve itself after an apt-get -f install. I don't need any threaded applications in order to run apt from a shell, so I can just move the binaries where the preinst script won't find them:

# mkdir /usr/lib/temp
# mv /usr/lib/libpthread* /usr/lib/temp

It is not a good idea to put files like this under /tmp, because it is deleted on every reboot and your machine might go down before you've finished this recovery process.

And now it works:

# dpkg -i  /var/cache/apt/archives/libc6_2.4-1ubuntu10_i386.deb
(Reading database ... 255104 files and directories currently installed.)
Preparing to replace libc6 2.4-1ubuntu6 (using .../libc6_2.4-1ubuntu10_i386.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.4-1ubuntu10) ...

# apt-get -f install
Reading package lists... Done
   :
   :

Put the pthreads library back and continue with apt-get dist-upgrade.

Upstream Package Error: Python Upgrade Fails

This Ubuntu Edgy Eft problem looks at first glance like some Ubuntu developer got the dependencies wrong:

# apt-get install python
Reading package lists... Done
Building dependency tree
Reading state information... Done
Tal vez quiera ejecutar `apt-get -f install' para corregirlo:
Los siguientes paquetes tienen dependencias incumplidas:
  python: Depends: python-minimal (= 2.4.3-11ubuntu3) pero 2.4.3-5ubuntu1 va a ser instalado
  python-examples: Depends: python (= 2.4.3-5ubuntu1) pero 2.4.3-11ubuntu3 va a ser instalado
  python2.4: Depends: python2.4-minimal (= 2.4.3-7ubuntu2) pero 2.4.3-8ubuntu1 va a ser instalado
E: Dependencias incumplidas. Intente 'apt-get -f install' sin paquetes (o especifique una soluciĆ³n).

So it looks like this is a circular dependency. However, if you do apt-get -f install or apt-get remove ANYTHING, you get:

   :
 subprocess pre-removal script returned error exit status 1
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1329, in ?
    main()
  File "/usr/bin/pycentral", line 1323, in main
    rv = action.run(global_options)
  File "/usr/bin/pycentral", line 854, in run
    runtimes = get_installed_runtimes()
  File "/usr/bin/pycentral", line 197, in get_installed_runtimes
    old = pyversions.old_versions()
  File "/usr/share/pycentral-data/pyversions.py", line 56, in old_versions
    value = config.get('DEFAULT', 'old-versions')
  File "/usr/lib/python2.4/ConfigParser.py", line 520, in get
    raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'old-versions' in section: 'DEFAULT'
dpkg: error while cleaning up:
 subprocess post-installation script returned error exit status 1
   :

So it seems more likely to be a problem with code written by the Python project that is used to upgrade from one version of Python to the next. One option is to try to fix the .py file.

Bug 57121 at launchpad.net describes exactly this problem. But the solutions don't recognise the main strength of the Debian-style development model. Why hack around with Python code when almost certainly the problem has been fixed in the next version of the Python package? We can't use dpkg to upgrade anything, but a .deb is just an archive of files we can easily pull apart.

This is what I did:

$ mkdir deche
$ dpkg --extract /var/cache/apt/archives/python-minimal_2.4.3-11ubuntu3_all.deb deche/
$ diff -u deche/usr/share/python/pyversions.py  /usr/share/python/pyversions.py
    :

Seems like there have been some changes to do with upgrading. Looks like someone noticed the problem and it is highly likely to be compatible with what is really just the same Python packages.

# mv /usr/share/python/pyversions.py /usr/share/python/pyversions.py.old
# mv deche/usr/share/python/pyversions.py /usr/share/python

Now apt-get and friends all work again.

Confused apt Database: Package Install Fails

This is a classic situation where the apt system is confused by a previous error. It is in an inconsistent state and complains about a package being uninstallable even though there is nothing wrong with it or its dependencies:

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these.
The following packages have unmet dependencies:
  python: Depends: python-minimal (= 2.4.3-5ubuntu1) but 2.4.3-11ubuntu3 is installed
  python2.4: Depends: python2.4-minimal (= 2.4.3-7ubuntu2) but 2.4.3-8ubuntu1 is installed
E: Unmet dependencies. Try using -f.
dan@fika:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
    :
    :
Do you want to continue [Y/n]? y
(Reading database ... 255285 files and directories currently installed.)
Preparing to replace python-examples 2.4.3-5ubuntu1 (using .../python-examples_2.4.3-11ubuntu3_all.deb) ...
Unpacking replacement python-examples ...
dpkg: python-tk: dependency problems, but removing anyway as you request:
 scribus depends on python-tk; however:
  Package python-tk is to be removed.
 python-unit depends on python-tk.
 scribus-ng depends on python-tk; however:
  Package python-tk is to be removed.
 python2.4-unit depends on python2.4-tk; however:
  Package python2.4-tk is not installed.
  Package python-tk which provides python2.4-tk is to be removed.
 python2.4-epydoc depends on python2.4-tk; however:
  Package python2.4-tk is not installed.
  Package python-tk which provides python2.4-tk is to be removed.
dpkg: error processing python-tk (--remove):
 Package is in a very bad inconsistent state - you should
 reinstall it before attempting a removal.
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
Cancelado
Errors were encountered while processing: python-tk

In this situation I've just fixed something manually and so I guess that apt is confused. My first try could be to install just the package in question by itself:

# apt-get install python-tk
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
  python: Depends: python-minimal (= 2.4.3-5ubuntu1) but 2.4.3-11ubuntu3 is to be installed
  python-examples: Depends: python (= 2.4.3-11ubuntu3) but 2.4.3-5ubuntu1 is to be installed
  python2.4: Depends: python2.4-minimal (= 2.4.3-7ubuntu2) but 2.4.3-8ubuntu1 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
dan@fika:~$ sudo dpkg -i /var/cache/apt/archives/python-tk_2.4.3-
python-tk_2.4.3-1ubuntu2_i386.deb  python-tk_2.4.3-4ubuntu1_i386.deb
dan@fika:~$ sudo dpkg -i /var/cache/apt/archives/python-tk_2.4.3-4ubuntu1_i386.deb
Selecting previously deselected package python-tk.
(Reading database ... 255285 files and directories currently installed.)
Preparing to replace python-tk 2.4.3-1ubuntu2 (using .../python-tk_2.4.3-4ubuntu1_i386.deb) ...
WARNING: using old version '/usr/bin/python2.3' found
Unpacking replacement python-tk ...
dpkg: dependency problems prevent configuration of python-tk:
 python-tk depends on libx11-6; however:
  Package libx11-6 is not configured yet.
dpkg: error processing python-tk (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python-tk

This didn't work, but it looks good because the problem is not very serious. I don't really think that installing python-tk (or any X11 program) while a newly installed libx11 is unconfigured is likely to cause trouble. The reason it is installed but unconfigured is almost certainly that apt-get fell apart during some previous problem that I fixed manually.

Chances are if I force python-tk to install regardless of this non-critical dependency issue apt-get will go back and complete installation/configuration of all packages that need it, including the new libx11. I could use the appropriate --force option but I'm lazy so I use --force-all.

# dpkg -i --force-all /var/cache/apt/archives/python-tk_2.4.3-4ubuntu1_i386.deb
(Reading database ... 255270 files and directories currently installed.)
Preparing to replace python-tk 2.4.3-4ubuntu1 (using .../python-tk_2.4.3-4ubuntu1_i386.deb) ...
Unpacking replacement python-tk ...
dpkg: also configuring `libx11-6' (required by `python-tk')
dpkg: also configuring `libx11-data' (required by `libx11-6')
Setting up libx11-data (1.0.3-0ubuntu3) ...
Setting up libx11-6 (1.0.3-0ubuntu3) ...
Setting up python-tk (2.4.3-4ubuntu1) ...

So it even did it in the same run... I think dpkg is not clever enough to resolve the dependency list of errors in this case, because some later action fixed an earlier problem.

Sure enough, after one more apt-get -f install to fix a similar sequence of dependent configuration/instalation problems, I was able to complete my apt-get dist-upgrade.

Creative Commons License
Creative Commons Attribution iconCreative Commons Share Alike icon
This content is licensed under the Creative Commons
Attribution ShareAlike License v. 2.5:
http://creativecommons.org/licenses/by-sa/2.5/
GNU head GFDL: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". (shearer.org uses but does not currently recommend the GDFL and here's the explanation why. )
Personal tools
Navigation