Debian Administration

Dealing with troublesome package upgrades or removals.

There are times when you have a package which you cannot upgrade, remove, or install due to scripting errors. 99% of the time these will be bugs which will be fixed after you've reported them. But if you cannot wait you'll need to fix them yourself.

In addition to the actual files in the package a binary .deb file contains other things:

• Information on its dependancies.
• Scripts to run at various times.
  • Pre-installation scripts
  • Post-installation scripts.
  • Pre-removal scripts.
  • Post-removal scripts.

These scripts are often overlooked when examining packages and many users never need to touch them.

To pick a package at random, the gnump3d package contains two scripts. One "postinst" which runs just after the package has been installed, and another "postrm" which runs just after the package has been removed.

In this case the scripts are very simple and serve only to:

• Add a new user to the system so that the server can run as its own dedicated user. (postinst)
• Setup a logfile directory, and optionally upgrade an obsolete configuration file. (postinst)
• Remove the logfiles, and configuration files when the package is purged. (postrm).

(Note: The new user that is added is never removed. This is common practise in Debian packages).

So what does this mean? Well in normal cases you'd not notice these being executed and the scripts will be bug free.

Sometimes you will see errors, such as this one:

root@mystery:~# dpkg --purge gforge-ldap-openldap
dpkg: error processing gforge-ldap-openldap (--purge):
 subprocess pre-removal script returned error exit status 5
Errors were encountered while processing:
 gforge-ldap-openldap

What do we see here? Well the command should have purged the package gforge-ldap-openldap. Instead it gave an error, and failed.

In this case we can see the source of the error:

subprocess pre-removal script returned error exit status 5

The next step is to find the script, and see why it fails.

All the scripts are stored in a single location, named after the package that they belong to. The directory to examine is /var/lib/dpkg/info, and to return to our GNUMP3d package we can see its files with:

skx@mystery:~$ ls -1 /var/lib/dpkg/info/gnump3d.*
/var/lib/dpkg/info/gnump3d.conffiles
/var/lib/dpkg/info/gnump3d.config
/var/lib/dpkg/info/gnump3d.list
/var/lib/dpkg/info/gnump3d.md5sums
/var/lib/dpkg/info/gnump3d.postinst
/var/lib/dpkg/info/gnump3d.postrm
/var/lib/dpkg/info/gnump3d.prerm
/var/lib/dpkg/info/gnump3d.templates
skx@mystery:~$ 

Here there are some files that you can ignore:

• .conffiles
  • This contains a list of all the configuration files associated with this package.
• .config
  • This file contains the results of any debconf based configuration questions.
• .list
  • This file contains all the files included in the package.
• .md5sums
  • Predictably this file contains the MD5 checksum of all files installed by the package. This can be useful if you wish to check your systems integrity; although using tripwire or aide would be preferable.

The other files we see are the scripts associated with the package:

• gnump3d.postinst
• gnump3d.prerm
• gnump3d.postrm

These scripts will run at the appropriate time (post-install, or pre-removal and post-removal respectively).

The gforge-ldap-openldap error message we saw was because the script file failed:

/var/lib/dpkg/info/gforge-ldap-openldap.prerm

To fix this you have two choices:

• Edit the script to make the failure non-terminal.
• Examine the script and determine why it fails.

In general most of the scripts associated with Debian packages will begin with:

#!/bin/sh -e

Or:

#!/bin/sh

set -e

Either of these two scripts will abort with an error if something fails. A simple fix is to remove the "-e", or the "set -e" line from the script before repeating your upgrade/install/removal attempt.

A more thorough fix is beyond the scope of this introduction, but if you can follow the script you may be able to work out what is failing and correct the problem.

Don't forget to report a bug!

Add Comment Printable version

 

<<< Automatically Blocking SSH Attackes From Script Kiddies? Secure Networking within kernel >>>