Debian packages: debugging postinst

June 2nd, 2010

When writing debian packages, sometimes things go wrong in the postinst stage. An error like “the postinstallation script returned an error code of 1″ will occur. This is not very informative.

If you want to debug postinst scripts, you can easily do this on the machine where you (half) installed the package. Normally you can execute /var/lib/dpkg/info/foo.postinst like this:

sh -x /var/lib/dpkg/info/foo.postinst configure

However, if you use debconf, the output will be like this:
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/foo.postinst

Which is not helpful either. However, you can add “set -x” in /var/lib/dpkg/info/foo.postinst and then just execute it, it will give you the full output.


sh /var/lib/dpkg/info/foo.postinst configure

Now the debugging process can begin!

Debian packaging: multiple packages

November 25th, 2009

For different projects, I’ve made debian packages before, but I’ve never had a project where multiple packages were created from one control file. Today, I had to work on a project where I had to do this. Everything went as normal, except that I could not find out where to install the files so dh_builddeb could include them in their respective packages.

When only one package is made, this is easy: just install the files in debian/tmp as you would when installing on the system. For multiple packages, each package has its own directory: debian/<package-name>. How does dh_builddeb figure out which directory to use?

Apparently, the default behaviour is to let the first package use the debian/tmp dir, and the other packages use the debian/<package-name> directory.

I would rather have them all using the debian/<package-name> directory, but I could not find an option to do this.

Update:
It seems that setting the compatibility level to 7 fixes this behaviour (echo “7″ > debian/compat), see man debhelper (section “Compatibility levels” for more info.

Munin plugin bind9

November 1st, 2009

Today, I was trying to get the ‘bind9′ plugin to work, but it didn’t work out-of-the-box. So I debugged and I found out that the standard bind9 plugin does not consider ‘views’. My bind9 setup has an ‘internal’ as well as an ‘external’ view. In the bind9 query log, this adds a ‘view internal: ‘ for each line, so the plugin didn’t see it as a valid query line:

client 192.168.1.1#37242: view internal: query: www.apple.com IN A +

I changed the regexp and I archive it here in case anyone else (or future-me) wants to use this:

--- bind9.orig	2009-11-01 15:06:16.000000000 +0100
+++ bind9.new	2009-11-01 15:06:07.000000000 +0100
@@ -73,9 +73,9 @@
     open(Q,"< $QUERYLOG") or die "$!";
     while () {
 	chomp;
-	if (/client \d+\.\d+.\d+.\d+\#\d+: query\: \S+ (\w+) (\w+)/) {
-	    if ($1 eq 'IN' and $2 !~ /^TYPE/) {
-		$IN{$2}++;
+	if (/client \d+\.\d+.\d+.\d+\#\d+: (view \w+: )?query\: \S+ (\w+) (\w+)/) {
+	    if ($2 eq 'IN' and $3 !~ /^TYPE/) {
+		$IN{$3}++;
 	    } else {
 		$OTHER++;
 	    }

By the way, I also found out that there is a program called ‘munin-run’ which can be used to run the plugin as munin would, this saves a lot of hassle with sudo and environment settings!

kjoradsatn. omtitra eod

October 8th, 2009

Today, I found this in the mail. I’m not sure if I should keep this kernel (it’s a stock Debian kernel: linux-image-2.6.26-2-vserver-amd64, 2.6.26-15). Google does not give any results, seems like a corruption of log messages.

Oct  8 03:32:08 hoshi kernel: [145430.434977]kjoradsatn. omtitra  eod

edit: Oct 9
Today, I got this one, this is getting scary:

Oct  9 03:32:08 hoshi kernel: >99873]koradsatn. omtitra  eod

The only link I could find was this one: http://forums.gentoo.org/viewtopic-t-245137-start-0.html But it does not help me a lot.

When comparing the output of dmesg to the one in /var/log/kern.log (which is the source of the garbled messages), the only thing that is missing in the kern.log is this:

[236989.877537] kjournald starting.  Commit interval 5 seconds

It looks like this is the source from the garbled message: If you start from ‘k’ and take only every other character, you’ll see. So apparently, this is not a kernel problem (because the message appears ungarbled in dmesg) but rather a problem with syslogd.

Now things get really strange, as I have an rsyslogd daemon running, but I could not find the binary on the disk. It seems that I accidentally started a syslog daemon in a chroot (I did play around with that certain chroot, because I was fixing a computer that was booting via nfs-root from this machine).

The funny thing is that the rsyslogd that was running, was actually a 32-bit executable (the nfsroot is a 32-bits install), while the host is a 64-bit system. So I’ve been running a 32-bit syslogd on a 64-bit for two days :)

I’ll see if I get another garbled message tomorrow, but I think the problem is solved now :)

apc usb-cable pinout

August 11th, 2009

Just before I cut the cable for something else, I wanted to check if the pinout was the same as described in http://pinouts.ru/DevicesCables/apc_usb_cable_pinout.shtml. It was!