Continuing my series of articles on dpkg’s errors, this time I’ll cover a pretty common one which has several variations:
Setting up acpid (1:2.0.12-1) ... rm: cannot remove `/etc/rc1.d/K20acpid': No such file or directory dpkg: error processing acpid (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: acpid
Even if dpkg is failing and outputting the error message, the real problem is not in dpkg but in the installed package (acpid in the example above). As we already learned, a package contains not only files but also “maintainer scripts” that are executed at various points of the installation process (see some useful graphics to understand how they are called, thanks to Margarita Manterola).
In the introductory example it was acpid’s “post-installation script” that failed, and dpkg is only forwarding that failure back to the caller. The maintainer scripts are stored in /var/lib/dpkg/info/. You can thus inspect them and even modify them if you hit a bug and want to work around it (do this only if you understand what you do!).
One common modification is to add “set -x” at the start of the script and to retry the failing operation. That way you can see what’s executed exactly. Here’s what the output could look like after the addition of “set -x” to /var/lib/dpkg/info/acpid.postinst:
$ sudo dpkg --configure acpid Setting up acpid (1:2.0.12-1) ... + dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.10-3 + dpkg --compare-versions 1:2.0.11-1 lt-nl 1.0.6-16 + dpkg --compare-versions 1:2.0.11-1 lt 1.0.6-6 + rm /etc/rc1.d/K20acpid rm: cannot remove `/etc/rc1.d/K20acpid': No such file or directory dpkg: error processing acpid (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: acpid
This output helps you locate the command that is actually failing. Here’s it’s relatively easy since we have an error message from “rm”. And the fix is trivial too, we replace “rm” with “rm -f” so that it doesn’t fail when the file doesn’t exist (this is a fake bug I made up for this article—I just added a failing rm call—but it’s inspired by real bugs I experienced).
Maintainer scripts are supposed to be idempotent: we should be able to execute them several times in a row without bad consequences. It happens from time to time that the maintainer gets this wrong… on the first try it works, so he uploads his package and we discover the problem only later once someone ended up executing the same code twice for some reason.
Follow me on Identi.ca, Twitter, Facebook and Google+. Or subscribe to this blog by RSS or by email.
You’re probably manipulating Debian packages everyday, but do you know what those files are? This article will show you their bowels… Surely they are more than file archives otherwise we would just use TAR archives (you know those files ending with .tar.gz). Let’s have a look!