[Bug 358654] Re: udevadm trigger is not permitted while udev is unconfigured

[Launchpad Bug Tracker]

** Branch linked: lp:~xnox/debian/sid/cryptsetup/ubuntu

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

Title:
  udevadm trigger is not permitted while udev is unconfigured

Status in “bcmwl” package in Ubuntu:
  Invalid
Status in “cryptsetup” package in Ubuntu:
  Fix Released
Status in “devmapper” package in Ubuntu:
  Fix Released
Status in “fuse” package in Ubuntu:
  Triaged
Status in “kbd” package in Ubuntu:
  Fix Released
Status in “linux” package in Ubuntu:
  Incomplete
Status in “lvm2” package in Ubuntu:
  Fix Released
Status in “ntfs-3g” package in Ubuntu:
  Fix Released
Status in “plymouth” package in Ubuntu:
  Fix Released
Status in “watershed” package in Ubuntu:
  Fix Released

Bug description:
  I've just finished helping a German user diagnose a failed-boot issue
  after the system had been updated. The failure means that although
  udevd starts it doesn't do anything so no devices are populated.

  Later, we found a forums post (also in the German language) with the
  same issue which shows:

  udevadm trigger is not premitted while udev is unconfigured.
  Gave up waiting for root device. Common problems:
  -Boot args (cat /proc/cmdline)
    -Check rootdelay= (did the system wait long enough)
    -Check root= (did the system wait for the right device?)
  -Missing modules (cat /proc/modules; ls /dev)
  ALERT! /dev/disk/by-uuid/05d79451-0ad0-43fc-9f51-a2c98b4831f2 does not exist. 
  Dropping to a shell!

  See: http://forum.ubuntuusers.de/topic/nach-update-bootet-laptop-
  nicht-mehr/

  It seems that the user was prompted to restart the system before the
  system had been fully configured. I'm not sure how that could happen
  and unfortunately we have no logs to look at, but this should at least
  be on the radar.

  The user reported he updates the system every day so in this case the
  difference was between 8th April and 9th April.

  Discussing it on 'ubuntu-devel kees suggested the best packages to
  post this against since:

  <kees> you could open it against both udev and linux :)
  <kees> ...well both of those packages drop the "please reboot" file, so they likely both need to be fixed.

  But Scott thought that wouldn't help and needs a cross reference check
  of the postinst scripts against package depends:

  <Keybuk> instead grep /var/lib/dpkg/info/*.postinst and look for calls to update-initramfs
  <Keybuk> and check each of the packages to make sure they have Depends: initramfs-tools
  <Keybuk> if you find some which don't, file bugs on them

  For which the user needs to return to check their particular
  installation, since they left in a hurry once the problem was finally
  fixed.

  However, the following shell script identifies some packages that
  don't depend on initramfs-tools:

  for ITEM in /var/lib/dpkg/info/*.postinst; do PKG=$(sed -n "/update-
  initramfs/ s/.*/${ITEM##*/}/p" $ITEM | sort -u); [ ! -z $PKG ] &&
  (apt-cache depends ${PKG%%.postinst} | grep Depends | grep -q
  initramfs-tools || echo ${PKG%%.postinst}); done

  For now I've assigned some of the packages this identifies whilst
  discussion continues as to the extent of the issue.

  
  ----------
  The solution is to use a live-CD to mount the system (or boot from a completely separate installation), mount the failed OS partition(s), and complete the update process:

  e.g.

  sudo -i

  # create a target mount point
  mkdir /mnt/target

  # mount root
  mount /dev/sda8 /mnt/target
  # mount boot
  mount /dev/sda9 /mnt/target/boot

  # into Jaunty
  chroot /mnt/target/

  # update
  dpkg --configure -a

  # done
  exit

  #unmount
  umount /mnt/target/boot
  umount /mnt/target

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