[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

multistrap: insserv vs. Essential: yes



I got the following from "chroot target dpkg --configure -a" when building an i386 image on an amd64 host (both squeeze): [...] Setting up ifupdown (0.6.10) ... Creating /etc/network/interfaces. insserv: Service checkroot has to be enabled to start service ifupdown-clean insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing ifupdown (--configure): subprocess installed post-installation script returned error exit status 1 [...] Setting up keyboard-configuration (1.55) ... insserv: Service mountkernfs has to be enabled to start service keyboard-setup insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing keyboard-configuration (--configure): subprocess installed post-installation script returned error exit status 1 I spoke to pere ("the insserv guy") about it. He saw the same symptoms when debootstrap installed util-linux and initscripts (both essential). That was fixed by adding a dependency between the two. However... pere> [...] multistrap seems to install essential and non-essential pere> packages in one go, increasing the demand for correct pere> dependencies. The fix for your problem is either to add pere> initscripts as package dependencies for ifupdown and pere> keyboard-configuration, or to change the relevant required-* pere> entries for ifupdown and keyboard-configuration to should-* to pere> make the init.d script dependencies optional. Or change pere> multistrap top configure essential packages first. :)

twb> I guess multistrap should do essential as a separate batch, because twb> current debian policy says that you don't need to declare twb> dependencies on Essential: yes packages

pere> Yes, that is the reason ifupdown and k-c do not declare the pere> dependency.

Now, since I'm building cross-architecture, I *think* the fault was mine: I was the one running dpkg --configure -a. But AFAICT multistrap behaves the same way internally for native builds (&native, line 649).

I'm not *how* exactly it should configure Essential: yes packages first; I suppose it could calculate the list of installed, essential packages, and call "dpkg --configure @list" before calling "dpkg --configure -a".

Currently I'm working around this (and other issues) by simply running
"dpkg --configure -a" over and over until it stops failing:

   chroot target dpkg --configure -a ||
   chroot target dpkg --configure -a ||
   chroot target dpkg --configure -a ||
   chroot target dpkg --configure -a ||
   chroot target dpkg --configure -a

PS: I wish multistrap would exit with non-zero exit status when its
child $setupsh process does!


Reply to: