Dealing with troublesome package upgrades or removals.

Posted by Steve on Fri 23 Sep 2005 at 16:04

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:

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.*

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:


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



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!



Posted by marki (82.119.xx.xx) on Fri 23 Sep 2005 at 20:29
I had similar problem with post-inst in libapache-mod-choke. The bug report was already submitted, so I sent only suggested solution.
Are bugs in these scripts fixed in stable? Or we have to wait for next release?

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Sat 24 Sep 2005 at 07:19
[ View Steve's Scratchpad | View Weblogs ]

In general bugs such as these will not be fixed in Stable, unless the package maintainer can convince the release manager(s) that they justify an upgrade in a point release.


[ Parent | Reply to this comment ]

Posted by Anonymous (207.46.xx.xx) on Tue 17 Apr 2012 at 06:33
I am new to this.
I just want to know detail steps of how to add postinst file in debian package, and how it will be invoked after installing. That is where to call postinst script (in rules file or somewhere else).
Please give detail steps.

[ Parent | Reply to this comment ]

Posted by andreyev (200.184.xx.xx) on Sat 24 Sep 2005 at 00:36
dpkg had a useful debug option, from the man page:

"-Doctal | --debug=octal
    Set debugging on. octal is formed by bitwise-orring
 desired values together from the list below (note that 
these values may change in future
releases). -Dh or --debug=help display these debugging 

     number  description
        1   Generally helpful progress information
        2   Invocation and status of maintainer scripts
       10   Output for each file processed
      100   Lots of output for each file processed
       20   Output for each configuration file
      200   Lots of output for each configuration file
       40   Dependencies and conflicts
      400   Lots of dependencies/conflicts output
     1000   Lots of drivel about e.g. the dpkg/info dir
     2000   Insane amounts of drivel"

In trouble with scripts, I run "dpkg -D2 foo-bar.deb" and
then I run manually each script that show warnings or 

PS: Ops, in this week I too had trouble with gforge 
packages... But this dont may means that we had a bug!
PPS: Sorry for english mistakes, I am still learning it.

[ Parent | Reply to this comment ]

Posted by Anonymous (89.132.xx.xx) on Fri 15 Dec 2006 at 00:07
Yeah, I also played around with the -D option, but it's relatively useless. Actually that's how I got to this page. It's so lame that there isn't an option to somehow debug the scripts and see where they fail. I'm not a bash expert but it has a debug switch that prints every command before executing it. It's the '-x' one. It an be specified just as -e is. There should be a global parameter that an be passed by dpkg to these scripts that turns debugging on or off in the scripts.

[ Parent | Reply to this comment ]

Posted by Anonymous (207.170.xx.xx) on Sun 25 Sep 2005 at 02:30
Score!! So one day I was being Dumb and tried to install the unstable bootsplash package from an un-official mirror, on my SARGE machine!!! Needless to say it didn't work (wouldn't install fully, and wouldn't uninstall fully either), until now. I simply went through and commented out the "set -e" lines from all of the scripts for the package and then: #apt-get remove bootsplash Hooray no errors, Finally I don't have to watch it try (and fail) to install EVERY time I use APT. Thank you !!! -GZ

[ Parent | Reply to this comment ]

Posted by fireboy (66.81.xx.xx) on Sun 26 Aug 2007 at 03:06
Thanks "Steve"!
I'm using SimpleMepis 6.5

I could not install/uninstall anything for over three weeks
now. I don't have much hair left had this gone on any longer.

Tried to uninstall taskjuggler and got this:

Preparing to replace taskjuggler 2.2.0-1ubuntu1 (using .../taskjuggler_2.2.0-1ubuntu1_i386.deb) ...
Unpacking replacement taskjuggler ...
touch: missing file operand
Try `touch --help' for more information.
dpkg: warning - old post-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
touch: missing file operand
Try `touch --help' for more information.
dpkg: error processing /var/cache/apt/archives/taskjuggler_2.2.0-1ubuntu1_i386.deb (--unpack):
subprocess new post-removal script returned error exit status 1
touch: missing file operand
Try `touch --help' for more information.
dpkg: error while cleaning up:
subprocess post-removal script returned error exit status 1

I found a link thru goggle to your article here.
I removed the "set e" and now life is good again.
Thanks again

[ Parent | Reply to this comment ]

Posted by Anonymous (64.166.xx.xx) on Mon 7 Apr 2008 at 15:22
This article saved my life.

[ Parent | Reply to this comment ]

Posted by linuxturtle (15.238.xx.xx) on Fri 23 Oct 2009 at 21:46
Whew! This article was certainly helpful, but doesn't it strike anyone else that a broken package should *not* be able to paralyze the entire package system? This seems like a severe flaw with dpkg, that it can't cope with a broken package w/out resorting to the user finding the package script that is causing the breakage and editing it. And since the article is from 2005, it's not like this is a new/unknown problem..

[ Parent | Reply to this comment ]

Posted by Anonymous (155.212.xx.xx) on Tue 22 Dec 2009 at 20:38
Technically you're only paralyzed if it's a dependency, as far as I know.

Letting packages run their own scripts to clean themselves up for removal is fraught, but no different than the headaches with uninstallers on Windows.

Unfortunately Linux packaging systems like to let packages leave doo-doo all over the filesystem rather than enforcing a convenient hierarchy that would allow purging and at worst leave some symlinks lying around. (No system is very good about this - even OS X, with its relatively sane .app objects, lets programs leave all sort of garbage in "Library" or other directories. IIRC PC-BSD seemed to be trying to enforce installation of a complete purgable dependency hierarchy per package; obviously a bit space-inefficient but I'm not sure how that's otherwise working out for them.)

Just being a little tidier (and shifting away from packages-can-run-whatever-script-they-want to packages-tell-one-standard-piece-of-code-where-they-might-put-thi ngs-and-what-to-remove) can go a long way. dpkg *has* this, with its .list files, but obviously some additional flexibility would be needed there to not just call additional arbitrary scripts per-package.

[ Parent | Reply to this comment ]

Posted by Anonymous (72.67.xx.xx) on Sun 30 May 2010 at 04:16
Much better than just giving away the answer, this article helps by telling you HOW or WHERE to find and solve the problem, so that you have a clue. Thank you, it has shown me what to look for in the future if this happens to me again.

[ Parent | Reply to this comment ]

Posted by Anonymous (196.1.xx.xx) on Fri 11 Mar 2011 at 14:03
Thanks sir/mam. This help me lot. Just need to remove -e option from any package which shown in error log that give trouble while removing.

[ Parent | Reply to this comment ]

Sign In







Current Poll

Will you stick to systemd as the default in Debian?

( 906 votes ~ 35 comments )