initscripts package fails to upgrade if there are local init scripts on the system with no LSB headers

[Hervé Pourchasse]

The dependency-based boot sequencing originally introduced upstream with Debian 6.0 is now always enabled in Ubuntu 14.10.

For optimal sequencing, all init.d scripts should declare their dependencies in an LSB header. This is already the case for scripts shipped in Ubuntu, but users should check their local scripts and consider adding that information.

For more information on this feature refer to the information available in /usr/share/doc/insserv/README.Debian.

ProblemType: Package
DistroRelease: Ubuntu 14.10
Package: initscripts-2.88dsf 41ubuntu18
ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
Uname: Linux x86_64 3.13.0-37-generic
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
Date: Sun October 26 2014 7:52:55
DuplicateSignature: Package: initscripts: 2.88dsf-41ubuntu18: the post-installation script subprocess installed returned error exit status 1
ErrorMessage: The post-install script subprocess installed returned error exit status 1
InstallationDate: Installed on 2014-08-06 (80 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: sysvinit
Title: initscripts package 2.88dsf-41ubuntu18 failed to install / upgrade: subprocess installed post-installation script returned error exit status 1
UpgradeStatus: Upgraded to utopic on 2014-10-26 (0 days ago)

[Steve Langasek (vorlon)]

Your upgrade log shows:

Paramétrage de initscripts (2.88dsf-41ubuntu18) ...
Installation de la nouvelle version du fichier de configuration /etc/init.d/ondemand ...
insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides
insserv: warning: script 'cron' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `cron'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `cron'
insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides
[...]
insserv: Starting vpnagentd_init depends on grub-common and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package initscripts (--configure):
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1

With this release of Ubuntu, we require init scripts to declare LSB dependencies in a pseudoheader, so that insserv is able to calculate a dependency tree for them. This is an unfortunate side-effect of the longer-term transition between upstart and systemd.

To fix your particular problem, it should suffice for you to add the following lines to the top of your local /etc/init.d/vpnagentd_init script (below the first line):

### BEGIN INIT INFO
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
### END INIT INFO

It's not clear to me that we can do anything further to mitigate this problem on upgrade, but we should certainly make sure that it gets documented in the release notes.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christopher (soft-kristal)]

For what it's worth, I have two other partitions: another Ubuntu Gnome 14.10 (test bed) and Ubuntu 14.10, both unaffected by this bug. It's my stable Ubuntu Gnome that's affected.

[Dimitri John Ledkov (xnox)]

All systems are affected, and the scope of this bug report is minimal. If there are no LSB headers, defaults are used, unless there are other _other_ scripts which do have lsb headers and reference that one (e.g. override scripts of the stock init script). In those cases an upgrade may fail and there is nothing that distribution maintainers can do, as the /default/ scripts are consistent across the distribution.

[ruedihofer (ruedihofer)]

I have a similar problem when updating my System. It says in aptitude for ppp the following, but it might be caused by any of the other packets at the end. Someone with an idea?

I'm running these foreign repos:
deb http://dl.google.com/linux/earth/deb/ stable main
deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu/ utopic main
deb http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu/ utopic main
deb http://ppa.launchpad.net/videolan/stable-daily/ubuntu/ utopic main

The Log with aptitude:

Setting up udev (208-8ubuntu8.1) ...
udev stop/waiting
udev start/running, process 4972
update-initramfs: deferring update (trigger activated)
insserv: warning: script 'x11vnc' missing LSB tags and overrides
insserv: Script vncserver is broken: incomplete LSB comment.
insserv: missing `Provides:' entry: please add.
insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:' entry: please add even if empty.
insserv: missing `Default-Start:' entry: please add even if empty.
insserv: missing `Default-Stop:' entry: please add even if empty.
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `vncserver'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `vncserver'
insserv: There is a loop between service minidlna and x11vnc if stopped
insserv: loop involving service x11vnc at depth 2
insserv: loop involving service minidlna at depth 1
insserv: Stopping x11vnc depends on minidlna and therefore on system facility `$all' which can not be true!
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package udev (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of systemd:
 systemd depends on udev; however:
  Package udev is not configured yet.

dpkg: error processing package systemd (--configure):No apport report written because the error message indicates its a followup error from a previous failure.

 dependency problems - leaving unconfigured
...
Errors were encountered while processing:
 ppp
 ntp
 openvpn
 cgmanager
 udev
 xserver-xorg-core
 systemd
 libpam-systemd:amd64
Press Return to continue.

[Christopher (soft-kristal)]

My list of unconfigured applications is growing. Tracker is new as of today.

 libpam-systemd:amd64
 ppp
 clamav-freshclam
 ntp
 spamassassin
 libunique-1.0-0
 dbus-x11
 cgmanager
 pppoeconf
 tracker
 udev
 shotwell
 xserver-xorg-core
 gnome-media-player
 clamav
 tracker-extract
 sa-compile
 clamtk
 systemd
 tracker-utils
 tracker-gui
 tracker-miner-fs

[Martin Pitt (pitti)]

Well, the list of "affected" packages is pretty arbitrary and random -- on affected systems you have to fix the broken third-party init.d script, or it's never going to work :/

[Christopher (soft-kristal)]

I have the same OS running without a hitch on an other partition with the same third party applications. Would it be safe make one 'old' and replace it with the working one?

[Christopher (soft-kristal)]

--more. I could replace the list of items in init.d one by one and see which one fixes the problem. My scripting is limited to web languages.

[Christopher (soft-kristal)]

Apparently all files included in Ubuntu have the appropriate LSB headers and from a cursor look at my affected files in #7, all have the header.

[Christopher (soft-kristal)]

This bug also prevents me from transferring files to a USB device or creating a bootable USB.

[Christopher (soft-kristal)]

I've searched my other partition for K20.depend.stop but it doesn't seem to be there, and the one on my affected partition is indeed missing an LSB header.

[ruedihofer (ruedihofer)]

Dear all, my list of packages is also growing. Is there a manual workaround for this? (I have disabled all foreign repos without effect..)

[Dimitri John Ledkov (xnox)]

If /usr/share/doc/insserv/README.Debian is not enough to resolve.

Please open a new bug report, with full output from apt-get dist-upgrade / dpkg --configure -a
WIth all files referenced.
There should be an upgrade log from insserv which will point out the bits it is complaining about.

[Christopher (soft-kristal)]

insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
insserv:...

[Dimitri John Ledkov (xnox)]

On 29 January 2015 at 16:10, Christopher <email address hidden> wrote:
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!

Do you have anything in /etc/rc.local ? apart from "exit 0"? What are
the headers of /etc/init.d/rc.local?

Are they:
### BEGIN INIT INFO
# Provides: rc.local
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO

?

Can you try force removing rc.local from startup, if you are not using it. E.g.:
$ sudo update-rc.d -f rc.local remove

However the stock initscript as shipped in the distribution works
correctly, as it's part of everyones upgrade.

> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insserv: Starting .depend.boot depends on rc.local and therefore on system facility `$all' which can not be true!
> insse...

[Christopher (soft-kristal)]

The headers match and i moved rc.local to the desktop for now. After a restart, nothing has changed.

Will the affected files be overwritten in 15.04? I can wait until then.

[Christopher (soft-kristal)]

I installed Aptik from the ppa's and have done a complete mirror of my applications and settings. At this point I'm seriously considering a clean re-installation. Do you think it to be the best solution under the circumstances? I can't run VirtualBox any more along with the applications listed in comment #7.

[Christopher (soft-kristal)]

For anyone else who is a bit crazed about this bug, I can recommend Aptik to backup and restore your applications, settings and documents. It's safe to do a fresh installation and it's dead easy to use, but you need some kind of external backup hardware.
 It's a long process to restore everything but well worth in the end.

No more unconfigured applications and everything seems to be as it was before this bug bit.

[ruedihofer (ruedihofer)]

Dear Dimitri
Please find the requested output in the attachment. I have not made another bug report before you have analyzed quickly my output.

Dear Brian
This bug is still very much critical!

Thanks to all
Ruedi

[Gianfranco Costamagna (costamagnagianfranco)]

Is something needed on the virtualbox side?

[Michael (rgnglzrd)]

I've upgraded this machine since 10.10. The rc.local provided with previous version did NOT have LSB headers in them. The file was never upgraded during previous system upgrades. Simply adding:

### BEGIN INIT INFO
# Provides: local
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start local scripts at boot time
# Description: Enable services provided by local daemons.
### END INIT INFO

seems to resolve the problem.

As a long term solution, having the upgrade package look for files missing the LSB header and fail upon finding them BEFORE the upgrade begins would be most helpful. The other choice would be to simply insert a generic LSB header into the offending file and proceed as usual.

[dogmatic69 (dogmatic69)]

I have had this similar issue and adding that LSB header to a couple places allowed the packages to be installed and get things working again.

[Phillip Susi (psusi)]

If this isn't a bug in Ubuntu and there isn't anything we can do about it, then why has it not been closed as invalid or wontfix?

[Bernhard Nikola (bnikola)]

thx for answer.

There are more than one way to install an operation system.
In my opinion it was a -not fixed fault- during installation with a
non-efi bios.

Bernhard

............................

Am 17.02.2017 um 15:50 schrieb Phillip Susi:
> If this isn't a bug in Ubuntu and there isn't anything we can do about
> it, then why has it not been closed as invalid or wontfix?
>

[bouman4 (dj-d424)]

<email address hidden>
________________________________
Van: <email address hidden> <email address hidden> namens Bernhard Nikola <email address hidden>
Verzonden: vrijdag 17 februari 2017 22:05
Aan: <email address hidden> <email address hidden>
Onderwerp: Re: [Bug 1385817] Re: initscripts package fails to upgrade if there are local init scripts on the system with no LSB headers

thx for answer.

There are more than one way to install an operation system.
In my opinion it was a -not fixed fault- during installation with a
non-efi bios.

Bernhard

............................

Am 17.02.2017 um 15:50 schrieb Phillip Susi:
> If this isn't a bug in Ubuntu and there isn't anything we can do about
> it, then why has it not been closed as invalid or wontfix?
>

--
You received this bug notification because you are subscribed to a
duplicate bug report (1406946).
https://bugs.launchpad.net/bugs/1385817

Title:
  initscripts package fails to upgrade if there are local init scripts
  on the system with no LSB headers

Status in sysvinit package in Ubuntu:
  Triaged

Bug description:
  The dependency-based boot sequencing originally introduced upstream
  with Debian 6.0 is now always enabled in Ubuntu 14.10.

  For optimal sequencing, all init.d scripts should declare their
  dependencies in an LSB header. This is already the case for scripts
  shipped in Ubuntu, but users should check their local scripts and
  consider adding that information.

  For more information on this feature refer to the information
  available in /usr/share/doc/insserv/README.Debian.

  ProblemType: Package
  DistroRelease: Ubuntu 14.10
  Package: initscripts-2.88dsf 41ubuntu18
  ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
  Uname: Linux x86_64 3.13.0-37-generic
  ApportVersion: 2.14.1-0ubuntu3.5
  Architecture: amd64
  Date: Sun October 26 2014 7:52:55
  DuplicateSignature: Package: initscripts: 2.88dsf-41ubuntu18: the post-installation script subprocess installed returned error exit status 1
  ErrorMessage: The post-install script subprocess installed returned error exit status 1
  InstallationDate: Installed on 2014-08-06 (80 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  SourcePackage: sysvinit
  Title: initscripts package 2.88dsf-41ubuntu18 failed to install / upgrade: subprocess installed post-installation script returned error exit status 1
  UpgradeStatus: Upgraded to utopic on 2014-10-26 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1385817/+subscriptions