incomplete migration to /run (shutdown script order has been demolished)

[Tom Chiverton]

[Impact]
severity : a total lack of system (wireless) networking coming up - this gives a >! minute pause during boot, as well as a subsequent total failure to be able to log into X (KDE or GNOME sessions give a cryptic error related to DBUS).
frequency : once triggered, remains till manually fixed
justification for backporting the fix to the stable release : I dunno your criteria, sorry, but it looks fairly bad to me.

[Development Fix]
over my head. see comments.

[Stable Fix]
migration script needs to double check (one time?) if all went well, if not, it needs to force the change through regardless, because the alternative is worse than any damage it could do.

[Text Case]
It's something like
1. install 9.10
2. upgrade to each release
3. install vmware at some point
4. attempt most recent upgrade
Broken Behavior: incomplete migration to /run
Fixed Behavior: complete migration to /run

[Regression Potential]
likelihood : cant see any that would be worse than not networking and no GUI.
TBH this should have been fixed already.

[Original Report]
I had the exact same issue documented as https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/807306 on upgrade from 11.04 to 11.10. Opening new bug as req.

Removing the existing /var/run and /var/run/lock and replacing with sym links as per comment 76 there fixed it.

The impact of this was a total lack of system (wireless) networking coming up - this gives a >! minute pause during boot, as well as a subsequent total failure to be able to log into X (KDE or GNOME sessions give a cryptic error related to DBUS).

I've just run an apt-get update/upgrade after *finally* getting back into my new 11.10 beta 2 system, and no updates to the mountall show up... therefore I assume this bug is still present.

To correct the broken symlinks, run the following commands as root:
 mv /etc/rc6.d/S*reboot /etc/rc6.d/S90reboot
 mv /etc/rc6.d/S*umountroot /etc/rc6.d/S60umountroot
 mv /etc/rc6.d/S*umountnfs.sh /etc/rc6.d/S31umountnfs.sh
 mv /etc/rc6.d/S*umountfs /etc/rc6.d/S40umountfs
 mv /etc/rc6.d/S*sendsigs /etc/rc6.d/S20sendsigs

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: initscripts 2.88dsf-13.10ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic i686
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Sat Sep 24 10:49:58 2011
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: sysvinit
UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago)

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

I do not have /var/run in your /etc/fstab

I rebooted after the upgrade-manager finished, and it was then nothing worked.

If you are relying on a one-time script at shutdown to do the migration, maybe you need to verify it worked OK and re-run it ASAP in the boot process too.

[Steve Langasek (vorlon)]

> If you are relying on a one-time script at shutdown to do the migration,
> maybe you need to verify it worked OK and re-run it ASAP in the boot process too.

Unfortunately, the shutdown script itself explains why this is not possible:

        # These must be turned into symlinks for the /run transition. We
        # can't do this at boot time because / is remounted read-write too
        # late, so do it on shutdown instead.

There is no point in the boot sequence when / is writable that we are guaranteed to be able to replace /var/run with a symlink safely, because /run is mounted *before* / is writable and this causes other processes to start up that may be creating sockets in /var/run.

So we really, really need to figure out why this script isn't working for you at shutdown. Unfortunately this is difficult to do since there are certainly no logs from this point in the shutdown sequence, and the problem has not been widely reproducible.

Could you attach a copy of your full /etc/fstab from this system? Maybe something will jump out...

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

If you've tried to do it safely at shutdown, and it didn't work, I think it's OK to try less safely early in the boot process, then reboot once it's done. Certainly I did this by hand, and no ill effects occurred.

fstab:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda3
UUID=01aa6a10-1c91-4b24-9632-a45de910f911 / ext3 defaults,errors=remount-ro,relatime 0 1
# /dev/sda5
/dev/sda5 none swap sw 0 0
/dev/sda6 /home ext3 defaults,errors=remount-ro,relatime 1 2
/dev/sda2 /media/dell-rescue-partition udf,iso9660 user,noauto,exec 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec 0 0
#manage these via sudoers that lets falken run mount/umount, scripts in ~falken/bin
# KDE control panel Autostart being tried instead of:
#then sym links in ~/.kde/shutdown|Autostart
//bookcase.house/falken /home/falken/smb4k/bookcase-falken cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
//bookcase.house/scratch /home/falken/smb4k/bookcase-scratch cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
//bookcase.house/mp3 /media/bookcase-mp3 cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
//bookcase.house/video /home/falken/smb4k/bookcase-video cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
#vmware needed this
#usbfs /proc/bus/usb usbfs auto,devgid=46,devmode=664 0 0

[Steve Langasek (vorlon)]

On Sat, Sep 24, 2011 at 09:05:17PM -0000, Tom Chiverton wrote:

> fstab:
<snip>

> //bookcase.house/falken /home/falken/smb4k/bookcase-falken cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
> //bookcase.house/scratch /home/falken/smb4k/bookcase-scratch cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
> //bookcase.house/mp3 /media/bookcase-mp3 cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0
> //bookcase.house/video /home/falken/smb4k/bookcase-video cifs noexec,credentials=/home/falken/.cifsPassword,uid=falken,noauto 0 0

This makes me suspect an effect of bug #221631. Although the dbus package
in oneiric includes a fix for this bug, since the dbus service can't be
restarted, the old stop condition is in effect for the job at the time of
the post-upgrade reboot, with the result that dbus shuts down as soon as
'runlevel 6' triggers, and if you use Network Manager, your cifs filesystems
will not cleanly unmount.

However, the behavior seen here is a timeout of the mount after 300 seconds
and a forced unmount, so I don't know why these would have blocked a clean
unmount in your case.

Do you often see errors on this machine at reboot about filesystems not
being cleanly unmounted?

Apologies if I've already asked this question, but is /etc/init.d/umountroot
an unmodified conffile? (i.e., does 'debsums -s -e initscripts' return
warnings, and what does 'ls -l /etc/init.d/umountroot*' show?)

