udevadm trigger is not permitted while udev is unconfigured

[TJ]

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

[TJ (tj)]

These are the package on my system that do not show depends on initramfs-tools:

cryptsetup
dmsetup
fuse-utils
initramfs-tools
kbd
ntfs-3g
watershed

[Kees Cook (kees)]

for i in $(grep update-initramfs /var/lib/dpkg/info/*.{post,pre}{rm,inst} | cut -d: -f1 | perl -pe 's/\.(post|pre)(inst|rm)//' | sort -u | awk -F/ '{print $NF}'); do apt-cache show $i | grep Depends | head -n1 | egrep -qv 'initramfs-tools' && echo $i; done

Ignoring fuse-utils for now since it Depends on udev already.

[Launchpad Janitor (janitor)]

This bug was fixed in the package watershed - 4

---------------
watershed (4) jaunty; urgency=low

  * debian/control: Depend on initramfs-tools so system is not potentially
    rendered unbootable (LP: #358654).

 -- Kees Cook <email address hidden> Thu, 09 Apr 2009 12:32:54 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package cryptsetup - 2:1.0.6-7ubuntu7

---------------
cryptsetup (2:1.0.6-7ubuntu7) jaunty; urgency=low

  * debian/control: Depend on initramfs-tools so system is not potentially
    rendered unbootable (LP: #358654).

 -- Kees Cook <email address hidden> Thu, 09 Apr 2009 12:29:31 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package devmapper - 2:1.02.27-4ubuntu5

---------------
devmapper (2:1.02.27-4ubuntu5) jaunty; urgency=low

  * debian/control: Depend on initramfs-tools so system is not potentially
    rendered unbootable (LP: #358654).

 -- Kees Cook <email address hidden> Thu, 09 Apr 2009 12:31:02 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package kbd - 1.14.1-4ubuntu4

---------------
kbd (1.14.1-4ubuntu4) jaunty; urgency=low

  * debian/control: Depend on initramfs-tools so system is not potentially
    rendered unbootable (LP: #358654).

 -- Kees Cook <email address hidden> Thu, 09 Apr 2009 12:31:48 -0700

[mjhorsnell (matt-horsnell)]

Still not fixed even with all packages above upgraded.

Output of

"for i in $(grep update-initramfs /var/lib/dpkg/info/*.{post,pre}{rm,inst} | cut -d: -f1 | perl -pe 's/\.(post|pre)(inst|rm)//' | sort -u | awk -F/ '{print $NF}'); do apt-cache show $i | grep Depends | head -n1 | egrep -qv 'initramfs-tools' && echo $i; done"

on my system (with ubuntu studio installed) is:

fuse-utils
initramfs-tools
linux-restricted-modules-2.6.28-11-generic
linux-restricted-modules-2.6.28-3-rt

I can boot in the rt kernel as a workaround for now.

[Kees Cook (kees)]

After getting the latest packages, you should verify:

a) /sbin/udevadm is a real file not the during-update-shell-script
b) rebuild your initramfs for all kernels (since you're booted on a different kernel)

If "a" above isn't fixed, that's a new bug.
For "b", you'll want "sudo update-initramfs -u -k VERSION" where VERSION is the kernel version to fix.

[mjhorsnell (matt-horsnell)]

Thanks Kees, "b" solution fixed my problem. I passed "all" as the version and let it rebuild for all my kernels.

[Miguel Gaspar (ghaspias)]

I had recently upgraded to Jaunty beta. Yesterday, after updating via synaptic (mark all updates - smart upgrade), I didn't immediately reboot and did another smart upgrade. Also, after all updates, i did 'apt-get clean`. Now I have the same problem as mentioned in the first post, but the proposed fix didn't work: after mounting the / and /boot partitions for my ubuntu (which lives in an external usb disk) using a live cd, chroot'd and did dpkg --configure -a, with no effect (seemed to do nothing). After that, I did dpkg-reconfigure udev, with the following output:

root@ubuntu:/# sudo dpkg-reconfigure udev
sudo: unable to resolve host ubuntu
sh: cannot create /dev/null: Permission denied
sh: cannot create /dev/null: Permission denied
grep: /proc/self/status: No such file or directory
Cannot find /proc/version - is /proc mounted?
invoke-rc.d: ----------------------------------------------------
invoke-rc.d: WARNING: invoke-rc.d called during shutdown sequence
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: ----------------------------------------------------
/usr/sbin/invoke-rc.d: 339: cannot create /dev/null: Permission denied
xargs: `/dev/null': Permission denied
/usr/sbin/invoke-rc.d: 339: cannot create /dev/null: Permission denied
xargs: `/dev/null': Permission denied
/usr/sbin/invoke-rc.d: 339: cannot create /dev/null: Permission denied
xargs: `/dev/null': Permission denied
Kernel uevent sequence number not available, cowardly not restarting udev
No diversion `local diversion of /sbin/udevadm to /sbin/udevadm.upgrade', none removed
update-initramfs: Generating /boot/initrd.img-2.6.28-6-386
/usr/sbin/mkinitramfs: 221: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 221: cannot create /dev/null: Permission denied
[repeated many times]
/usr/sbin/mkinitramfs: 221: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 221: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 230: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 230: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 248: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 248: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 255: /usr/sbin/mkinitramfs: 255: cannot create /dev/null: Permission denied
cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 282: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 282: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 285: /usr/sbin/mkinitramfs: 285: cannot create /dev/null: Permission denied
cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 286: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 286: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 287: cannot create /dev/null: Permission denied
/usr/sbin/mkinitramfs: 287: cannot create /dev/null: Permission denied
/usr/share/initramfs-tools/hooks/brltty: 20: cannot create /dev/null: Permission denied
/usr/share/initramfs-tools/hooks/brltty: 20: cannot create /dev/null: Permission denied
/usr/share/initramfs-tools/hooks/brltty: 22: cannot create /dev/null: P...

[Skewray (ubuntu-skewray)]

My fix was to run "dpkg-reconfigure udev" (which recreates /sbin/udevadm) and then rerun mkinitramfs.

[BjornW (bjornw)]

I've seem to have run into the same problem described here with updating my samsung nc10 to the latest version of Jaunty. The proposed solutions did not solve this problem.

[Tobias Bradtke (webwurst)]

I seem to have a similar setup to 'mjhorsnell' (Ubuntu Studio Jaunty).
When I execute "$ sudo dpkg-reconfigure udev" /sbin/udevadm will be deleted.
After doing "$ sudo aptitude reinstall udev" it shows up again.

So for me the fix was to run "aptitude reinstall udev" and then "update-initramfs -u -k all".

[Quentin Stafford-Fraser (quentinsf)]

Many thanks, all -

Tobias's suggestion brought my world back too.

It's a bit scary just how far we still are from having a system suitable for normal users :-(

[c_ellesley (archelegraph)]

I ran into the same problem with karmic-beta
after update to kernel 2.6.31-14.47 (2.6.31-14.xx before)
the rt kernel 2.6.31-9.152 (newly installed with the same update) boots

I guess "sudo update-initramfs -u -k VERSION" would be the fix but i hope update to 2.6.31-14.48 will do that anyway

[donarntz (donarntz)]

I'm having this problem. I can't boot with the newest kernel. "udevadm trigger..." message. Karmic 64

[Jordan Reese (jordanmreese)]

i had the same issue as the previous two posters, if i did sudo dpkg-reconfigure udev, it only updated the -9-rt kernel, and not the -14-generic kernel, i fixed it by running:

sudo dpkg-reconfigure udev
sudo update-initramfs -u -k 2.6.31-14-generic

this fixed the problem, so i beleve that udev is not configured to reconfigure the initramfs on the new kernels.

[Goky (goran-jakovljevic)]

Had same problem upgrading from ubuntu 8 to ubuntu 9.10. I managed to boot the system using alternative kernel image selection from GRUB boot. (Generic kernel boots ok, while pae karnel had issues describe at the beginning).

Hope this helps - since this way there was no need to download live CD....

[Otshelnik (otshelnik)]

Had some problem in ubuntu 9.10 after "apt-get update" when kernel package was updated to 2.6.31-17.55~ppa7 version. I was boot old kernel, installed on my laptop and fixed it with that commands:

sudo dpkg-reconfigure udev
sudo dpkg-reconfigure linux-image-2.6.31.17-generic

[jimmy the saint (lowid95)]

Same issue on a Karmic Fresh install. Ran the updates, restarted as prompted and was left with an unbootable kernel.

My solution was to simply boot into the older kernele and run

"sudo dpkg --configure -a"

[Sfinx (lieven-leuridan)]

I was most displeased to experience the exact same problem as described by Jimmy above. May be worth mentioning I also tried to update my video drivers while the update process was ongoing and had to cancel it due to an error (I figured it was because I was already running an upgrade window)

I tried the solution described in the bug description but to no avail (errors all over trying to update) so I reinstalled my Ubuntu, the problem didn't reoccur.

[Rubén Darío Ponticelli (rdponticelli)]

I had the same problem with lucid. Shouldn't plymouth and lvm2 also depends on initramfs-tools? This is the output of the script:

bcmwl-kernel-source
fuse-utils
lvm2
plymouth-theme-fade-in
plymouth-theme-kubuntu-logo

[Steve Langasek (vorlon)]

ok, opening new tasks for the affected packages.

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.2-1

---------------
plymouth (0.8.2-1) lucid; urgency=low

  [ Steve Langasek ]
  * New upstream release.
  * debian/plymouth.plymouth-stop.upstart: trust the new kdm to stop plymouth
    for us, too. LP: #540177.
  * plymouth needs to depend on initramfs-tools to avoid calling
    update-initramfs when the stack isn't configured yet and rendering the
    system unbootable with a broken initramfs. LP: #358654.
  * src/client/ply-boot-client.c: ply_boot_client_flush() needs to process
    the incoming queue before the outgoing, otherwise we get a deadlock.
    LP: #554737.
  * src/plugins/splash/script/script-lib-image.c: call script_obj_is_null()
    to check for the presence of the alpha argument, otherwise all our labels
    are rendered invisibly...
  * src/plugins/renderers/drm/plugin.c: temporarily disable the drm backend
    for nouveau, until we can get to the bottom of the DRM lockup in bug
    #539655. This is not as pretty, but it boots to the desktop without
    hanging regardless of how many displays are used, and that takes
    precedence. LP: #533135.

  [ Scott James Remnant ]
  * Implement a Window.GetBitsPerPixel() function in the script library,
    and the necessary support in ply_pixel_display, ply_renderer and in
    the vga16fb and frame-buffer renderers to make that information
    available. This will return "0" on drm and x11 where the answer is
    "lots". LP: #558352.
  * Modify vga16fb to only fallback to reducing colors if it's overflowed
    the 16-color palette already, so if you stick to the same 16 colors,
    you can get exact matches.
  * Use alternate 16-color images when we have only 4bpp. LP: #551013.

  [ Alberto Milone ]
  * ubuntu-logo: accept a format string from mountall for the disk check
    progress, so that localization is possible. LP: #553954.
 -- Steve Langasek <email address hidden> Thu, 15 Apr 2010 00:55:46 +0000

[Kees Cook (kees)]

I think this is not an issue for lvm2, as it depends on dmsetup, which depends on initramfs-tools. Or does apt try to get sneaky, and we need a direct depend on initramfs-tools in lvm2 as well?

[Darryl Meganoski (zodiacdm)]

Just got this bug from updating to lucid-proposed.

Had to use the old image and check synaptic's history find what packages caused the problem.

Rolling back the uDev packages did nothing, though once I rolled back the linux-image and linux-headers pakages, everything is fine again.

[Aymeric Mansoux (aymeric)]

Same here.

We got this one on a machine after a fresh update from lucid-proposed. None of the usual workaround (reconfiguring, reinstalling udev) fixed the situation. Only a complete rebuild of the initramfs images did the trick.

- chroot in your broken install from a liveUSB/CD
- sudo update-initramfs -u -k
- reboot

All sorted. It was a pain to narrow it done as it first seemed to be an LVM or disk issue, but no.

[Graham Ranger (graham-ranger)]

The solution given at the top appears to have worked for me. Many thanks for the help!

[bandini (jphilippe-francois)]

System broken after update !
sudo update-initramfs -u -k 2.6.32-24-generic restored a working boot.

Why don't you save the previous kernel + initramfs when updating image ? I am glad I had another working kernel + initramfs.

How are you supposed to even find this page if you are not an experienced user ? A broken system after an update is a very bad bug IMO. Please find attached the dpkg.log file.

[LL Phillips (lilo-phillips)]

this happened to me after I left the room while the update was proceeding. I did not see any error messages upon return and rebooted. It is the first time Update manager has failed me. I am not an experienced user. I do have the Live 64 bit CD. Could someone please post the exact code I would have to type to follow Amyeric's directions. Thanks

[R (Chandra) Chandrasekhar (chandra)]

LL Phillips: You might want to see

http://ubuntuforums.org/showpost.php?p=9796852&postcount=10

 for StewartM's step-by-step solution if you have previous kernel images that you can reboot from.

If you do not have a previously working kernel, you might have to do what Andrux101 has suggested at

http://ohioloco.ubuntuforums.org/showpost.php?p=8079302&postcount=12

and what Aymeric Mansoux has also suggested above. Be sure to prepend sudo to the relevant commands.

In any case, here is what I did:

1. Boot from Live CD. Go into console mode [Ctrl-Alt-F1] or fire up a terminal.

2. sudo mkdir /media/newroot

3. sudo mount /dev/sda1 /media/newroot

(My root partition is at /dev/sda1; change /dev/sda1 to suit your case.)

4. sudo chroot /media/newroot

5. sudo update-initramfs -u -k all

(the "all" argument is a bit of bravado since I did not know what exactly it would do. If in doubt, try "2.6.32-24-generic" instead of "all".)

6. Reboot without Live CD.

It is a great shame that this bug has resurfaced after a kernel image update.

FWIW, my most recent kernels are:

2.6.32-24-generic

and

2.6.32-24-preempt

in case it is one and not the other theta has triggered this problem.

I appeal for an early closure of this problem. Thanks.

[LL Phillips (lilo-phillips)]

Chandra, I followed your directions to the letter and my main machine is now running and even has today's updates done. Thank you so much I must now do my second machine as I held off on its updates til I could successfully get at least one machine in the house able to get onto the internet. I surely hope this bug does not happen to every single machine when it updates as my sister will be in a panic. I set her up with a 32 bit version of Ubuntu 10.04 Both my machines are 64 bit. Thanks again

[sam (samazon)]

Just discovered this issue with 32 bit 10.04 LTS (upgraded from 8.04 LTS in Aug) (20100908). Boot stopped exactly as described in bug description. System normally runs for weeks at a time without reboot, and several upgrades/changes/new programs were applied before restarting--unfortunately not well recorded or defined. Therefore, I don't have good info on what may have caused it.

To fix the problem, followed Chandra's instructions exactly. Booted from Live 10.04 CD and opened a terminal window. May be useful to note that update-initramfs took a relatively long time to complete on my system (probably due to many older kernels still around). Restarting system after following the instructions exactly resulted in a good boot from default (top) kernel.

Thank You!

[Andres Muniz (andresmp)]

Just happend to me with my Aspire one netbook. I was running Ubuntu netbook edition also updating. Will try to do the live cd recovery proposed.
Agree with a coment above: what if it is your only PC? pretty bad stuff to happen on an update.

There is Busybox 1.13.3.... anything that can be done with that?

[Andres Muniz (andresmp)]

forgot to add it was on the LTS and I keep it updated on a mothly (if not weekly) basis. Thought it had to do with my 16GB USB left in.
More hardware notes: it is an aspire one with SSD.

[Andres Muniz (andresmp)]

Tried what was shown in post: http://ubuntuforums.org/showpost.php?p=9796852&postcount=10

I could load grub and load a previous kernel but after running the comands (2.6.32-24-generic
 or 2.6.32-23-generic) it still comes up with the same bootup problem.

Seems there is no need for liveCD as I do have previous kernels...?
I'll wait for an update.

[Skip VerDuin (verduin)]

I seem to be living in a "house of cards" here... I began 3 days ago with this bug but made the not-so-good choice to work backwards starting from the end "... does not exist" message -- see question #125176. My twist is to find /dev/sdb partition table garbled-or-missing. Today I fail to boot a newly downloaded live 10.04.1 to apply the fix above #31 by Chandra [specifically it seems to begin booting then fail prior to any message]. None of the previous boot options function from the grub menu on HD. PXE boot options also yield different [than a week ago] results from various OS choices. In short -- 3 days of no joy...

Summary:
The machine is a white box - 32bit workstation built on a dual-AMD server mobo. The file system is built on 2 SATA drives in BIOS RAID 0 & LVM. It was assembled a year ago and Fedora 12 was the OS. Three months ago the ubuntu 10.04 LTS was added via network install option in a new LV for dual-boot purposes - dual boot was soon abandon and only 10.04 ran 24-7. The boot failure on 9/11 following safe-upgrade is the first problem encountered. It's a killer.

I now view my problem as one of finding a successful live OS option to apply a Chandra-like fix. What makes my system so vulnerable remains a mystery to me. I expect to run out of options [patience(?)] after a couple more days and resort to re-install. In the mean time I'll provide anything that might be helpful to others...

[Dmik (dmik-for-maillists)]

Just got exactly the same problem after installing the batch of updates (accumulated for the 10 days of my absence) through Update Manager that included the latest generic kernel update. Only could solve this by running

  sudo update-initramfs -u -k 2.6.32-24-generic

while booting another kernel that was luckily installed along on the same machine and was not touched by the update. (Credits go to Audi200Q that published the solution at http://ubuntuforums.org/showthread.php?t=1567147).

I think this bug should be marked as Critical as it's definitely impossible for a non-geek person to solve it on his(er) own which makes their computer completely unusable until an Ubuntu expert with a boot CD is found.

[Skip VerDuin (verduin)]

The posted solution does work on this instance of 10.04 LTS Desktop. The "house of cards?
1) Beginning the bug killing at the bottom -- answers #125176 was a false start and not necessary ["fsck -f" cleaned up /boot filesystem after #4) below].
2) Access to former rev 2.6.32-23 in /boot failed -- unknown reason at this moment.
3) Access to live Ubuntu problematic --
3.a) boot from catalog of OS revs via PXE failed -- unknown reason
3.b) boot from 10.04.1 Desktop on CD frequently failed -- CD/DVD & BIOS hdwr problem to identify CD as "bootable media"
4) support for LVM not std for live OS -- need to install lvm2 per linuxwave at:
     http://linuxwave.blogspot.com/2007/11/mounting-lvm-disk-using-ubuntu-livecd.html
5) partial solution using update-initramfs failed -- no improvement
Full solution posted above under "The solution is..." using live OS, install lvm2, and "dpkg --configure" does work around this bug.

I do agree this bug is not for the "faint-of-heart" crowd. Fixing the bug and moving it into distribution quickly seems important. I do wonder what is unique to my configuration that initiated this bug, and why a 9.04 bug gets into 10.04 a year(+) later. Without launchpad [and linuxwave?] this host needed re-installation from scratch -->THANKS to the many posts for saving my install!

[Torsten (thpost)]

I installed Ubuntu 10.04.1 on a 64-bit machine. There is a fake-raid configuration on my machine. All went well until I tried to update my system. I run into the following error: "kernel panic unable to mount root fs on unknown-block". Nothing helped but re-installing my system. After re-installation and update my system again I got "udevadm trigger is not permitted while udev is unconfigured" and I found this thread. Thx for the solution (update-initramfs -u -k all fixed it)! btw: If you were on Windows and it would crash your whole system after a regular update, what would you say ...?

[Hieratical (trainerjonathan)]

Hi there. I just had this issue when updating my 10.10 UNE install. So it should be marked for Meerkat as well.

I fixed it using the sequence below:
sudo -i

# create a target mount point
mkdir /mnt/target

# mount root
mount /dev/sda5 /mnt/target

# into Meerkat
chroot /mnt/target/

# update
dpkg --configure -a

# done
reboot

which is basically the sequence found in this post: http://ubuntuforums.org/showpost.php?p=8079302&postcount=12

[Andy_vso (a-schofield)]

I have just encountered this problem too.
I am running Kubuntu 10.04 on VMWare Player 3.1.2 on a Windows XP Pro machine. Kubuntu performed the updates and then I got the udevadm trigger... report.
I am facing issues with the various suggestions here and elsewhere though.
After the udevadm trigger message it drops to the initramfs command line
ls /boot simply says no such directory
I have the kubuntu iso mounted within the VMWare player however, when rebooting the Kubuntu VM, there is no repsonse to the F2 or ESC key so it passes straight through to the udevadm trigger message everytime (the VMWare restart screen does appear for a second or so with the message at the bottom re F2 for SETUP, F12 etc. ESC for Boot Menu).
I'm a little stuck as to ideas as I'd rather not lose that Kubuntu VM setup.

Cheers
Andy

[Thomas Ibbotson (thomas-ibbotson)]

I also had this problem. The solution was to stop grub from using UUIDs. For me using Grub 2 this meant editing /etc/default/grub and setting "GRUB_DISABLE_LINUX_UUID=true". Unfortunately this does not fix the core problem, but it does at least allow you to boot.

[Aidan Skinner (aidan-skinner)]

Just installed ubuntu 10.10, installed the nvidia driver and updated everything, first reboot and hit this.

Mounted / on /mnt using busybox, chrooted /mnt, started /bin/bash and then did update-initramfs -a -k <latest installed kernel> which fixed it.

but SEEESH. Really? REALLY? This should be a can't-happen kind of scenario, or at least a "this is easy to recover from". Not "drop to shell, run magic commands"

[linas (linasvepstas)]

Me too .. dkpg --configure -a fails because udisks wants to run "udevadm trigger" which fails. dpkg-reconfigure udev works fine ...

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in dianosing the problem. From a terminal window please run:

apport-collect 358654

and then change the status of the bug back to 'New'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lvm2 - 2.02.88-2ubuntu1

---------------
lvm2 (2.02.88-2ubuntu1) quantal; urgency=low

  * Merge from Debian unstable (LP: #726677), remaining changes:
    - debian/patches/avoid-dev-block.patch: Prefer any other device name over
      names in /dev/block/ since lvm.conf won't handle this.
    - debian/rules:
      - copy .po file to .pot file for Rosetta (Ubuntu specific).
    - debian/{dmsetup,lvm2}-udeb.install:
      - install initramfs and udev hooks in udebs (Debian bug 504341).
    - auto-start VGs as their PVs are discovered (Ubuntu specific):
      - add debian/tree/lvm2/lib/udev/rules.d/85-lvm2.rules: use watershed plus
        the sledgehammer of vgscan/vgchange to turn on VGs as they come online.
      - debian/tree/lvm2/usr/share/initramfs-tools/scripts/hooks/lvm2:
        - add 85-lvm2.rules to the list of udev rules to copy.
        - depend on udev.
      - debian/control:
        - add versioned Depend on watershed in lvm2 for udev rules.
        - add versioned Depend/Breaks on udev in dmsetup for udev rules.
        - add Depend on initramfs-tools in dmsetup so system is not potentially
          rendered unbootable by out-of-order dpkg configuration. LP: #358654.
      - debian/rules:
        - do not install local-top scripts since Ubuntu mounts root using udev.
        - do not install init scripts for lvm2, since udev starts LVM.
      - debian/lvm2.postinst: handle missing lvm2 init script.
      - debian/tree/dmsetup/lib/udev/rules.d/60-persistent-storage-dm.rules:
        watch dm devices for changes with inotify
    - add mountroot failure hooks to help fix bad boots (Debian bug 468115):
      - debian/tree/lvm2/usr/share/initramfs-tools/scripts/init-premount/lvm2
    - add packages for upstream event manager (Debian bug 514706):
      - debian/control: define libdevmapper-event1.02.1 and dmeventd packages.
      - debian/rules:
        - enable dmeventd during configure.
        - add build targets.
        - fix shlibs invocation with a cleared DH_OPTIONS to get udeb shlibs.
      - debian/dmeventd.{install,8,manpages}: install dmeventd files.
      - debian/libdevmapper-event*.{install,symbols}: install dmeventd files.
      - debian/libdevmapper-dev.install: install libdevmapper-event files.
      - debian/patches/monitoring-default-off.patch: by default, do not
        expect to talk to dmeventd. Monitoring can be done via "--monitor y".
    - rename debian/clvm.defaults to debian/clvm.default so it is intalled
      correctly.
    - debian/control: add dmsetup-udeb to libdevmapper1.02.1-udeb recommends.
    - lidevmapper-dev: move .so symlinks to /usr/lib where they belong
    - debian/patches/rules-subdir.patch: removed as reordering will cause
      build failure with dmeventd.
    - debian/patches/libdm-event-static.patch: removed as other static libs
      aren't being built anymore either.
    - debian/rules: make sure dmsetup and lvm2 initramfs-tools scripts are
      executable. When the Ubuntu-specific ones are added with a patch,
      they may lose their executable bit.
    - Add and install clvmd resource agent
    - Add dependency on libudev-dev to libdevmapper-...

[John T Gowing (jgowing)]

I experienced the same issue on Mint 17.1 Cinnamon 64 after a power failure during an update run.
Your methodology of booting a live cd, mounting the partitions, chroot, and complete the updates worked for me and I was able to recover my system.

I posted my experience on the Mint forums here:-
http://forums.linuxmint.com/viewtopic.php?f=46&t=196408