Can't upgrade from 14.10

[doctordruidphd]

As of 24 March:
Stops after upgrading grub. Seems to be a problem with initscripts. Tried deleting /etc/rc.local just for the fun of it, no difference. "apt-get install -f" and "dpkg --configure -a" can't get around this.

Setting up initscripts (2.88dsf-53.2ubuntu11) ...
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: warning: current stop runlevel(s) (5) of script `killprocs' overrides LSB defaults (empty).
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package initscripts (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of systemd:
 systemd depends on initscripts (>= 2.88dsf-53.2); however:
  Package initscripts is not configured yet.

dpkg: error processing package systemd (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of systemd-sysv:
 systemd-sysv depends on systemd (= 219-4ubuntu9); however:
  Package systemd is not configured yet.
 systemd-sysv depends on systemd; however:
  Package systemd is not configured yet.

dpkg: error processing package systemd-sysv (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 219-4ubuntu9); however:
  Package systemd is not configured yet.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of upstart:
 upstart depends on initscriptsNo apport report written because the error message indicates its a followup error from a previous failure.
                                   No apport report written because the error message indicates its a followup error from a previous failure.
                                       No apport report written because MaxReports is reached already
                                                                                                     No apport report written because MaxReports is reached already
                                                             No apport report written because MaxReports is reached already
                     No apport report written because MaxReports is reached already
                                                                                   ; however:
  Package initscripts is not configured yet.

dpkg: error processing package upstart (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of friendly-recovery:
 friendly-recovery depends on upstart | systemd-sysv; however:
  Package upstart is not configured yet.
  Package systemd-sysv is not configured yet.

dpkg: error processing package friendly-recovery (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of upstart-bin:
 upstart-bin depends on upstart; however:
  Package upstart is not configured yet.

dpkg: error processing package upstart-bin (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 initscripts
 systemd
 systemd-sysv
 libpam-systemd:amd64
 upstart
 friendly-recovery
 upstart-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

[doctordruidphd]

Still not working (as of 4/4)
Problem is still with initscripts, and can't get beyond it.

oot@Crynfyd:/etc# dpkg --configure initscripts
Setting up initscripts (2.88dsf-53.2ubuntu11) ...
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: warning: current stop runlevel(s) (5) of script `killprocs' overrides LSB defaults (empty).
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: script rc.local: service rc.local already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package initscripts (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initscripts

Has anyone been able to upgrade?

[SteveRiley]

I wonder what would happen if you switch your 14.10 from Upstart to systemd first, and then tried the upgrade. I admit it's a guess, but who knows?

[doctordruidphd]

I didn't know that option was available for 14.10, might be worth a try. It doesn't seem to be a boot option on the menu, but I guess I can try it manually. Will try and report back.

[doctordruidphd]

Tried booting with systemd by adding "init=/bin/systemd" to the linux line.
It seems to start, but hangs and never escapes from:

A start job is running for Wait for Plymouth Boot Screen to Quit

and just hangs there forever (until I hit CTRL-ALT-DEL). Any way to get beyond this?

Edit: PS I don't want a boot screen' I want to see the console text during boot. I do have
the nosplash option set in the linux line in grub.cfg.

[ronw]

Do you have systemd-sysv installed?

I think that is what I installed on Vivid Alpha 1 to switch to systemd early. It's now the default in Vivid.

No idea if 14.10 will handle the switch though, so all the Usual Disclaimers.

With all the changes in Vivid, I used it as an excuse to do a fresh install.

[doctordruidphd]

Apparently systemd-sysv is not installed, but the only way to get it in there will be for the upgrade to go through.
The last "fresh install" wasted about 2 weeks of time to get everything set up, so not really an option.

I did get around the plymouth problem by hacking /lib/systemd/system/plymouth-quit-wait.service, and also specifying plymouth.enable=0 on the kernel boot line (which hint I found somewhere...). I also had to switch from kdm to lightdm, so now I can boot with systemd.

Next project is to try the upgrade, and if that doesn't go through, I guess hold the initscripts package and see what happens.

[doctordruidphd]

Tried the upgrade from the system booted with systemd; same problem. Initscripts fails to configure, which essentially kills the whole upgrade process. There has to be a way around this...

[kubicle]

Didn't we already do this once

https://www.kubuntuforums.net/showth...lated-packages

(Might not be the exactly same issue, but very similar symptoms...seems your installation shows a strong aversion to being upgraded )

So the first thing to check is the output of:

grep rc.local /etc/init.d/*

To see if there are multiple initscripts that have rc.local in their "Provides" header. (The last time the issue was /etc/init.d/rc.shutdown that had a bad "Provides" header)

[doctordruidphd]

Didn't we already do this once

Yeah, I thought so, but searching didn't turn up the thread. I guess I also have a strong aversion to remembering these horrors. This time I will bookmark it.

Will try ASAP, but I suspect it's the same problem, same solution. Will report back the results.

Thanks.

[doctordruidphd]

Some progress.
Removing /etc/init.d/rc.local let the upgrade go through.
Now boots with systemd, gets to the lightdm greeter, logs in, then no KDE.

I am guessing it's an nvidia driver problem.

As I recall there was a fairly quick way to switch to nouveau; once I get a screen, then try to debug the nvidia problem. Might be my card is too old for the new driver.

[doctordruidphd]

Found the problem -- I needed to choose "Plasma" from the lightdm menu (I have never used lightdm until now).
Now kde comes up, though I guess it will not use any of the existing themes, colors, etc.
Oh well. Anyway, upgrade problem solved.

[kubicle]

Some progress.
Removing /etc/init.d/rc.local let the upgrade go through.

I'm guessing that is what you did the last time (and probably the reason why the issue resurfaced).

It's sort of a backward fix, as /etc/init.d/rc.local actually should "provide" rc.local. The proper fix is to change/remove the initscript that falsely claims to "provide" rc.local.

At least the last time, you had another script (rc.shutdown) that falsely claimed to provide rc.local (which caused the insserv to spew the error of multiple rc.local services). The correct fix would have been to either delete rc.shutdown (if not needed, it does not come from any package in the repos) or fix it's "provides" header (rc.local -> rc.shutdown).

If you remove rc.local, an upgrade will likely install the file back and then the issue will resurface (again).

To summarize, the issue (if it is indeed the same issue) is not /etc/init.d/rc.local...it's that some other initscript falsely claims to provide the same functionality, and you should be able to find out which one by running 'grep rc.local /etc/init.d/*'.

[doctordruidphd]

Yeah, it's the rc.shutdown, and I have no idea where it came from. I deleted it for the last upgrade, and somehow it reappeared. Why it would run rc.local on shutdown is beyond me anyway, and that seems to be all it does, other than to also generate some logout message. I can live without that.

It seems that /etc/init.d/rc.local was not regenerated, and the only thing that has rc.local as a "Provides" is that rc.shutdown thing.

[kubicle]

Yeah, it's the rc.shutdown, and I have no idea where it came from. I deleted it for the last upgrade, and somehow it reappeared. Why it would run rc.local on shutdown is beyond me anyway, and that seems to be all it does, other than to also generate some logout message. I can live without that.

It is possible some 3rd party software (something not in the repos) installs the rc.shutdown (which could explain why it reappeared). Nevertheless, there is no reason why it should have rc.local in it's provides header (which conflicts with rc.local).

I recommend editing rc.shutdown's provides line so that it will not conflict with rc.local, by changing:

# Provides: rc.local

to

# Provides: rc.shutdown

This should keep insserv happy even if you have both rc.local and rc.shutdown installed.

Just out of curiosity, can you post the contents of rc.shutdown (that might give some clues where it came from)? you can also run:

dpkg -S /etc/init.d/rc.shutdown

, but that will only work if the software that installed the file was installed via package management.

It seems that /etc/init.d/rc.local was not regenerated

It probably will be, when the "initscripts" package is upgraded/reinstalled the next time. Since it's listed in initscripts as a conffile, it might not be regenerated on every upgrade, though.