What is the output of ls -l /etc/rc6.d/ on this system?

> If you've tried to do it safely at shutdown, and it didn't work, I think
> it's OK to try less safely early in the boot process, then reboot once
> it's done. Certainly I did this by hand, and no ill effects occurred.

It may come to this, but that's easier said than done. The risks of doing
it here include hanging the system on boot (potentially very bad if it's
remotely managed), and filesystem corruption due to an unclean shutdown. We
do want to resolve this bug, but we shouldn't be hasty to change things that
might make it worse.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

I'd suspect https://bugs.launchpad.net/network-manager/+bug/211631 first myself.
Although those mounts are meant to be brought up/down by KDE, if Samba or NetworkManager was screwed by the upgrade at the time, this might have failed.
$ cat ~/.kde/Autostart/mountcifs.sh
#!/bin/bash
sleep 30
sudo mount /home/falken/smb4k/bookcase-falken
...

$ cat ~/.kde/shutdown/umountcifs.sh
#!/bin/bash
sudo umount -t cifs -a

No, I don't get unclean shutdown messages, and shutdown is normally very quick. It took ages after the upgrade, but is now quick again.

debsums produces no output.

falken@wopr:/tmp$ ls -l /etc/init.d/umountroot*
-rwxr-xr-x 1 root root 2926 2011-07-14 06:11 /etc/init.d/umountroot
falken@wopr:/tmp$

falken@wopr:/tmp$ ls -l /etc/rc6.d/
total 4
lrwxrwxrwx 1 root root 17 2010-09-26 10:08 K01apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 16 2009-11-23 21:38 K01dhcdbd -> ../init.d/dhcdbd
lrwxrwxrwx 1 root root 15 2010-09-26 10:08 K01exim4 -> ../init.d/exim4
lrwxrwxrwx 1 root root 13 2008-05-18 17:19 K01gdm -> ../init.d/gdm
lrwxrwxrwx 1 root root 20 2009-11-23 21:38 K01kerneloops -> ../init.d/kerneloops
lrwxrwxrwx 1 root root 16 2009-11-23 21:38 K01lindvd -> ../init.d/lindvd
lrwxrwxrwx 1 root root 19 2009-11-23 21:38 K01mysql-ndb -> ../init.d/mysql-ndb
lrwxrwxrwx 1 root root 17 2010-09-26 10:17 K01openvpn -> ../init.d/openvpn
lrwxrwxrwx 1 root root 19 2010-01-29 19:34 K01setserial -> ../init.d/setserial
lrwxrwxrwx 1 root root 18 2010-11-05 21:33 K01timidity -> ../init.d/timidity
lrwxrwxrwx 1 root root 17 2010-09-26 10:17 K01vboxdrv -> ../init.d/vboxdrv
lrwxrwxrwx 1 root root 23 2010-01-29 19:34 K02etc-setserial -> ../init.d/etc-setserial
lrwxrwxrwx 1 root root 23 2009-11-23 21:38 K02mysql-ndb-mgm -> ../init.d/mysql-ndb-mgm
lrwxrwxrwx 1 root root 22 2009-11-23 21:38 K02spamassassin -> ../init.d/spamassassin
lrwxrwxrwx 1 root root 20 2010-09-26 10:17 K06umountcifs -> ../init.d/umountcifs
lrwxrwxrwx 1 root root 22 2010-09-26 10:08 K08umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root 33 2011-04-22 11:08 K20vboxballoonctrl-service -> ../init.d/vboxballoonctrl-service
lrwxrwxrwx 1 root root 25 2010-10-11 18:52 K20vboxweb-service -> ../init.d/vboxweb-service
lrwxrwxrwx 1 root root 17 2009-10-04 08:38 K25hwclock.sh -> ../init.d/hwclock
lrwxrwxrwx 1 root root 19 2010-11-05 21:30 K74bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 21 2011-04-18 19:19 K99laptop-mode -> ../init.d/laptop-mode
-rw-r--r-- 1 root root 351 2011-07-14 06:11 README
lrwxrwxrwx 1 root root 16 2009-11-23 21:38 S01reboot -> ../init.d/reboot
lrwxrwxrwx 1 root root 18 2009-11-23 21:38 S01sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root 18 2009-11-23 21:38 S01umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 20 2009-11-23 21:38 S01umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root 17 2010-09-26 10:08 S02urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 29 2011-04-05 21:55 S10unattended-upgrades -> ../init.d/unattended-upgrades
lrwx...

[Steve Langasek (vorlon)]

On Tue, Sep 27, 2011 at 05:51:33PM -0000, Tom Chiverton wrote:

> lrwxrwxrwx 1 root root 22 2010-09-26 10:08 K08umountnfs.sh -> ../init.d/umountnfs.sh
[...]
> lrwxrwxrwx 1 root root 16 2009-11-23 21:38 S01reboot -> ../init.d/reboot
> lrwxrwxrwx 1 root root 18 2009-11-23 21:38 S01sendsigs -> ../init.d/sendsigs
> lrwxrwxrwx 1 root root 18 2009-11-23 21:38 S01umountfs -> ../init.d/umountfs
> lrwxrwxrwx 1 root root 20 2009-11-23 21:38 S01umountroot -> ../init.d/umountroot

Aha, here's the problem! This is certainly not the order in which these
scripts are supposed to be run. I'm surprised you didn't encounter serious
problems before now, given the above... your system is configured to reboot
before (or in parallel with) cleanly shutting down processes and unmounting
filesystems. So /etc/init.d/umountroot never gets a chance to run, or if it
does things are still mounted at the time!

Does the file /etc/init.d/.legacy-bootordering exist on your system? If
not, it looks like something has happened to fail to block insserv from
rearranging your symlinks. Did you make any deliberate changes to your
system involving insserv? How was this system originally installed?

