Udev is looping, retrying the same operation

This is probably connected to an evms bug that's in the 2.6.22 kernel; it bit me too. When I removed the evms package, the problem went away.

Let's see... (launchpad search is terrible) it was #115616 where I read about it.

Removed the following packages:

evms evms-ncurses libevms-2.5

Problem all gone.

I think upgrade process said it would remove evms after the upgrade. The fact that this wasn't done is probably either a bug in the upgrade package, intentional since we're still in pre-release, or just me having finger troubles.

I got the same error, just as described. Will try evms removal and report later. Here's my output from lspci:

00:00.0 Host bridge: Intel Corporation 82850 850 (Tehama) Chipset Host Bridge (MCH) (rev 02)
00:01.0 PCI bridge: Intel Corporation 82850 850 (Tehama) Chipset AGP Bridge (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 04)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 04)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev 04)
00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 04)
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 04)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 04)
01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 15)
02:0a.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801] (rev b1)
02:0a.1 Gameport controller: Fortemedia, Inc Xwave QS3000A [FM801 game port] (rev b1)
02:0b.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 31)

Looks like a subset from bug #115616. BTW I removed evms and problem is solved.

evms (2.5.5-26ubuntu1) gutsy; urgency=low

  * Merge from debian unstable, remaining changes:
    - call evms_activate from a udev rule when appropriate block devices
      are detected.
    - ubuntu maintainer address
  * debian/patches/99-suse-dos_plugin_activation.patch:
    - Patch taken from SuSE evms-2.5.5-173.src.rpm that is believed to
      alleviate bd_claim issues. LP: #109320, #115616, #144200.

evms (2.5.5-26) unstable; urgency=low

  * Use "[ ! -f Makefile ] || make clean" instead of "-make clean"; fixes a
    lintian error, and is in general more sane.
  * Remove spurious close line from the 2.2.1-2 changelog; makes lintian
    happier.
  * Remove debian/patches/disk_cache.patch, which is a leftover file from
    importing 15-disk_cache.patch.
  * 16-fix_manpage_warnings.patch: Escape latin-1 characters in hex dump (!)
    in the evms_restore_metadata(8) man page; fixes warnings from man.
  * 17-update_autotools_helpers.patch: Update config.{sub,guess} with the
    latest versions from autotools-dev; we haven't received any reports of
    failures with the old files (most likely since EVMS is Linux-only), but it
    is a good idea nevertheless.
  * Add LSB init header and status targets to the init script.

evms (2.5.5-25) unstable; urgency=low

  * disk_cache.patch: New patch from upstream, fixes an issue with the wrong
    key being used in an internal cache.
  * Drop Enhances on obsolete packages initrd-tools and devfsd.
  * Fix Replaces by evms-ha, which in the last version was inadvertedly on -24
    instead of -23 as it should be.
  * Use ${binary:Version} instead of ${Source-Version} in dependency from
    libevms-dev on libevms-2.5, which should make the package binNMU-safe.
  * Update Standards-Version to 3.7.2.0 (no changes needed).
  * Remove obsolete files debian/evms.mkinitrd.probe and debian/evms.devfs,
    and references to them in debian/rules.

evms (2.5.5-24) unstable; urgency=low

  * Partial resync with Ubuntu.
    * Update initramfs when EVMS is removed or purged.
  * Fix file list in evms-ha.install; the new plugin is named hb2, not ha2.
    Also change ha -> hb2 in debian/rules. This fixes issues where EVMS would
    complain that the hb2 plugin couldn't be loaded (since the plugin ended up
    in the main package, and the dependency was from evms-ha).
  * Make evms-ha replace libevms-2.5 (= 2.5.5-23), as the hb2 plugin is
    moving.
  * Update debian/evms.mkinitrd.probe to read "hb2" instead of "ha".

evms (2.5.5-23) unstable; urgency=low

  * Update HA plugin to heartbeat2, as it is now the default in the archive:
    * Build-depend on heartbeat-dev (>= 2.0.8-7) (ie. bump version). Also
      depend on libltdl3-dev, as it seems to be required for detection of
      heartbeat2 by configure.
    * Build-depend on libglib2.0-dev instead of libglib1.2-dev, as the HA2
      plugin requires glib 2.x.
    * Give --disable-ha --enable-hb2 to configure, as the ha and hb2 plugins
      cannot both be built.
    * Update plugin names in debian/evms-ha.install.
    * This also fixes a FTBFS issue where heartbeat-dev would bring in a
      different version of glib from what configure expected, leading to
      no...

I reinstalled evms-2.5.5-26ubuntu1 to see if my system would behave better now. I'd say it was worse, as this made my system crash to a shell during boot, when trying to fsck the filesystem used for /home.

Hitting ctrl-d made the system boot (but with no /home) to a state where I could uninstall evms. This restored functional booting again.

Screenshot attached. The hard-to-read part under the orange reflection is "/dev/sda6".

Øystein Viggen: you are actually seeing somewhat intended behaviour there :-)

The upload fixes evms so that it works for those people who actually want to use evms. Those people will put /dev/mapper/sdXY paths in their fstab, etc. to force its use.

The problem you're seeing is that evms has "claimed" /dev/sda6 for its own, and you therefore can't fsck it -- you'd have to put /dev/mapper/sda6 in your fstab instead.

This is perfectly normal for evms :-(

I suppose some debconf question/warning and an /etc/default/evms could be an easy solution to this intended behaviour. A simple package install breaking booting by default sounds harmful.

A better solution might be to expand evms to have a look in /etc/fstab to figure out which devices it should stay away from and which it can "claim", a lot like how NetworkManager checks /etc/network/interfaces to see which network interfaces to control. This could be a suggestion for upstream, if there still is one..

Having learned not to install evms unless I'm going to use it, I no longer care deeply about this issue :)