[Bug 899795] Re: hang during boot after upgrade to oneiric

[linas]

I just discovered that there are a fair number of files in /etc/init
that are stale, and do not belong to any dpkg.  That is, dpkg -S
/etc/init/whatever reports that there's no owning package. Judging from
the timestamps on these files, they appear to belong to 11.04 or even
earlier distros, and should have been removed/replaced, but weren't.
This suggests that dpkg is getting confused about what's installed
and/or install glitches cause dpkg to forget to run .postrm scripts.  I
will try to manually remove the orphaned files & see if this fixes the
problem.  I notice that some of the orphans include udev and dbus and
hal ...  it may take a few days to get around to this...

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
https://bugs.launchpad.net/bugs/899795

Title:
  hang during boot after upgrade to oneiric

Status in Upstart:
  New
Status in “update-manager” package in Ubuntu:
  New

Bug description:
  After upgrading to oneirc, and rebooting, system hangs during boot.
  Problem seems to be a bad interaction with upstart, udev, and lvm
  (device mapper) filesystems.  Details below:

  During boot, kernel appears to boot fully. Next set of messages show
  fsck running, and then a hang. Using the old init=/bin/sh trick, I can
  see that all of my file systems are now mounted, except one: a file
  system that lives on an lvm volume. I believe that, at this point,
  upstart is waiting for the lvm volume to come online... but of course,
  it can't/won't until lvm and the device-mapper run, which is typically
  done later, in the /etc/init.d scripts.  (The mount point, a directory
  in /dev/mapper, hasn't yet been created).   Commenting out the lvm
  volume in /etc/fstab allows the boot to proceed, more or less
  normally; the missing file system can then be mounted by hand.

  With the above problem worked around, there is another alarming
  problem: much, much later in the boot, after a number of /etc/init.d
  scripts run, if finally gets around to running /etc/init.d/checkfs,
  which does an ... fsck!  but with upstart, most all file systems are
  already mounted at this point, so the fsck crashes & burns.  In the
  old SysV init scheme, this was correct: the fsck would not run until
  *after* the /etc/init.d/lvm2 scripts ran.

  The clever sysadmin can work around these, but .. wow, it was hard and
  painful to figure out the above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/upstart/+bug/899795/+subscriptions