Here are the correct symlinks on an oneiric system:

lrwxrwxrwx 1 root root 18 Apr 30 2009 S20sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root 17 Apr 30 2009 S30urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 22 Apr 30 2009 S31umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root 20 Jun 9 05:43 S35networking -> ../init.d/networking
lrwxrwxrwx 1 root root 18 Apr 30 2009 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 20 Apr 30 2009 S60umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root 16 Apr 30 2009 S90reboot -> ../init.d/reboot

I don't know if there's a good way to undo insserv mangling automatically,
or if you'll need to adjust these by hand.

Opening a task on sysv-rc, which is supposed to ensure that
/etc/init.d/.legacy-bootordering exists.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

Never come across /etc/init.d/.legacy-bootordering before !

falken@wopr:/tmp$ ls /etc/init.d/.legacy-bootordering
/etc/init.d/.legacy-bootordering
falken@wopr:/tmp$ cat /etc/init.d/.legacy-bootordering
falken@wopr:/tmp$

I don't recall mucking with insserv ever, but I've had this machine awhile, upgraded since 9.04 I think.

It looks like you should be able to spot misordered scripts and if not fix it, at least tell the user ?

[Steve Langasek (vorlon)]

On Tue, Sep 27, 2011 at 07:41:16PM -0000, Tom Chiverton wrote:
> Never come across /etc/init.d/.legacy-bootordering before !

Yes, it's meant to work invisibly ;)

> falken@wopr:/tmp$ ls /etc/init.d/.legacy-bootordering
> /etc/init.d/.legacy-bootordering
> falken@wopr:/tmp$ cat /etc/init.d/.legacy-bootordering
> falken@wopr:/tmp$

> I don't recall mucking with insserv ever, but I've had this machine
> awhile, upgraded since 9.04 I think.

ok.

> It looks like you should be able to spot misordered scripts and if not
> fix it, at least tell the user ?

Yep. I'll see what I can come up with here on that score.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[GeekSmith (lixo-geeksmith)]

Manual symlink of /var/run->/run and /var/lock-/run/lock fixed my issues.

[Steve Langasek (vorlon)]

The root cause of this problem seems to be VMWare Workstation 8/Player.

https://bugs.launchpad.net/ubuntu/lucid/+source/sysvinit/+bug/616287/comments/93

[Eduard Hasenleithner (eduard-hasenleithner)]

