Discussion:
Bug#757330: [Pkg-libvirt-maintainers] Bug#757330: libvirt-daemon-system: fails to install: update-rc.d: error: insserv rejected the script header
Guido Günther
2014-08-07 10:04:23 UTC
Permalink
Package: libvirt-daemon-system
Version: 1.2.7-3
Severity: serious
Justification: does not install
Setting up libvirt-daemon-system (1.2.7-3) ...
insserv: script libvirtd: service libvirt-bin already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
subprocess installed post-installation script returned error exit status 1
Package libvirt-daemon-system is not configured yet.
dependency problems - leaving unconfigured
libvirt-daemon-system
libvirt-bin
E: Sub-process /usr/bin/dpkg returned an error code (
Any chance to rerung this with DPKG_DEBUG=1 ? I did an update of a
sysv based system yesterday without any troubles. Did you modify
/etc/init.d/libvirt-bin ?
Cheers,
-- Guido
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
ii adduser 3.113+nmu3
ii gettext-base 0.19.2-1
ii init-system-helpers 1.20
ii libapparmor1 2.8.0-5.1
ii libaudit1 1:2.3.7-1
ii libavahi-client3 0.6.31-4
ii libavahi-common3 0.6.31-4
ii libblkid1 2.20.1-5.8
ii libc6 2.19-7
ii libcap-ng0 0.7.3-1.1
ii libdbus-1-3 1.8.6-1
ii libdevmapper1.02.1 2:1.02.85-2
ii libgnutls-deb0-28 3.2.16-1
ii libnl-3-200 3.2.24-2
ii libnl-route-3-200 3.2.24-2
ii libnuma1 2.0.9-1
ii librados2 0.80.5-1
ii librbd1 0.80.5-1
ii libsasl2-2 2.1.26.dfsg1-11
ii libselinux1 2.3-1
ii libssh2-1 1.4.3-3
ii libsystemd-daemon0 208-7
ii libvirt-clients 1.2.7-3
ii libvirt-daemon 1.2.7-3
ii libvirt0 1.2.7-3
ii libxml2 2.9.1+dfsg1-4
ii libyajl2 2.1.0-1
ii logrotate 3.8.7-1
ii bridge-utils 1.5-9
ii dmidecode 2.12-3
pn dnsmasq-base <none>
pn ebtables <none>
ii iproute2 3.16.0-1
ii iptables 1.4.21-2
ii parted 3.2-2
ii pm-utils 1.4.1-15
pn apparmor <none>
pn auditd <none>
pn policykit-1 <none>
pn radvd <none>
pn systemd <none>
pn systemtap <none>
/etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf'
-- no debconf information
_______________________________________________
Pkg-libvirt-maintainers mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
Thorsten Glaser
2014-08-07 10:28:54 UTC
Permalink
Any chance to rerung this with DPKG_DEBUG=3D1 ? I did an update of a
***@tglase:~ $ sudo env DPKG_DEBUG=3D1 dpkg -a --configure
[sudo] password for tglase:=20
Setting up libvirt-daemon-system (1.2.7-3) ...
insserv: script libvirtd: service libvirt-bin already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package libvirt-daemon-system (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of libvirt-bin:
libvirt-bin depends on libvirt-daemon-system (>=3D 1.2.7-3); however:
Package libvirt-daemon-system is not configured yet.

dpkg: error processing package libvirt-bin (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
libvirt-daemon-system
libvirt-bin
sysv based system yesterday without any troubles. Did you modify
/etc/init.d/libvirt-bin ?
Yes, I did. I added =E2=80=9Clinux64=E2=80=9D before =E2=80=9Cstart-stop-da=
emon --start [=E2=80=A6]=E2=80=9D
since I=E2=80=99m running an amd64 kernel with i386 userland and:

***@tglase:~ $ cat /sbin/init =
=20
#!/bin/mksh-static
exec /usr/bin/linux32 /sbin/init.real "$@"

bye,
//mira=E2=80=9Cwaiting for the Debian kernel to support x32=E2=80=9Dbilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg
Guido Günther
2014-08-07 12:32:32 UTC
Permalink
Post by Guido Günther
Any chance to rerung this with DPKG_DEBUG=1 ? I did an update of a
Setting up libvirt-daemon-system (1.2.7-3) ...
insserv: script libvirtd: service libvirt-bin already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
subprocess installed post-installation script returned error exit status 1
Package libvirt-daemon-system is not configured yet.
I meant the whole update process from the previous version
(downgrading to the old version, then updating again).

I suspect dpkg-maintscript-helper to not identify
/etc/init.d/libvirt-bin to be related part of libvirt-bin:amd64 and
therefore not being moved out of the way. I saw a similar error when
changing the libvirt-bin transitional package to arch all.
dependency problems - leaving unconfigured
libvirt-daemon-system
libvirt-bin
Post by Guido Günther
sysv based system yesterday without any troubles. Did you modify
/etc/init.d/libvirt-bin ?
Yes, I did. I added “linux64” before “start-stop-daemon --start […]”
#!/bin/mksh-static
So this is multiarch using mostly i386 but some x86_64? Could you
attach "dpkg -l" as well?
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thorsten Glaser
2014-08-07 12:50:57 UTC
Permalink
Post by Guido Günther
I suspect dpkg-maintscript-helper to not identify
/etc/init.d/libvirt-bin to be related part of libvirt-bin:amd64 and
:i386

Yes, probably.
Post by Guido Günther
So this is multiarch using mostly i386 but some x86_64? Could you
No, this is i386 single-arch. There is an amd64 kernel package
for this. I’ve got an amd64 schroot, which I use to run qemu
when VMs need more than 2047 MiB RAM.

***@tglase:~ $ cat /usr/local/bin/qemu-in-chroot
#!/bin/sh
exec schroot -c sid-amd64 -u root -- qemu-system-x86_64 "$@"

Then, <emulator>/usr/local/bin/qemu-in-chroot</emulator>
in the domain XML, and it works.
Post by Guido Günther
I meant the whole update process from the previous version
(downgrading to the old version, then updating again).
Thanks
 downgrading killed the VMs I had running, errored
out, and did all other sorts of trouble. Don’t suggest that
to “newbie” users ;-)

Anyway, did it. typescript attached.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
GeschÀftsfÌhrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Guido Günther
2014-08-07 17:06:31 UTC
Permalink
Hi,
Thanks for reporting back.
DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper mv_conffile in preinst of libvirt-bin
DEBUG: dpkg-maintscript-helper: CONFFILE=/etc/default/libvirt-bin -> /etc/default/libvirtd PACKAGE=libvirt-bin:i386 LASTVERSION=1.2.6-1~ ACTION=upgrade PARAM=1.2.4-3.2
DEBUG: dpkg-maintscript-helper: Executing /usr/bin/dpkg-maintscript-helper mv_conffile in preinst of libvirt-bin
DEBUG: dpkg-maintscript-helper: CONFFILE=/etc/init.d/libvirt-bin -> /etc/init.d/libvirtd PACKAGE=libvirt-bin:i386 LASTVERSION=1.2.6-1~ ACTION=upgrade PARAM=1.2.4-3.2
Renaming a conffile
[..snip..]
Current implementation: the preinst checks if the conffile has been modified, if yes it's left on place otherwise it's renamed to old-
conffile.dpkg-remove. On configuration, the postinst removes old-conffile.dpkg-remove and renames old-conffile to new-conffile if old-
conffile is still available. On abort-upgrade/abort-install, the postrm renames old-conffile.dpkg-remove back to old-conffile if
required.

So since you modified /etc/init.d/libvirt-bin it's left in place and
when insserv runs in the postinst there is /etc/init.d/libvirt-bin and
/etc/init.d/libvirtd both providing libvirt-bin which breaks insserv.

The situation would be improved if we'd moved the conf file rename
_prior_ to the insserv (added by dh_installinit). Is this possible
with debhelper without open coding it?

But this still isn't enough. If you didn't modify
/etc/default/libvirt-bin then this file would be renamed to
/etc/default/libvirtd and the nonexistent /e/d/libvirt-bin would
result in start_libvirtd != yes and the daemon wouldn't be started
again.

So we additinally need to add a symlink from /etc/default/libvirt-bin
to /etc/default/libvirtd (since this is what your then renamed script
would source).

The simplest solution would be to just remove libvirt-bin from the
Provides in the init script headers. Nothing else in Debian seems to
require it. Only nova-compute has it in the Should-Start and that
could easily be fixed (and a Breaks: added to libvirt-daemon-system).

I'm cc'eing Raphael since he might have encountered this before.
Cheers
-- Guido
Thorsten Glaser
2014-08-08 06:56:05 UTC
Permalink
Post by Guido Günther
_prior_ to the insserv (added by dh_installinit). Is this possible
with debhelper without open coding it?
But this still isn't enough. If you didn't modify
/etc/default/libvirt-bin then this file would be renamed to
Yes, I didn=E2=80=99t.
Post by Guido Günther
So we additinally need to add a symlink from /etc/default/libvirt-bin
to /etc/default/libvirtd (since this is what your then renamed script
would source).
Sounds like fun=E2=80=A6

What do I do now, manually remove the old initscript then retry?

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg
Guido Günther
2014-08-08 07:54:40 UTC
Permalink
Post by Guido Günther
_prior_ to the insserv (added by dh_installinit). Is this possible
with debhelper without open coding it?
But this still isn't enough. If you didn't modify
/etc/default/libvirt-bin then this file would be renamed to
Yes, I didn’t.
Post by Guido Günther
So we additinally need to add a symlink from /etc/default/libvirt-bin
to /etc/default/libvirtd (since this is what your then renamed script
would source).
Sounds like fun…
What do I do now, manually remove the old initscript then retry?
Yes, just remove /etc/init.d/libvirt-bin as a work around.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...