Maybe it makes sense to put also the 3rd party "turboprint" package in the affected package list for the release-notes (See Bug #811675)?

[Steven Haber (sthaber)]

For me, this problem was caused by VMWare Workstation 8 leaving a mount point of some sort in /var/run. After umounting and symlinking manually (per the comments above) I was good to go. I wouldn't say VMware is the root cause. The mount point is in the fstab. They aren't doing anything wrong by mounting in /var/run. The script just needs to run after it has unmounted.

[Digulla-hepe (digulla-hepe)]

I had this problem, too, and I don't have VMWare installed.

[Steve Langasek (vorlon)]

> For me, this problem was caused by VMWare Workstation 8
> leaving a mount point of some sort in /var/run.

Incorrect. The problem is that upon installation, VMWare Workstation 8 *destroys* the shutdown sequence of the system. Merely adding a mount point doesn't matter, because the shutdown scripts are designed to methodically unmount all mount points in order regardless of their origin; but this doesn't work when /etc/rc6.d has been scrambled, because 'reboot' suddenly gets called in parallel with the unmounting.

[James Cuzella (trinitronx)]

I'm seeing this on a Thinkpad T410 that has been dist-upgraded to Oneric. It started out running a freshly installed Maverick, which I have upgraded up to Oneric now.

The system failed to boot after dist-upgrade with dbus error messages like in Bug #811441

I do not have any weird cifs or nfs mounts. I do not run VMWare, only VirtualBox. I do have turboprint installed.

Here are the file listings on my system:

ls -l /etc/init.d/.legacy-bootordering
-rw-r--r-- 1 root root 0 2011-01-18 17:07 /etc/init.d/.legacy-bootordering

ls -l /etc/init.d/umountroot
-rwxr-xr-x 1 root root 2926 2011-07-13 23:10 /etc/init.d/umountroot

ls -l /etc/rc6.d/
total 4
lrwxrwxrwx 1 root root 16 2011-02-19 13:29 K01hdapsd -> ../init.d/hdapsd
lrwxrwxrwx 1 root root 17 2011-02-19 13:29 K01postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root 19 2011-02-19 13:29 K02bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 2011-07-02 01:45 K09apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 23 2011-04-04 09:29 K20uml-utilities -> ../init.d/uml-utilities
lrwxrwxrwx 1 root root 33 2011-04-21 10:24 K20vboxballoonctrl-service -> ../init.d/vboxballoonctrl-service
lrwxrwxrwx 1 root root 17 2011-04-21 10:39 K20vboxdrv -> ../init.d/vboxdrv
lrwxrwxrwx 1 root root 25 2011-04-21 10:39 K20vboxweb-service -> ../init.d/vboxweb-service
lrwxrwxrwx 1 root root 17 2011-07-20 11:50 K20winbind -> ../init.d/winbind
-rw-r--r-- 1 root root 351 2011-07-13 23:11 README
lrwxrwxrwx 1 root root 26 2011-02-19 13:29 S01cryptdisks-early -> ../init.d/cryptdisks-early
lrwxrwxrwx 1 root root 20 2011-02-19 13:29 S02cryptdisks -> ../init.d/cryptdisks
lrwxrwxrwx 1 root root 16 2011-02-19 13:29 S03reboot -> ../init.d/reboot
lrwxrwxrwx 1 root root 18 2011-02-19 13:29 S03sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root 18 2011-02-19 13:29 S03umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 22 2011-02-19 13:29 S03umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root 20 2011-02-19 13:29 S03umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root 17 2011-02-19 13:29 S04urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 29 2011-04-29 12:19 S10unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx 1 root root 20 2011-10-14 02:13 S35networking -> ../init.d/networking

[James Cuzella (trinitronx)]

FYI: I had previously upgraded from Maverick -> Natty
I experienced the issue when upgrading from Natty -> Oneric

I manually did the following:

sudo mv /var/run/* /run/
sudo mv /var/lock/* /run/lock/
sudo rmdir /var/run
sudo rmdir /var/lock
sudo ln -s /run /var/run
sudo ln -s /run/lock /var/lock

I rebooted, and X still does not start! Most of the boot process looks ok, except for the following errors:

rpcbind: Cannot open '/var/run/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory)
rpcbind: Cannot open '/var/run/rpcbind/portmap.xdr' file for reading, errno 2 (No such file or directory)

[Eduard Hasenleithner (eduard-hasenleithner)]

The same what Steve said for vmware is also true for turboprint: "*destroys* the shutdown sequence of the system."

You could try to fiddle with the '/run' symlinks and manually correct the script order. But IMHO the only reliable way to get the script order "back" is to make a fresh Oneiric install, and not install the buggy package again, until the package provider fixed it.

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

I disagree. There is no sane reason for those packages to be messing with the order.
The change to the order renders a system unusable on upgrade.
The upgrade should just fix the order.

[Eduard Hasenleithner (eduard-hasenleithner)]

As a highly experimental means to get the system back working one can try to:

sudo mv /etc/rc6.d/S01reboot /etc/rc6.d/S90reboot
sudo mv /etc/rc6.d/S01umountroot /etc/rc6.d/S60umountroot

and do a "sudo reboot" afterwards. Please be aware that the other scripts remain reordered, but it should be enough to be able to backup your data. E.g. on halt, the harddisks will not be unmounted properly.

[Steve Langasek (vorlon)]

On Fri, Oct 14, 2011 at 09:50:19PM -0000, Eduard Hasenleithner wrote:
> As a highly experimental means to get the system back working one can
> try to:

> and do a "sudo reboot" afterwards. Please be aware that the other
> scripts remain reordered, but it should be enough to be able to backup
> your data. E.g. on halt, the harddisks will not be unmounted properly.

I suggest also including umountfs, sendsigs, and umountnfs.sh in this list
to cover all the cases.

Also, the exact sequence numbers will be different depending on what else
was installed.

So a complete workaround would be (untested):

 mv /etc/rc6.d/S*reboot /etc/rc6.d/S90reboot
 mv /etc/rc6.d/S*umountroot /etc/rc6.d/S60umountroot
 mv /etc/rc6.d/S*umountnfs.sh /etc/rc6.d/S31umountnfs.sh
 mv /etc/rc6.d/S*umountfs /etc/rc6.d/S40umountfs
 mv /etc/rc6.d/S*sendsigs /etc/rc6.d/S20sendsigs

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Kevin Jackson (kevin-linuxservices)]

This error produces the "Waiting for network configuration" error message.
The fix is to symlink /var/run to /run and /var/lock to /run/lock

http://uksysadmin.wordpress.com/2011/10/14/upgrade-to-ubuntu-11-10-problem-waiting-for-network-configuration-then-black-screen-solution/

I've had a massive influx of traffic to this post suggesting this is a affecting many people on real and virtual hardware. It downed my machine immediately after the first reboot of my upgraded 11.10 laptop.

Note it doesn't affect clean installs suggesting a conflict of trying to point /var/run (directory) and /var/lock (directory) to /run and /run/lock on tmpfs as symlinks (possibly unable to remove the directories on a running system?)

[James Cuzella (trinitronx)]

Update: I found that the root cause of my X11 not starting was due to my nvidia-current package being in a bad state during the upgrade. The video drivers were not installed for the new kernel, which was causing the second issue.

After manually doing the move & symlink of /var/run and /var/lock, everything seems to be in working order now. I didn't end up messing with the ordering of scripts in runlevel 6 at all.

[Trebacz (david-trebacz)]

Much like the responder in #24. I became a subscriber to this bug to to the errors that I was seeing after the upgrade from 11.04 to 11.10. Based on what I'm seeing in my system logs it seems the video driver integration into the latest 3.0.0-12.20 kernel is borked. My upgrade reported that the machine was likely left in a unstable state. I found that I could log into my system using the old kernel 2.6.38-11. I was seeing the symptoms of this bug, but do have symlinks to /var/run and /var/lock. My system does utilize smb4k and nvidia-current for my video driver.

Now I'd like to understand what I need to do to get my nvidia-current correctly installed with the 3.0.0-12.20 new kernel.

[Jonas Sundman (jonas-sundman)]

Like #18 ran into this when updating to maverick. As both occured in VMware guest installations I suspect that in that specific case vmware-tools caused the incomplete transition.

I also saw messed up shutdown orders, but not in all installations. You may also have a look at rc0.d for halting.

[TinHo MAK (csmth96)]

Could I know that what should be done to receive the fix? The manual fix (commands listed in #18) does not seems to be stable when my PC is going to upgrade again (to 12.04 LTS).

I do not dare to reboot my PC because of this bug.

[Steve Langasek (vorlon)]

On Sun, Oct 23, 2011 at 06:50:16AM -0000, TinHo MAK wrote:
> Could I know that what should be done to receive the fix? The manual fix
> (commands listed in #18) does not seems to be stable when my PC is going
> to upgrade again (to 12.04 LTS).

> I do not dare to reboot my PC because of this bug.

Please use the commands from comment #22. It's likely that this is the
fix that will be implemented in Ubuntu.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Marius B. Kotsbak (mariusko)]

Hmm, I have verified #22 and my /run seems right:

$ ls -lhd /run
drwxr-xr-x 23 root root 880 2011-10-23 04:22 /run

$ ls -lhd /var/run
lrwxrwxrwx 1 root root 4 2011-10-22 01:34 /var/run -> /run

$ ls -lhd /var/run/lock/
drwxrwxrwt 2 root root 40 2011-10-23 04:22 /var/run/lock/

but I still get the network config error at startup. Are there other sources of this error?

[Steve Langasek (vorlon)]

You don't say what error message you're receiving, but if you have /var/run as a symlink, then it's not caused by this bug.

[Arul (aselvan)]

Like many here, I had the same problem when upgrading natty server to oneiric server. The conversion/migration of /var/run to /run during the upgrade process is buggy causing all sorts of problems until the content of /var/run and /var/lock are moved to /run and symlinks are created shown below as per comment #18.

ls -l /var/run /var/lock
lrwxrwxrwx 1 root root 9 2011-10-23 12:24 /var/lock -> /run/lock/
lrwxrwxrwx 1 root root 4 2011-10-23 12:23 /var/run -> /run/

PS: The strange thing is, I upgraded my desktop version last week from natty->oneiric, the upgrade went just fine with the migration done properly.

[bart95130 (marc-lecrosnier)]

Hi,

same problem after a migration from natty->oneiric desktop.
I had to create symlinks for /var/run and /var/lock
and it works again

[Marius B. Kotsbak (mariusko)]

Steve, I opened a new bug report #881079 as I could not see any reported for my case.

[Jeff Burns (admiraljkb)]

It looks like I'm having the "Waiting for network configuration" issue as well, but while an annoyance, I've ignored it until today. I figured it was related to an extra NIC being unconfig'd. I just config'd LACP and I've still got it, so went hunting for a bug.

I checked and I've got the symlinks. The weird thing is the symlink for /var/run to /run was created ~2.5 hours ago when I last did an update/reboot, while the other is from my upgrade to 11.10. Not sure if that is significant. Upgrade path natty --> oneric

ls -l /var/run /var/lock
lrwxrwxrwx 1 root root 9 2011-10-10 21:13 /var/lock -> /run/lock
lrwxrwxrwx 1 root root 4 2011-10-24 19:48 /var/run -> /run

I didn't see this on an Ubuntu Server with 4 NIC's LACP'd going from Natty to Oneric, nor on my Kubuntu laptop, just on this desktop. I can get any other details if needed.

[Marius B. Kotsbak (mariusko)]

Jeff, maybe you suffer from bug #881079 too? I thought about the extra NIC from my 3G card, but I also experience it without the modem enabled.

[phoebus (phoebus)]

Any progress on this one?

[trent-- (sylvainfaivre)]

I also experienced this bug, because I had the shutdown script order messed up by VMware Workstation.
Everything was fixed by manually creating the links to /run and /run/lock as per #18, and restoring the correct shutdown script order as per #22.
So, as a side effect of the /run problem, this fixed a long standing problem with the shutdown sequence. I used to stupidly wonder why fsck often reported "orphan nodes deleted" on reboot, now it won't happen any more !

[karit (nzkarit)]

If you are pre upgrade to 11.10 can you uninstall VMWare Player and then reinstall Player after update and avoid this issue? Just thinking about work around strategies. As currently the this only covers how to fix up the issue.

[Steve Langasek (vorlon)]

On Sun, Oct 30, 2011 at 09:46:30PM -0000, karit wrote:
> If you are pre upgrade to 11.10 can you uninstall VMWare Player and then
> reinstall Player after update and avoid this issue?

No. VMWare Player damages the shutdown script ordering; uninstalling it
won't undo this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[James Cuzella (trinitronx)]

Trebacz (from Comment #25),

I was able to simply uninstall and re-install the package, and it seems to work fine now. I pressed Ctrl+Alt+F1 when I got the blank screen after a reboot, logged in, and did this:

sudo apt-get remove nvidia-current
sudo apt-get install nvidia-current

[magelan (magelan)]

The root of this cause is not vmware (because I never even knew about it until some weeks, but my bug exists longer) or I have another variant.
Look at my symlinks:
"/var$ ll
insgesamt 64
drwxr-xr-x 16 root root 4096 2011-10-30 22:47 ./
drwxr-xr-x 23 root root 4096 2011-10-19 21:43 ../
...
drwxrwsr-x 2 root staff 4096 2010-04-23 12:11 local/
lrwxrwxrwx 1 root root 9 2011-10-19 22:08 lock -> /run/lock/
...
lrwxrwxrwx 1 root root 4 2011-10-30 22:47 run -> /run/
..."
Everything right?

[Steve Langasek (vorlon)]

On Mon, Oct 31, 2011 at 08:57:44PM -0000, magelan wrote:
> The root of this cause is not vmware (because I never even knew about it
> until some weeks, but my bug exists longer) or I have another variant.

You have a completely unrelated issue, because:

> Look at my symlinks:
> "/var$ ll
> insgesamt 64
> drwxr-xr-x 16 root root 4096 2011-10-30 22:47 ./
> drwxr-xr-x 23 root root 4096 2011-10-19 21:43 ../
> ...
> drwxrwsr-x 2 root staff 4096 2010-04-23 12:11 local/
> lrwxrwxrwx 1 root root 9 2011-10-19 22:08 lock -> /run/lock/
> ...
> lrwxrwxrwx 1 root root 4 2011-10-30 22:47 run -> /run/
> ..."
> Everything right?

These are the correct symlinks.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[A.B. (abadr)]

packrook solution worked for me. Thanks.
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/811441/comments/9

This is a serious bug brought down an important backup server. The server was a standard Ubuntu server installation with only 1 foreign repo (webmin). This doesn't look good for Ubuntu or Linux.

[markusj (markusj)]

My rc0.d/rc6.d have been broken the same way. Can someone please tell me the default order for rc0.d, please? For now, i'm assuming they are the same as for rc6, is that correct?

This is an epic fail. Really. fsck on each boot because none of the filesystems has been unmounted properly is inacceptable, especially for an "server" distribution. This /run migration thing created a big mess, i had to do the work by myself, no symlinks have been created automagically.

Is there a way to rebuild the contents of rc*.d despite of doing it manually?

ls -la /etc/rc0.d
[...]
-rw-r--r-- 1 root root 353 2011-07-14 07:11 README
lrwxrwxrwx 1 root root 14 2011-09-09 12:35 S01halt -> ../init.d/halt
lrwxrwxrwx 1 root root 20 2011-10-30 14:58 S01networking -> ../init.d/networking
lrwxrwxrwx 1 root root 18 2011-09-09 12:35 S01sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root 18 2011-09-09 12:35 S01umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 22 2011-09-09 12:35 S01umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root 20 2011-09-09 12:35 S01umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root 17 2011-09-09 12:35 S02urandom -> ../init.d/urandom

[Steve Langasek (vorlon)]

On Mon, Nov 07, 2011 at 12:07:12PM -0000, markusj wrote:
> My rc0.d/rc6.d have been broken the same way. Can someone please tell me
> the default order for rc0.d, please? For now, i'm assuming they are the
> same as for rc6, is that correct?

See comment #22.

> This /run migration thing created a big mess, i had to do the work by
> myself, no symlinks have been created automagically.

No, some third-party software which incorrectly assumes it's ok to call
insserv directly on installation created a big mess. The /run migration has
simply made the existence of this big mess apparent. In particular, the
failure to cleanly unmount filesystems on shutdown is entirely unrelated to
the /run migration.

> Is there a way to rebuild the contents of rc*.d despite of doing it
> manually?

No. The nature of the damage done by the third-party packages calling
insserv is such that the system cannot unwind this automatically. We will
be adding some code to do this in a stable release update for 11.10.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Paul Crawford (psc-sat)]

Suffered similar issue of the /etc/rc0.d and rc6.d links being mangled by VMware player upgrade, in my case using 10.04.3 LTS version. Wrote a short script that puts it back to the order that I found on another (hopefully correct) 10.04 installation.

As with all scripts, and in particular with something you need to run as root/sudo, check carefully and THINK before using it!

[Endre Stølsvik (stolsvik)]

As "A.B. (abadr)" wrote in comment#43, my system that was hit by this is a pure Ubuntu box, *except for the fact that webmin is installed*.

[Arkadiy Kulev (eth-ethaniel)]

Still not fixed as of 26 December 2011.

[Adam Stokes (adam-stokes)]

re comment #45

Steve,

If we think about moving insserv out of system path we need to make sure that update-rc.d is not broken by this since it assumes it can reach the binary within the path. Other than that I dont think anything else would be affected.

[Steve Langasek (vorlon)]

On Fri, Jan 13, 2012 at 08:42:12AM -0000, Adam Stokes wrote:
> If we think about moving insserv out of system path we need to make sure
> that update-rc.d is not broken by this since it assumes it can reach the
> binary within the path. Other than that I dont think anything else
> would be affected.

In fact, update-rc.d only ever calls insserv if
/etc/init.d/.legacy-bootordering does not exist, which it should for all
Ubuntu systems:

if ( ! -f "/etc/init.d/.legacy-bootordering" ) {
    info("using dependency based boot sequencing");
    exit insserv_updatercd(@ARGV);
}

Having update-rc.d fail for users who have manually removed this file is
probably the lesser evil, and fixable by having them re-create the flag
file.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Adam Stokes (adam-stokes)]

This patch attempts to move insserv out of the system path in order to dissuade package maintainers from invoking it directly.

[Joonas Paalasmaa (joonas-paalasmaa)]

It's a bit unclear to me what the recommended fix for the upgrade process is. I would like to upgrade from 11.04 to 11.10. I am running Ubuntu in VMware Workstation 7.1.1.

[Evan Broder (broder)]

Hi Adam -

Thanks for working on getting that patch together. I've gone ahead and sponsored it into precise, and will be working on an SRU for oneiric momentarily. For future reference, I made a few tweaks before uploading:

 1. The insserv package is source format 3.0 (quilt), so it uses quilt to manage patches (http://developer.ubuntu.com/packaging/html/patches-to-packages.html#patches-with-quilt). I created a quilt patch containing your change. We also try to apply the DEP-3 guidelines in distro patches so we can track their provenance down the road (http://dep.debian.net/deps/dep3/)

 2. Your changelog entry targets "unstable" - Ubuntu changes should always refer to the Ubuntu release they're targeting; in this case, that would be "precise"

 3. When Ubuntu changes a Debian package, our policy is to adjust the maintainer field in debian/control - the update-maintainer script in ubuntu-dev-tools will do this for you automatically. It's also our policy to adjust the Vcs-* fields to be XSBC-Debian-Vcs-*. update-maintainer doesn't currently do this, so you have to do it yourself (bug #567629)

I'm also working on a change to initscripts to try and clean up some of the fallout of this bug for people who have hit it; hopefully that should land later today.

Joonas: If you have not yet installed VMware Workstation 8, just removing /usr/sbin/insserv should be sufficient (nothing on an Ubuntu system should actually use it). If you have, run the series of "mv" commands in the bug's description

[Evan Broder (broder)]

(Err, to clarify, I have not sponsored it just yet, but will be doing so momentarily after a little more testing)

[Evan Broder (broder)]

Ok. I've installed the package in a VM and then verified that installing VMware Player does not break my boot order. Therefore, I've uploaded the change to precise and oneiric-proposed. The oneiric-proposed upload should be processed by a member of the SRU team before too long.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sysvinit - 2.88dsf-13.10ubuntu10

---------------
sysvinit (2.88dsf-13.10ubuntu10) precise; urgency=low

  * On upgrade, detect and correct broken shutdown sequence caused by
    3rd-party packages running insserv. (LP: #858122)
 -- Evan Broder <email address hidden> Wed, 15 Feb 2012 18:38:19 -0800

[Steve Langasek (vorlon)]

Fixed in the latest upload of insserv:

insserv (1.14.0-2.1ubuntu1) precise; urgency=low

  * Add 200_hide_insserv_on_ubuntu.patch: Move insserv out of system path
    to disuade package maintainers from invoking it directly. (LP:
    #897390)

[Jose Plans (jplans)]

Hi, uploading a debdiff for Lucid. thanks,

[Evan Broder (broder)]

I've uploaded SRUs of insserv to lucid, maverick, natty, and oneiric. Based on IRC discussions with Steve, I added a postinst to those versions that cleans up the broken shutdown sequence. It's the same snippet that I added to initscripts, but for the SRU case, ensuring correct ordering of the upgrade is too difficult.

[Steve Langasek (vorlon)]

Hello Tom, or anyone else affected,

Accepted into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Steve Langasek (vorlon)]

Hello Tom, or anyone else affected,

Accepted into maverick-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Steve Langasek (vorlon)]

Hello Tom, or anyone else affected,

Accepted into natty-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Steve Langasek (vorlon)]

Hello Tom, or anyone else affected,

Accepted into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

I'm not sure we can report anything useful though, as anyone reading this will already have fixed the boot order in order to get their machine working again :-)

[Evan Broder (broder)]

The fixes seem to work in my build chroots for all 4 releases:

evan@caron:~$ schroot -c oneiric-amd64 -u root
(oneiric-amd64)root@caron:~# apt-get update -qq
(oneiric-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(oneiric-amd64)root@caron:~# insserv &>/dev/null
(oneiric-amd64)root@caron:~# ls /etc/rc6.d
README S01reboot S01umountfs S01umountroot
S01networking S01sendsigs S01umountnfs.sh S02urandom
(oneiric-amd64)root@caron:~# echo 'deb http://localhost:9999/ubuntu oneiric-proposed main restricted universe multiverse' >>/etc/apt/sources.list
(oneiric-amd64)root@caron:~# apt-get update -qq
(oneiric-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(oneiric-amd64)root@caron:~# ls /etc/rc6.d
README S02urandom S31umountnfs.sh S60umountroot
S01networking S20sendsigs S40umountfs S90reboot
(oneiric-amd64)root@caron:~# hash insserv
-bash: hash: insserv: not found

evan@caron:~$ schroot -c natty-amd64 -u root
(natty-amd64)root@caron:~# apt-get update -qq
(natty-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(natty-amd64)root@caron:~# insserv &>/dev/null
(natty-amd64)root@caron:~# ls /etc/rc6.d
README S01reboot S01umountfs S01umountroot
S01networking S01sendsigs S01umountnfs.sh S02urandom
(natty-amd64)root@caron:~# echo 'deb http://localhost:9999/ubuntu natty-proposed main restricted universe multiverse' >>/etc/apt/sources.list
(natty-amd64)root@caron:~# apt-get update -qq
(natty-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(natty-amd64)root@caron:~# ls /etc/rc6.d
README S02urandom S31umountnfs.sh S60umountroot
S01networking S20sendsigs S40umountfs S90reboot
(natty-amd64)root@caron:~# hash insserv
-bash: hash: insserv: not found
(natty-amd64)root@caron:~# logout

evan@caron:~$ schroot -c maverick-amd64 -u root
(maverick-amd64)root@caron:~# apt-get update -qq
(maverick-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(maverick-amd64)root@caron:~# insserv &>/dev/null
(maverick-amd64)root@caron:~# ls /etc/rc6.d
README S01reboot S01umountfs S01umountroot
S01networking S01sendsigs S01umountnfs.sh S02urandom
(maverick-amd64)root@caron:~# echo 'deb http://localhost:9999/ubuntu maverick-proposed main restricted universe multiverse' >>/etc/apt/sources.list
(maverick-amd64)root@caron:~# apt-get update -qq
(maverick-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(maverick-amd64)root@caron:~# ls /etc/rc6.d
README S02urandom S31umountnfs.sh S60umountroot
S01networking S20sendsigs S40umountfs S90reboot
(maverick-amd64)root@caron:~# hash insserv
-bash: hash: insserv: not found
(maverick-amd64)root@caron:~# logout

evan@caron:~$ schroot -c lucid-amd64 -u root
(lucid-amd64)root@caron:~# apt-get update -qq
(lucid-amd64)root@caron:~# apt-get dist-upgrade -yy &>/dev/null
(lucid-amd64)root@caron:~# insserv &>/dev/null
(lucid-amd64)root@caron:~# ls /etc/rc6.d
README S01reboot S01umountfs S01umountroot
S01networking S01sendsigs S01umountnfs.sh S02urandom
(lucid-amd64)root@caron:~# echo 'deb http://localhost:9999/ubuntu lucid-proposed main restricted universe multiverse' >>/etc/apt/sources....

[Eduard Hasenleithner (eduard-hasenleithner)]

Yes, Tom is right. In order to avoid the problem I reinstalled my system from scratch and did not install the faulty package.

Nevertheless, I tried oneiric-proposed with a virtual machine and the faulty package.

# BEFORE INSTALL OF turboprint
eduard@qemu-oneiric:~$ ls /etc/rc6.d
K20speech-dispatcher README S31umountnfs.sh S60umountroot
K20unattended-upgrades S20sendsigs S35networking S90reboot
K74bluetooth S30urandom S40umountf

# AFTER INSTALL OF turboprint 2.21-1
eduard@qemu-oneiric:~$ ls /etc/rc6.d
K01speech-dispatcher README S01sendsigs S01umountroot
K01unattended-upgrades S01networking S01umountfs S02urandom
K02bluetooth S01reboot S01umountnfs.sh

# AFTER ACTIVATION OF oneiric-proposed
eduard@qemu-oneiric:~$ ls /etc/rc6.d
K01speech-dispatcher README S20sendsigs S60umountroot
K01unattended-upgrades S01networking S31umountnfs.sh S90reboot
K02bluetooth S02urandom S40umountfs

Apparently, not all scripts are restored, but the most important are.

On a further note, i can confirm that insserv is not in the search path anymore, and calling it from bash reports that insserv is not installed. (This might be a bit misleading, but personally I don't care)

[Metabaronen (emil-assarsson)]

Just a note... I can't get why the sendsig (for example) does have a S-link. The script does only handle stop (start is a no-op). Same goes for umountfs etc.

[Metabaronen (emil-assarsson)]

Sorry! I managed to click on a link that changed the status with no questions asked (just wanted to get an explanation of the status). Can someone undo the Status change? I can't undo it myself :-/

[Alex L. (alexal)]

Hello.

I've installed Ubuntu 11.10 from the scratch and I do not have VMWare on my computer, but I have the same problem. I've recreated symbolic links (please see below), but this didn't solved problem with loading.

alex@alex-thinkpad-t410:~$ ls -l /var/run /var/lock
lrwxrwxrwx 1 root root 9 2012-02-29 22:10 /var/lock -> /run/lock
lrwxrwxrwx 1 root root 4 2012-02-29 22:10 /var/run -> /run

Alex

[Steve Langasek (vorlon)]

On Wed, Feb 29, 2012 at 06:21:14PM -0000, Alex L. wrote:
> I've installed Ubuntu 11.10 from the scratch and I do not have VMWare on
> my computer, but I have the same problem. I've recreated symbolic links
> (please see below), but this didn't solved problem with loading.

Please test the package in oneiric-proposed that addresses this issue, as
described in the link referenced from comment #64
(https://wiki.ubuntu.com/Testing/EnableProposed) and let us know if this
resolves the problem for you.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Bartosz Kosiorek (gang65)]

On webpage http://people.canonical.com/~ubuntu-archive/pending-sru.html
the package insserv has wrong LP number.

It is #897390 , but it should be #858122

Could you please fix this?

[Nathan Stratton Treadway (nathanst)]

The debian/changelog entry also has the LP number listed incorrectly (as does the related Bazaar commit message):

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/insserv/lucid-proposed/revision/15/debian/changelog
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/insserv/oneiric-proposed/revision/17/debian/changelog
(etc.)

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

Please see #941867 - in Precise the postinst script that attempts to change the order to the correct one fails, leaving the system unable to boot the default kernel (because initrd isn't generated during dist-upgrade) with no networking (update of network-manager depends on initscripts) or working X.

The fix is simple enough, in the fix up block "# Cleanup the broken shutdown sequence created by 3rd-party packages" run the mv commands in a way so their failure (for instance, because the order is OK already so mv complains the source and destination are the same) doesn't kill the package install.

Fixed script attached.

[Steve Langasek (vorlon)]

Bug #941867 is a regression introduced by this change. We need to cope with systems whose shutdown script ordering has already been partially fixed locally by the admin.

[JC Hulce (soaringsky)]

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

[Clint Byrum (clint-fewbar)]

[BUMP] can somebody verify this fix on lucid?

[Peter Matulis (petermatulis)]

@Clint

Wasn't verification done on all releases back in comment #66?

[Scott Kitterman (kitterman)]

Looks like it was.

[Launchpad Janitor (janitor)]

This bug was fixed in the package insserv - 1.12.0-14ubuntu0.2

---------------
insserv (1.12.0-14ubuntu0.2) lucid-proposed; urgency=low

  * Only try to move links in /etc/rc{0,6}.d that match "S0*". LP: #941867.

insserv (1.12.0-14ubuntu0.1) lucid-proposed; urgency=low

  [ Adam Stokes ]
  * Add 200_hide_insserv_on_ubuntu.patch: Move insserv out of system path
    to disuade package maintainers from invoking it directly. (LP:
    #858122)

  [ Evan Broder ]
  * Fix the shutdown sequence if it was broken by insserv being run at
    some point in the past.
 -- Steve Langasek <email address hidden> Fri, 13 Apr 2012 22:08:39 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package insserv - 1.14.0-2ubuntu0.11.04.2

---------------
insserv (1.14.0-2ubuntu0.11.04.2) natty-proposed; urgency=low

  * Only try to move links in /etc/rc{0,6}.d that match "S0*". LP: #941867.

insserv (1.14.0-2ubuntu0.11.04.1) natty-proposed; urgency=low

  [ Adam Stokes ]
  * Add 200_hide_insserv_on_ubuntu.patch: Move insserv out of system path
    to disuade package maintainers from invoking it directly. (LP:
    #858122)

  [ Evan Broder ]
  * Fix the shutdown sequence if it was broken by insserv being run at
    some point in the past.
 -- Steve Langasek <email address hidden> Fri, 13 Apr 2012 22:07:25 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package insserv - 1.14.0-2.1ubuntu0.2

---------------
insserv (1.14.0-2.1ubuntu0.2) oneiric-proposed; urgency=low

  * Only try to move links in /etc/rc{0,6}.d that match "S0*". LP: #941867.

insserv (1.14.0-2.1ubuntu0.1) oneiric-proposed; urgency=low

  [ Adam Stokes ]
  * Add 200_hide_insserv_on_ubuntu.patch: Move insserv out of system path
    to disuade package maintainers from invoking it directly. (LP:
    #858122)

  [ Evan Broder ]
  * Fix the shutdown sequence if it was broken by insserv being run at
    some point in the past.
 -- Steve Langasek <email address hidden> Fri, 13 Apr 2012 22:07:04 -0700

[jaseywang (jaseywang)]

After I patched the right version, do I need to reboot the box or it will take effect on the fly?

[Ads20000 (ads20000)]

Apparently this: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/811441 is a duplicate of this 'Fix Released' bug yet I still get the error on my Xubuntu 13.10 laptop...