Device-mapper errors: dm-linear, lookup failed

Please don't confirm. There's still no evidence that this is a kernel bug. It could very well be a udev bug.

Googling this reveals the following which may (or may not) be relevant:

http://evms.sourceforge.net/faq.html (see the Volume Activation section)

Definitely, we used to carry the bd_claim patch, but after review, we've decided not to include it anymore because of the more important problems it allows.

This link explains how to correctly use evms with stock kernels.

http://evms.sourceforge.net/install/kernel.html#bdclaim

Is evms not installed by default? If it is will not the error that I am seeing trip up other users as well?
I don't recall ever installing evms optionally.
Just trying to understand how this issue may effect the run of the mill user.....
I will filp the off switch in /etc/evms.conf as suggested and see whether this is the problem for sure...

Confirmed that this appears to be the problem. If I exclude all devices lin the sysfs_devices section of /etc/evms.conf then the problem disappears.

As mentioned above I am a bit concerned how many other users may hit this snag if evms has been installed "without their knowledge" so to speak........

Kyle is looking into what we can do to properly handle this.

Scott is uploading an evms package with a fix pulled from SuSe.

In case that's not obvious from the above, "aptitude remove evms" gets rid of the problem. I suppose if you don't know what evms is, then you're probably not using it (unless someone else configured your system; you should ask them then).

Just upgrading to gutsy and have the same issue. Kernel log is full of messages:

[ 2860.300000] device-mapper: ioctl: error adding target to table
[ 2860.300000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed

root@orion:~# ps aux | grep udev
root 2669 56.8 6.7 27476 25852 ? S<s 19:15 31:23 /sbin/udevd --daemon
root 21697 0.0 6.7 27608 25944 ? S< 20:10 0:00 /sbin/udevd --daemon
root 21699 0.0 0.1 2020 588 ? S< 20:10 0:00 /lib/udev/watershed /sbin/evms_activate

Please note, that the /sbin/evms_activate process and one udevd show up then hide again and again (with different pid). udevd process with pid 2669 eats all idle CPU according to top.

I have removed evms (and then reboot) to 'fix' this issue since I don't need evms.

I have the same problem and I use evms... I could not boot to 2.6.22 kernel :-(, but I can boot to 2.6.20. Do you have a workaround for the problem?

SergeyS , as reported in one of the duplicates, removing evms should fix the problem (at least waiting for a proper solution).

As a work around, excluding any devices which are mounted externally to evms in sysfs_devices section of /etc/evms.conf works fine and allows the continuing use of evms to manage devices which are not otherwise mounted.

I guess this only works if you are using entirely separate disks in evms.

I had the same problem. The udevd was using lot of CPU and writing the same messages over and over again to kernel.log. Stopping and starting udevd again worked for the session, but it started doing the same thing again after a reboot. Removing evms fixed the thing also between reboots.

(Kernel: 2.6.22-7-386 #1 Mon Jun 25 16:30:18 GMT 2007 i686 GNU/Linux)

Bump.

I saw this also. My laptop would never finish booting after I upgraded to gutsy, with said messages on console. Could boot with an old kernel, and removing evms "fixed" the problem.

I have also the same problem, so i have just removed evms, thanks for the quicky fix.

I also had this and removed evms to fix, on amd64 gutsy.

I saw the same thing today when upgraded from feisty. Removing evms fixed it. The CPU usage of udevd made my T23 almost unusable which could be a real problem when trying to fix it.

Gutsy with yesterday's dist-upgrades is showing the same error. I eventually get a login screen, but entry of name and pass return me to login screen [CTRL] [Alt] [F1] shows me a continually incrementing list
[ 320.xxxxxx] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed.
I never get a log-in to see if I even have evms.

Dell c600 laptop

I can confirm this is happening on gutsy (yesterdays dist-upgrade).

Removing evms also seemed to make the messages go away.

Wolf, press CTRL-ALT F1 to get a terminal.

on /etc/evms.conf in sysfs_devices added :

exclude = [ * ]

and got fixed

_______________
on /etc/evms.conf in sysfs_devices added :

exclude = [ * ]
_______________

This fix worked for me, but is it correct? Will it break things in the future???

here with kubuntu feisty and kernel 2.6.20-16 no problem, compiled by myself kernel 2.6.22.5 and same message error.
Tried Leonel changes and it worked, however don't know what happens whit this.

Also had this problem with Gutsy alpha 5. I had evms installed (along with evms-ncurses). No idea how, when or why.

I've been killing and restarting this process manually. I hope this clears up the problem as it has for others. Thanks for the tip.

This cured two bugs! My second slave drive was not mounting, and now it does.

I upgraded from feisty yesterday afternoon, I had the same problem. A "sudo apt-get --purge remove evms" solved the problem for me

I applied the fix to /etc/evms.conf and stopped and then started (restart hung) both evms and udev .

its all fixed now , lets push this out to the repos.

the solutions is already provided by link provided by Richard Kleeman:

from:
http://evms.sourceforge.net/install/kernel.html#bdclaim

The end result is that a single disk cannot be used both for EVMS and for mounting the kernel's built-in partitions.

There are three solutions to this problem.

    * Switch to using EVMS for ALL your volumes and partitions. If none of the kernel's built-in partitions are mounted, then there won't be any conflicts when DM tries to claim the disks. This is, of course, the preferred solution, but also requires some extra work on your part to convert to mounting your root filesystem using an EVMS volume. Please see the Root-Volume section of this install guide as well as the Converting-To-EVMS guide for more details on this option.

    * Tell EVMS to exclude any disks that contain partitions that you are going to mount using the kernel's built-in partitions. You can do this by adding the names of these disks to the sysfs_devices.exclude line in your /etc/evms.conf file. If you choose this option, EVMS will completely ignore the specified disks and not discover any of the partitions or volumes on those disks.

    * Apply this patch, which will is a reversal of the patch that prevents Device-Mapper and the kernel's built-in partitions from using the same disk at the same time. This patch is not supported by the kernel community, and in fact removes functionality that they specifically added. However, it will allow you to share your disks between EVMS and the kernel's built-in partitioning code, if that's the choice you wish to make for your system.

      patch -p1 < /usr/src/evms-2.5.5/kernel/2.6/bd-claim.patch

This issue does not exist on 2.4 kernels.

I had the same problem after upgrading to Gusty. dmesg was full of nothing but:

device-mapper: ioctl: error adding target to table
device-mapper: table: 254:1: linear: dm-linear: Device lookup failed

And udevd was using 70%CPU!

Removing all *evms* pakages fixed the problem. Hopefully the developers will fix this before Gusty finally comes out. I would suggest some sort of check/clean-up script in update-manager should be made to disable EVMS.

The latest `update-manager -d` from Feisty is now prompting to remove the evms packages, but they are not completely removed, so the user must still manually remove the evms packages.

I also did an upgrade from Feisty today, and I also encountered a flood of these:

Sep 18 13:40:24 lapedb kernel: [ 178.476000] device-mapper: ioctl: error adding target to table

(my nvidia module wasn't loaded so my machine got stuck in textmode spawning this message)

So I ssh'ed to it, killed udev, removed emvs, rebooted and everything was fine.

Same here upon dist-upgrade to Gutsy. Nothing new to add, though; my experience was a combination of the above.

Killing udevd and uninstalling evm worked for me.

Same here (using linux-image-2.6.22-12-generic/gutsy uptodate 2.6.22-12.36).

Same for me. Booting 2.6.20, fixing NVIDIA driver, finding this bug report and removing evms worked for me. Actually I upgraded only with the console. I hope this problem will be fixed for the friends of aptitude dist-upgrade, too.

I have the same , kernel 2.6.22-12-386. udevd get 76% CPU. Gutsy.

Sep 28 22:53:15 localhost kernel: [ 763.952000] device-mapper: table: 254:0: linear: dm-linear: Device lookup failed
Sep 28 22:53:15 localhost kernel: [ 763.952000] device-mapper: ioctl: error adding target to table

<-- error in infinite loop

Linux 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux

I don't use evms, so I'll try to remove the package

Removing evms needs to be handled by the upgrade-manager.

I get this too, I installed gutsy (amd64 if it matters) and can't boot when I use the 2.6.22-12 kernel. When I try to boot normally the screen just goes black and sits there, when I boot in the safe mode I get the error message over and over until I restart the system:

device_mapper: table: 254:2 linear: dm-linear: device lookup failed

I'll try removing evms as others have mentioned.

I've had the same problem on Kubuntu Gutsy.

P.S. udevd is eating up 23% of system resource.

Look at bug #144200, closely related if not the same.

I also have this issue but would like to add one more thing: Compiz didn't run for me. Even manually enabling it I get an error saying Compiz can't start.

After removing evms last night, this morning when I tried enabling Compiz again, it worked fine this time. Normal & Extra visual effects work. I didn't test customising yet though.

i had the same problem, and removing emvs (i dont know why it was installed though) solved the problem. one thing: external drives are no longer automounted when plugged in at boot-time, i have to unplug and re-plug them in order to be mounted. this worked with evms installed.

Happened again when I updated my Laptop to Gutsy today. I had to remove evms. I don't understand why it was installed at all.

because evms is intalled by default

please try to don't spam this list :q

Sorry I did not want to spam. I just wanted to say that the problem occurred again on a second machine. I did not know that evms was a default package in a previous release. In that case the whole situation is even worse. I can imagine that most "normal" users will not be able to understand why their system is so slow and they won't find this bug and find the solution. They will blame Linux for beeing a bad system, etc. etc. So please fix this bug.

Martin now I think evms is removed from default packages, so if you have updated from a previous release you still have it (you have to manually remove it), if you install a fresh gutsy no, so I think bother anymore about this is useless.

the side effect about this is for example when you put a cd-rom then desktop icon in kubuntu isn't automatically added until you open the cd-rom from dolphin.

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...

This is not only an EVMS related bug. I currently use Device Mapper to access the host protected area of my laptop's HD. I can't create a partition for it (that makes my dual-booted Windows crash), but a linear devicemap can make this part accessable for linux. Ofcourse since there's now the limitation to not allow DM to access the disk used by the rootfs, I'm again stuck.

Removal of the "evms" package resolved the problem on my Samsung Q20.

so someone on Gutsy have tried new version of the package?

Yes. The new evms caused my laptop to fail to boot. LiveCD -> chroot
-> aptitude remove evms resolved the issue.

On 10/5/07, Cimmo <email address hidden> wrote:
> so someone on Gutsy have tried new version of the package?
>
> --
> Device-mapper errors: dm-linear, lookup failed
> https://bugs.launchpad.net/bugs/115616
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Another option, which I did, is to change the evms.conf's line "exclude [ ]" to "exclude [ * ]".

I have three such exclude lines in mine. Instructions above are just for sysfs_devices stanza? Yep, that change alone worked.

I hope this will actually be fixed for the Gutsy release. It's really bad. I appeared to be averaging over 80% CPU from this before I modified the evms.conf file. Things froze up all the time. BAAAAAAAAAD.

I had this problem when I first upgraded to Gutsy, then I removed "evms", and it went away.

Then we had an automatic upgrade come through, and it installed "evms-activate", and now I have the problem back. I can not remove or kill the evms-activate process, it's grayed out.

The only way to get my cpu usage back down, is to kill the udevd process. Not good. :)

The machine is a Toshiba R-15-S829 TABLET PC (convertible notebook). I'm running Gutsy 2.6.22-13-386 and Gnome 2.20.

Just to be clear...evms-activate is the only evms I have.

I have attached an archive of all of my logs. 01 is while running, and 02 is after I killed udevd. There are erros generated, most are permissions denied, but evms and udevd are there.

    * logs_both.tar.gz (22.2 MiB, application/x-tar)

This does not seem to be fixed, on gutsy beta I have the latest evms:

ii evms 2.5.5-26ubuntu1 Enterprise Volume Management System (core)
ii evms-ncurses 2.5.5-26ubuntu1 Enterprise Volume Management System (ncurses
ii libevms-2.5 2.5.5-26ubuntu1 Enterprise Volume Management System (library

And I get millions of messages in the logs, disk is spinning continuously and the laptop just feels very slow.

I added the exclude * line but still got some messages:

Oct 7 10:45:34 m kernel: [ 1366.108000] device-mapper: ioctl: error adding target to table
Oct 7 10:45:34 m last message repeated 9 times
Oct 7 10:45:34 m kernel: [ 1366.112000] device-mapper: ioctl: error adding target to table

I killed udev because it was still taking 100% cpu. Then

apt-get remove evms

Then reboot and all was fine.

After upgrading to from 7.04 to gutsy, I couldn't boot with 2.6.22-12 and -13. I only got repeated messages scrolling on the screen: 'device-mapper: table: 254:7: linear: dm-linear: Device lookup failed'.
2.6.20-16 booted fine.

After changing /etc/evms.conf (exclude = [ * ] in sections 'activate' and 'sysfs_devices') 2.6.22-13 booted now without problems and no problems with udev using too much cpu.

Got this one, too. In addition to flooding dmesg it also locked up my dvd-drive and prevented mounting my secondary HD. Tried also using vanilla kernel 2.6.23-rc9 but the same thing happened with that as well (not so surprising after reading the evms url above).

Removing evms magically fixed the issue.

I have a current install of Gutsy, and I am experiencing this same behaviour on a Compaq Presario 2190 Laptop.

stopping udevd stopped the flood of dmesg notices

removing evms stopped it all together.

Although, I'm sure this stuff was installed on purpose, I'm waiting for a proper solution..

Until then, my laptop us unusable with evms installed - as it causes 35-45% cpu usage constantly.

Cheers,
Darryl

Scott,
I am a bit concerned about this bug. The fix has been released (latest gutsy update of evms) but people with current gutsy are still reporting this as an issue. Should people check the version of evms and confirm the fix is not working?

On Mon, 2007-10-08 at 13:53 +0000, Richard Kleeman wrote:

> I am a bit concerned about this bug. The fix has been released (latest
> gutsy update of evms) but people with current gutsy are still
> reporting this as an issue. Should people check the version of evms
> and confirm the fix is not working?
>
Note that the changelog only says the patch is believed to fix the
issues.

The update manager prompts people to remove evms, so this only affects
people upgrading by other means or who deliberately chose to keep evms
installed.

(The latter is unwise, since it's apparently unmaintained now and
upstream have shown no inclination to make it work with the 2.6 kernel!)

Scott
--
Scott James Remnant
<email address hidden>

I used update-manager -d to update my system from 7.04 to 7.10 beta on the 3rd of Oct. The upgrade process asked me to confirm the deletion of a lot of packages what I did. Nevertheless evms was not removed and my system didn't boot with kernel 2.6.22-12 after the upgrade. Luckily 2.6.20-16 was also included in the grub menu and did allow me to boot my computer.

Hmmm here is the changelog entry for upgrade-manager

- mark evms as obsolete if it is not in use

10 July 2007

And it has switched from main to universe....(for fresh installs)

Wonder why this change didn't work for Manfred?

Scoot I did "update -d" from a fully up to date 7.04 system and agreed to all deletions, but evms was still there.

Please explain me something. AFAIK removing evms criples some functionality related to automounting - according to some comments in this (and related) bug report. If so, why removing evms is an accepted way of resolving this issue?

Just did an upgrade to gutsy from 7.04 (< 1 hour ago) and had the same problem. Removing evms fixed it.

Sorry, should have provided some additional info. I'm running amd64 and I used the update manager to perform the upgrade. I accepted all proposed changes in the update manager process. I don't know what evms is so I wouldn't have installed it manually (I have been doing upgrades since 6.06). I have run a few scripts to get wine working and codecs installed in the past - it's possible that they added it, but I wouldn't have thought it likely. Let me know if you need additional info.

przemjaskier,
As Scott previously mentioned, the evms project is no longer maintained and the patch they suggested does not seem to work for everyone if at all.

I did the on-line upgrade from Feisty to a Gutsy beta on an IBM T30 Laptop that I only use for web browsing. It displayed this problem straight away, very high CPU utilisation.

The resource tab of the System Monitor program charts CPU utilisation and made it obvious that CPU was being wasted somewhere but the process tab did not give any clue where. None of the displayed processes showed a high utilisation. COULD THIS BE ANOTHER BUG ?

I needed to use the "top" command to find the culprit udevd using 87% CPU.

The problem went away after doing:
sudo aptitude remove evms
and re-booting the PC.

Like Pat above, I have never heard of EVMS before so I assume it is a standard part of Gutsy. Having read the evms web site I am a little concerned that I no longer have it and I certainly have no plans to do the same upgrade on my desk top machine until I read encouraging noises about this bug.

Scott,

Sorry to be a pain but I am confused about this bug. It seems upgrades to Gutsy beta from Feisty are not removing evms. Will this change when the distro goes "live" i.e. will the changes of July 10 in update-manager which cause evms to be removed come into effect when the distro is released? Or should we still be worried about people's systems being flooded by all the messages discussed ;-)

I have just been hit by this bug upgrading my AMD64 desktop from Feisty to Gutsy. Booting the old kernel and using aptitude to remove the evms package then rebooting fixed the issue. My desktop started off running Dapper and has over time been dist-upgraded to each new version of Ubuntu. I have never explicitly installed EVMS (although I think its been installed since I originally put Dapper on the system). These is a pretty nasty bug to be hit by when you upgrade!

Based on the recent comments that the fix doesn't solve the problem, I'm reopening the bug since it seems to be a problem for those people who are not using update-manager to update.

However, worryingly, it also still seems to be a problem for those who *are* using update-manager. If the project is unmaintained, Is it not desirable to force evms to uninstall on every upgrade by conflicting or similar?

Matthew East , may be the common point for people having the problem is that their system has dist-upgraded multiple times to follow ubuntu version since dapper as opposed to a fresh edgy system going to gutsy. This is my case here since I've been dist-upgrading a few versions on this machine.

I did use "update -d" and I have never used or requested the install of evms (first evms related command on the system was the apt-get remove).

Interestingly my laptop started life with Edgy and has been dist-upgraded to Fiesty and then Gutsy using aptitude and hasn't suffered this issue at all! I used update-manager -d to upgrade my AMD64 desktop which did suffer the problem. As people are getting the problem with both apt and update-manager, perhaps the issue is only affecting systems that have been running Dapper at some point in the past?

You could be right - my systems started with 5.10 and they both had this problem during upgrade. A friend of mine who started with 6.10 did not have this problem during upgrade to gutsy. By the way for one system I used aptitude, for the other adept's update manager.

Un-milestoning and Un-assigning this bug.

evms is unsupported (and effectively unmaintained by upstream, who have not yet provided a version that actually works with the vanilla 2.6 kernel).

Our preferred solution is to ensure evms is removed on upgrade.

If evms never worked with the 2.6 kernel, then why did Dapper ship with it installed and enabled by default (I have just verified it was on the Dapper based desktop we have here at work). This upgrade bug appears to mainly be affecting people that ran dapper (or earlier) at some point in the past and is likely how we all involuntarily ended up with evms installed. Will update manager actually remove evms now when upgrading now? Cause it sure didn't remove it on my desktop last night when I upgraded, despite me agreeing to allow it to remove all unsupported packages!

I too have used update-manager -d for several Ubuntu versions in sequence. I did never actively install evms and was not aware of its existence. Only when the update to Gutsy left me with an unbootable system (with the latest 2.6.22 kernel, 2.6.20 allowed me to boot and fix the system). I can also confirm that evms remained installed despite me agreeing to the removal of all suggested packages.

I have added update-manager to the affected packages list since this *appears* to be a bug there. Any comment by this package maintainer greatly appreciated.

I wrote earlier that I suffered this bug when updating an IBM T30 laptop from Feisty to Gutsy. What I omitted to say was that this laptop had undergone a number of online updates prior to this one. I do not remember which version I started with but it has probably only had on-line updates since 6.06 or before.

The update-manager in beta did not have the rules to remove evms. It does currently, so this issue from an upgrade perspective should be fixed now.

ok may i sum ?

EVMS were previously installed by default on early Ubuntu version (anterior to Feisty)

This project is no longer installed by default
This project is no longer maintain by it author

This bug is fix, i guess that update-manager will ask you to remove EVMS since all unsupported packet are dropped in ubuntu
And published patch doesn't seems to work properly

Now wait for more news here and please stop spamming this list by describing the same bug described since may 2007!

Thanks all

Thanks Kees. That should solve this problem for nearly all users.

Gaëtan - you have it exactly right.

I've summed up the situation in more detail here: https://wiki.ubuntu.com/Evms

This hopefully explains why we've chosen to drop support for and remove evms, and what the underlying problem is that causes this bug.

I've also confirmed that updating from dapper *does* cause the removal of evms (see the screenshots on that wiki page), so I'm content that users upgrading to 7.10 will have evms removed unless they try hard not to (e.g. because they're using).

Since Update Manager has a task on this bug that's now marked Fixed Released, I've marked the EVMS task "won't fix" since we don't intend to fix the *actual* evms bug -- our preferred solution is to get it off your computers :-)

Okay let's sum this up. This problem occurs:

Quote:
May 19 10:10:16 richard-desktop kernel: [ 227.338011] device-mapper: table: 254:1: linear: dm-linear: Device lookup failed
 May 19 10:10:16 richard-desktop kernel: [ 227.338017] device-mapper: ioctl: error adding target to table

People point to EVMS being installed but this is only causing the problem to become visible, it's not the cause itself of the problem, and removing it only hides the symptoms.

As stated before, I cannot map an unallocated part (not part of any partition) of a disk anymore with dm-linear. This has nothing to do with EVMS at all, although it's exactly the same problem as being experienced with EVMS. The bug is located in the kernel! In use partitions should be locked, but why should a complete device be locked if only certain parts of it are used? This does not make sense.

I just upgraded from Feisty to Gutsy RC tonight, and I still ran into this problem. My system couldn't mount any of my partitions other than / (so no /home, etc.) and I was getting errors spewing to the log file and udev stealing tons of CPU. At first I ran /etc/init.d/udev stop to get back the CPU, but couldn't mount /home at all still. Then I rebooted with my 2.6.20 kernel and that worked but of course all my special KLMs like nvidia don't run anymore since they've been recompiled.

EVMS is installed on my system, but I never installed it myself nor do I use it nor do I even know what it is. This system has been upgraded starting with Breezy, I think; it definitely had Dapper on it. In addition to evms and evms-ncurses I had libevms installed. I don't know whether the upgrade offered to remove evms or not: it offered to remove a lot of things and I said "yes" and it successfully removed them all.

I've removed evms, evms-ncurses and libevms via synaptic and rebooted and now my system comes up OK.

But, contrary to the status of this bug as "fixed released", it's definitely not fixed in Gutsy RC1.

Jan: you are incorrect, evms is the cause of the errors you are seeing because it is repeatedly attempting to create devmapper devices for a block device already claimed.

It is correct behaviour that you cannot create devmapper block devices for an already claimed block device.

Just to follow up on Paul Smith's comment, I just (<2 hours) did a tidy-out of unused packages, cleaned/flushed package cache, a full update of 7.04 followed by update-manager -d and didn't intervene in any package removals. Same issue. This is not yet fixed as far as I can see. The fix listed in this bug remains effective, and the existing accounts here are 100% accurate to the issue I encountered.

Again, I'm another person who's upgraded multiple times from earlier distros. I've got a few more machines to go, so a fully working fix would be nice before release!

I can confirm that this is not yet fixed in update-manager on Feisty. I upgraded my main system to the Gutsy release candidate last night (using update-manager -d) and evms was not listed for removal. When the 2.6.22 kernel was booted this bug appeared with a vengeance preventing a boot. the 2.6.20 kernel was OK so I could solve the problem easily by manually removing evms. Is there an update to Feisty update-manager which does remove evms?

For the folks that still saw this problem during the RC upgrade, can you attach the output of "mount"? The only way I see that evms would be left out of the removal list is if "evms" is listed in your active mounts. (Additionally, I've been unable to reproduce this problem -- evms gets uninstalled in every test I've done.) I'd like to better understand how everyone's systems are different from the test systems I've built.

<Keybuk> mvo: installed feisty, made sure universe was enabled and installed evms
 upgraded to gutsy
 evms was *not* removed
<mvo> Keybuk: the reason that evms got not removed in your case was that you had packages depending on it and the upgrader is trying to be too clever. thanks for catching this, I'm preparing a update now

Here is mine (after apt-get removal of evms and reboot in gutsy):

/dev/sda5 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.22-14-generic/volatile type tmpfs (rw)
/dev/sda9 on /home type ext3 (rw)
/dev/sdb5 on /scratch type ext3 (rw)
/dev/sda10 on /test type ext3 (rw)
/dev/sda6 on /usr type ext3 (rw)
/dev/sda7 on /var type ext3 (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

The fix for this has been accepted for gutsy, with the following changelog:

update-manager (1:0.81) gutsy; urgency=low

  [ Jonathan Riddell ]
  * DistUpgrade/DistUpgradeViewKDE.py:
   - Add word wrap to quesiton dialogue

  [ Michael Vogt ]
  * DistUpgrade/DistUpgradeControler.py:
    - make the commercial archive transition more robust
    - when forcing the evms removal, ensure that all
      evms rdepends get obsoleted so that the safety checks
      in the upgrader do not kick in and prevent the removal
    - when calculating the size required in /boot take into account
      that installed initramfs images create a .bak file
  * updated list of demoted packages
  * updated ReleaseAnnouncement to include final text
  * updated demotions and mirrors to current gutsy

Just another follow up. Today, I upgraded to gutsy, from feisty, on a machine that has seen several upgrades in the past, and I still hit this bug. Removing evms fixes the problem, it seems.

On the plus side, wireless networking now works much better for my card:-)

Just another "me too".

Tried to upgrade using the GUI (suggested) method for Kubuntu 7.04, failed on debconf packages and never worked right since then. Ended up having to upgrade via sudo apt-get -f install and sudo apt-get dist-upgrade a couple times. Then it worked but upon reboot it gave the errors. Fix was to boot with 2.6.20 (thankfully I didn't remove that yet) and then to sudo apt-get remove evms. Now the newest 2.6.22-14 works fine.

I knew there was a problem when I said "Ok dear, it's all done. Just reboot and you can get back to your things" 3 mins later she comes storming out "You fix that or install ...." well the option she gave me hates freedom. So I choose to fix it.

Upgraded to Gutsy with `update-manager -d` on Monday 15th (two days ago) and I'm getting this. EVMS was not removed, but AFAIK I don't use it. I'm booting fine with my Feisty kernel. I've upgraded all the way from Breezy or Hoary, but I may have skipped a release somewhere (I know this is a BAD thing but I didn't know when I did it).

/dev/sda3 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda5 on /home type ext3 (rw)
/dev/sda1 on /media/sda1 type fuse (rw,nosuid,nodev,noatime,allow_other)
/dev/sda2 on /media/sda2 type vfat (rw)
/dev/sda7 on /var type ext2 (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

I upgraded from Feisty to Gutsy last night. As with the Dapper->Edgy->Feisty upgrade it didn't go entirely smoothly, but I soon got it to finish the job.
Then today I noticed that I can't mount one of my logical partitions (thankfully just a media storage partition) and this appears to the be the problem.

Seems this bug has been known for five months now and is evms is automatically installed during the upgrade process...?

Oisín

"Me to". Upgrade to gutsy via dist-upgrade (N times).
2.6.20 works with gutsy, 2.6.22 does not.
1) It generates annoying "Device-mapper errors:" messages
2) it does not mount /dev/sda1 to /windows/c automatically (and "mount -a" does not help too)
3) after "apt-get remove evms" it fails to boot because kernel cannot find root patition (menu.lst: /root=UUID=...)
4) after changeing /root=/dev/sda3 in menu.lst 2.6.22 still does not boot. ("cannot find sda3 device" or somethink like this).

Any suggestions?

Just upgraded edgy->feisty->gutsy in a single day (machine was originally installed as dapper), and this is still a problem. In my case /home was not mounted...which meant that users couldn't log into a graphical shell. I'm glad for the Kubuntu "failsafe" mode (and it's good that I had a 2nd computer in the house to use to google for the solution). As with everyone else, apt-get remove evms solved the problem.

I did the upgrade via the command line, apt-get dist-upgrade.

So to re-cap again. I believe the situation is:

If you do the upgrade via to Gutsy the GUI tool System -> Administration -> Update Manager all is well.

If you do the upgrade using apt-get this will not remove evms for you and you are likely to be in trouble, You have to remove evms yourself.

sudo aptitude remove evms
and re-boo the PC.

But don't listen to me, read it from someone who understands this stuff.
https://wiki.ubuntu.com/Evms

I removed evms (#apt-get remove evms) e reinstalled it again (#apt-get install evms) and the error vanished !

I also had this problem. I upgradet from feisty using the Update Manager, but it stopped at mpd (still having problems there), so I never finished the upgrade. I rebooted, got this error, freaked out, and removed evms after googling the error text on my cell phone. I've never installed evms manually.

I have the problem on a new upgrade, I had to type this command to the blind :

aptitude remove evms

(because too much error messages scrolled)

I had already this problem when I upgrade from Feisty to Gutsy Beta.

Same here. Just dist-upgraded to Gutsy and got unbootable system as a result with this error. It was unable to mount my /home. This is a very bad bug as it probably breaks the upgrade for many people. The package could be removed automatically in dist-upgrade in case it's not needed and causes problems?

Please read the thread above before commenting. evms is removed if the standard and recommended method for upgrading feisty (i.e. upgrade-manager) is used.

As noted in my duplicate report #156157, I encountered this problem when upgrading a server not a workstation -- I upgraded the workstations with upgrade-manager as is recommended and had no problem. The server I upgraded with do-release-upgrade which is the recommended mechanism for upgrading a server, but I got the problem. Is it certain that do-release-upgrade removes evms and that I just had a glitch of some sort?

I had the same error when upgrading to gusty. My laptop had a feisty version upgraded from drapper. I am going to remove evms to confirm the workarround.

To upgrade I use the command "update-manager -d -c", this because when opening the upgrade manager it did not detected the availability of the new version.

My previous version of the kernel allows me to use my computer

uname -a
Linux dnielben-laptop 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux

I am posting just to confirm that this is a real problem and upgrade-manager is not removing evms.

Upgraded a box to 7.10 today, it originally ran 6.06, then it was upgraded to 6.10 and 7.04. All by using apt-get and aptitude. On boot I get a root shell and the continuous error spewing makes it difficult to use that shell.

I browsed trough this thread and if I've read it correctly what this means is that the upgrade path 6.06 > 6.10 works, 6.06 > 6.10 > 7.04 works but 6.06 > 6.10 > 7.04 > 7.10 does not? Even though all these versions are still supported, but since the evms isn't supported in 7.10 this bug wasn't release-critical anymore? Seems to me like a crooked "gray area" in bug tracking policies. Judging from the list of subscribers this is pretty severe. If removing the package fixes it for everyone then surely at least a dummy package could've been provided instead (would cover all upgrade methods and scenarios easy and swift)? (And the real evms be renamed for those who dare.) OTOH if removing the package could cause problems for some people then this is a whole new can of worms. Consider the scenario where something like this would happen to apache(2).

BTW the actual error is slightly different for me, it says "254:8" instead of "254:1" but I guess that could mean that the config file on this box simply has an extra tab on that line.

Just reporting I saw these exact errors on dmesg after updating to 7.10 today

[ 615.757307] device-mapper: ioctl: error adding target to table
[ 615.769759] device-mapper: table: 254:2: linear: dm-linear: Device lookup failed

Just confirming that removing evms "cured" this. Another symptom I was seeing is that my CD tray (a.k.a. "cup holder") would only open half way and close again when this problem was present.

Also for the record I just used the update-manager GUI for my upgrade.

guys stop spamming and confirming, this bug is known at 100%.
If you upgrade from supported tool then evms will be automatically removed (I saw that it's removed in a Feisty->Gutsy upgrade) if you are not using official upgrade method then don't expect that all will work.

So stop spamming and confirming things that all of us just listened about 100 times!

Sorry Cimmo, but you're wrong. A number of people have confirmed that this bug still happens on Gutsy upgrades, EVEN WHEN using the upgrade-manager to perform the upgrade. In fact Alex, whom you responded to, was using the official upgrade method when he ran into the problem.

This bug should be re-opened and get some more attention; until that happens you're just going to have to live with people continuing to add comments to it, since it's an absolutely critical problem that seems to impact a large percentage of people trying to upgrade.

Just out of interest... did the people who upgraded using the update-manager, but still suffered the problem, apply all updates to Feisty before upgrading to Gutsy? If the update-manager was fixed to remove evms in an update, then I can see the problem potentially occuring for Feisty users upgrading if they didn't apply all updates to Feisty first and therefore upgraded using a non fixed version update-manager. I have updated all my machines now so can not test this quickly and easily. Anyone else wanna experiment a bit?

Scott Hilleard ha scritto:
> Just out of interest... did the people who upgraded using the update-
> manager, but still suffered the problem, apply all updates to Feisty
> before upgrading to Gutsy? If the update-manager was fixed to remove
> evms in an update, then I can see the problem potentially occuring for
> Feisty users upgrading if they didn't apply all updates to Feisty first
> and therefore upgraded using a non fixed version update-manager. I have
> updated all my machines now so can not test this quickly and easily.
> Anyone else wanna experiment a bit?
>

No during my update firstly evms was updated and at the end removed.
In my opinion the only possibility is that these people have explicitly
chosen to not remove obsolete software when asked by the installer.

Can be useful if these people comment about this instead saying: "I had
the problem, removed evms now all is ok" that is totally useless at this
point.

So, ATTENTION ATTENTION to all people that had this bug:
- please describe which method of upgrade have you chosen and if you
have agreed to uninstall obsolete software when asked by the installer.

All the rest is totally useless.

thanx

I upgraded about a week before release, using update-manager -d, and
agreed for packages to be removed. I checked the list, and don't
remember evms being on it.

--Max

On 29/10/2007, Cimmo <email address hidden> wrote:
> So, ATTENTION ATTENTION to all people that had this bug:
> - please describe which method of upgrade have you chosen and if you
> have agreed to uninstall obsolete software when asked by the installer.
>

For the sake of not being "totally useless" here's what I recall of this story, this happened on mom-in-law machine, so there's nothing more I can contribute, being in other city as of now.

I have been testing gutsy alpha, beta and final on that machine. Always using the update-manager GUI for the updates. On the last update if requested for a "partial upgrade" which I accepted and I also agreed with it to "remove obsolete packages" or something similar. After the reboot the problem was there, showing on dmesg on a terminal, I had an usable gnome desktop, but my NTFS partitions won't show on the desktop or auto mount and I had the problem of the CD tray not opening completely.

All the symptoms were resolved once evms was removed using aptitude.

Hope this helps and keep up the great work.

> In my opinion the only possibility is that these people have explicitly
> chosen to not remove obsolete software when asked by the installer.

At least in my case this is simply not true. I did use update-manager and did agree to remove all absolute packages. There are other reports above which say the same. But the responsible people seem not to believe in this and continue to state that we must have done something wrong, because they can't reproduce the problem. ;-) It obviously does work in the standard test cases but it looks like that under certain circumstances evms does not get removed although it should.

The common denominator _seems_ to be that all those systems started with an earlier version than feisty.

I had this problem. Thankfully I found this bug report.

I did NOT choose not to remove obselete software - in fact I was careful to remove obselete software. I also made sure my feisty system was totally up to date before starting.

My system has evolved from dapper drake thru edgy, eisty, gutsy, if that is what is meant by 'started with an earlier version than feisty'.

This has been the worst upgrade so far. Avoiding this rubbish is why I left gentoo. Perhaps time to look at it again?

foolishchild, did you upgrade before or after the release of Gutsy?

I don't want to be boring, but is it possible that update-manager crashed before it finished all the updates he wanted to perform? It's what happened to me: it took some time before I realize that it hadn't finished but had discretely crashed. Just an idea - chastise me telling that apt does not complain and I will shut up ;-).

yeah Milan that happened to me, but I had restarted it in text mode and finished.
I still thinking all people with problems didn't uninstall obsolete packages...

On 29/10/2007, Scott Hilleard <email address hidden> wrote:
> foolishchild, did you upgrade before or after the release of Gutsy?
>

Personal insults aren't going to solve the problem.

It might be that it works if the Single Correct Upgrade Procedure is
followed. But this is a very specific and narrow case that does not
happen on many systems.

Who would update a system that is about to be upgraded to a new release?

Doesn't the upgrade process ever break?

What should people without a gui (on server/remote systems) do?

I guess the change is too fast. Ideally a change that causes such
serious breakage should be done in two steps. First make the evms
package obsolete, and give it some time to disappear. But it can
disappear only if the update tools do show it as obsolete package that
should be removed.
Then it would be safe to remove the kernel patches.

As a fixup when we are already in trouble it would be desirable to
release an updated evms package in Gutsy which would refuse to start
whatever evms does if the configuration is broken.

Wait, sorry, that wasn't intended as a personal insult, thats his launchpad username!!! I was directing the comment at him and didn't mean it as an insult at all! :)

I *tried to* upgrade using the instructions at http://kubuntu.org/announcements/7.10-release.php#upgrade
page.

The installer crashed so I resorted to the good ol' 'apt-get dist-upgrade' method I've used since my
Debian times. It has always worked before quite well.

In case there is a single method of dist-upgrading that does not render the installation unbootable,
it should be written with bold letters in the update instructions page. Especially, in case the
traditional 'dist-upgrade' is not one of the supported methods of distribution upgrade anymore,
it's not something that should be considered a self-clear thing for users, but announced widely.

However, except for this single issue with upgrading, Gutsy seems to work flawlessly. Well done.

Best regards,
Pekka

On 30/10/2007, Scott Hilleard <email address hidden> wrote:
> Wait, sorry, that wasn't intended as a personal insult, thats his
> launchpad username!!! I was directing the comment at him and didn't mean
> it as an insult at all! :)

Ah, I was looking from my mailbox, and it looks like my spam filter
thought foolishchild is too much so it did not show the comment from
him/her. Since there was already some quite sharp comment earlier I
got the impression this is escalating too much ;-)

Sorry about the misunderstanding

I have another question, evms successfully removed here, however if I do a locate evms here is the result:

/var/lib/dpkg/info/evms.list
/var/lib/dpkg/info/evms.postrm
/var/lib/dpkg/info/libevms-2.5.list
/var/lib/dpkg/info/libevms-2.5.postrm
/var/log/evms-engine.log
/var/log/evms-engine.1.log
/var/log/evms-engine.2.log
/var/log/evms-engine.3.log
/var/log/evms-engine.4.log
/var/log/evms-engine.5.log
/var/log/evms-engine.6.log
/var/log/evms-engine.7.log
/var/log/evms-engine.8.log
/var/log/evms-engine.9.log
/etc/devfs/conf.d/evms
/etc/init.d/evms
/etc/modutils/evms
/etc/rc0.d/S49evms
/etc/rc6.d/S49evms
/etc/rcS.d/S27evms
/etc/udev/rules.d/85-evms.rules
/etc/evms.conf

ok for logs not being removed, but all the rest why sill here?

try a purge maybe?
it's the underscore character on the package in aptitude...
_J

On Nov 5, 2007 5:10 AM, Cimmo <email address hidden> wrote:
> I have another question, evms successfully removed here, however if I do
> a locate evms here is the result:
>
> /var/lib/dpkg/info/evms.list
> /var/lib/dpkg/info/evms.postrm
> /var/lib/dpkg/info/libevms-2.5.list
> /var/lib/dpkg/info/libevms-2.5.postrm
> /var/log/evms-engine.log
> /var/log/evms-engine.1.log
> /var/log/evms-engine.2.log
> /var/log/evms-engine.3.log
> /var/log/evms-engine.4.log
> /var/log/evms-engine.5.log
> /var/log/evms-engine.6.log
> /var/log/evms-engine.7.log
> /var/log/evms-engine.8.log
> /var/log/evms-engine.9.log
> /etc/devfs/conf.d/evms
> /etc/init.d/evms
> /etc/modutils/evms
> /etc/rc0.d/S49evms
> /etc/rc6.d/S49evms
> /etc/rcS.d/S27evms
> /etc/udev/rules.d/85-evms.rules
> /etc/evms.conf
>
> ok for logs not being removed, but all the rest why sill here?
>
>
> --
> Device-mapper errors: dm-linear, lookup failed
> https://bugs.launchpad.net/bugs/115616
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I initialled installed v 6.06, upgraded to 7.04 (Feisty) several months ago and was running well, yet after update and upgrade to 7.10 this morning I had the above reported problem even after removing evms, i.e. I cannot boot into 2.6.22 but 2.6.20. Not sure what's happenning. Mine is a Dell GX260 with two harddisks(Three OS). The same upgrading pathway was working for my IBM T40 with only one disk on system.

I agree with the posters who mention that if the good old method of upgrade "apt-get dist-upgrade" is no longer supported for some functions, a note should be added to "apt" packages or elsewhere. I just upgraded my machine and had the same error. I too have been upgrading for several versions now.

I have exactly the same problem since the latest kernel update with my Kubuntu gutsy installation:

kernel [ 2185.818660] device-mapper: table: 254:1: linear: dm-linear: Device lookup failed
25.11.2007 11:40:34 zalas kernel [ 2185.819148] device-mapper: ioctl: error adding target to table

I didn't have this problem before. How can I stop the process. My kubuntu installation is unusable right now.

It's explained at the beginning of the bug description. I updated it so it is more explicit, but *please* always read carefully at least the description if not the complete thread before asking for help. Thanks for caring about that, though.

Sorry about that. Thanks. Luther
----- Original Message -----
From: "Milan" <email address hidden>
To: <email address hidden>
Sent: Sunday, November 25, 2007 3:07 PM
Subject: [Bug 115616] Re: Device-mapper errors: dm-linear, lookup failed

It's explained at the beginning of the bug description. I updated it so
it is more explicit, but *please* always read carefully at least the
description if not the complete thread before asking for help. Thanks
for caring about that, though.

** Description changed:

- [This issue is fixed by removing evms]
+ [This issue is fixed by removing evms: just type "sudo apt-get remove
+ evms" in a console.]

  In gutsy the new 2.6.22-4-generic kernel produces the following error
  message repreatedly:

  May 19 10:10:16 richard-desktop kernel: [ 227.338011] device-mapper:
table: 254:1: linear: dm-linear: Device lookup failed
  May 19 10:10:16 richard-desktop kernel: [ 227.338017] device-mapper:
ioctl: error adding target to table

  This causes the disk to thrash. Can be eliminated by killing the udevd
daemon.
  Does not occur with the 2.6.20-15 kernel.

--
Device-mapper errors: dm-linear, lookup failed
https://bugs.launchpad.net/bugs/115616
You received this bug notification because you are a bug contact for
update-manager in ubuntu.

I don't know. My system is operational, but I don't know what has been
updated and what has not. Sorry I can' help you. Luther
----- Original Message -----
From: "Hagy Hag" <email address hidden>
To: <email address hidden>
Sent: Sunday, November 25, 2007 2:46 PM
Subject: [Bug 115616] Re: Device-mapper errors: dm-linear, lookup failed

I have exactly the same problem since the latest kernel update with my
Kubuntu gutsy installation:

kernel [ 2185.818660] device-mapper: table: 254:1: linear: dm-linear:
Device lookup failed
25.11.2007 11:40:34 zalas kernel [ 2185.819148] device-mapper: ioctl:
error adding target to table

I didn't have this problem before. How can I stop the process. My
kubuntu installation is unusable right now.

--
Device-mapper errors: dm-linear, lookup failed
https://bugs.launchpad.net/bugs/115616
You received this bug notification because you are a bug contact for
update-manager in ubuntu.

I'm confused as this bug still affects users who need evms to operate their raid.

Are there any other options for users in this case? If not, the bug needs to be reopened.

Scott Remnant posted a wiki entry on the situation:
https://wiki.ubuntu.com/Evms

I don't usually like to add a "me too" comment to bugs but I think this one is rather important and I want to add my almost insignificant voice -- happened on one of my production servers yesterday during a dist_upgrade to Gutsy. The purge of evms worked fine and the killall udevd made the machine usable 'til reboot -- I didn't even know I was using evms! -- I also had to remove lvm which caused conflicts and thought I'd wrecked the install by removing something I shouldn't: I used to know what almost everything did on Debian-based distros - sigh! those were the days :)

So, if apt-get dist-upgrade is no longer considered a "supported" method or "the right way" of upgrading, what are users to do when the update manager chokes on a package that corrupted on download and has to be killed? That happened to me. After a bit of fighting with dpkg, I could get apt-get dist-upgrade to run and get a working (except for this) system again. The command line really really should never break, and having different results from a dist-upgrade than from the update manager, is a bad thing.

If you read the first post you will see:

[This issue is fixed by removing evms: just type "sudo apt-get remove evms" in a console.]

On 21/12/2007, Richard Kleeman <email address hidden> wrote:
> If you read the first post you will see:
>
> [This issue is fixed by removing evms: just type "sudo apt-get remove
> evms" in a console.]

But that does not fix the issue. The issue is that unless you file a
duplicate of this bug and get to read the first post your system is
broken.

Hi,
I have do apt-get dist-upgrade on a server (without any X environment, so I can't use update-manager) and I must to remove evms manually to fix the issue.

To remove first reduce LogLevel to 3 (using the sysrq key (alt+sysrq+3))
then update the path with the main binary directory (export PATH=/bin:/sbin:/usr/bin:/usr/sbin:$PATH)
after you can remove evms using apt-get remove evms.

This bug not really fix, I think you must add a conflict package in linux-server or in a package only installed in a server because I don't think that lot of people look wiki evms page before upgrading ...

PS : Sorry for the up :|

MulX

I had the same (udevd) problem after upgrading xubuntu 6.06 to 8.04 (although the problem might already have occurred with 6.06)
removing evms and stop, restart udevd helped.

I had the same (udevd) problem after upgrading kubuntu 6.06 to 8.04 on PPC.
Removing evms and reboot helped.

Same as 'PETIT Aymeric' here...
Just upgraded a server from dapper to hardy, after which the /backup couldn't be mounted... same device-mapper errors.
After removing evms and a reboot, it worked again.

Just to be clear -

This bug is *not* fixed. Upgrading via command line and completely breaking a working system is not very cool. System critical bugs that are open for years doesn't bother me half as much as serious bugs erroneously marked as fixed...

2009/2/10 Christian Gunning <email address hidden>:
> Just to be clear -
>
> This bug is *not* fixed. Upgrading via command line and completely
> breaking a working system is not very cool. System critical bugs that
> are open for years doesn't bother me half as much as serious bugs
> erroneously marked as fixed...

This is fixed by proclaiming any systems still carrying the buggy
package obsolete which is a common technique for fixing bugs in
Ubuntu.

Maybe this can be addressed at the release notes. So i'm adding it to the wiki so the admins out there upgrading from 6.06 to 8.04 can take this into account beforehand.

https://wiki.ubuntu.com/HardyReleaseNotes

Also i'm adding the ubuntu website tasks to update the website.

Andres,

Can you please propose some language to use in the release notes for describing this issue? The 8.04 release notes are otherwise unlikely to get much additional attention at this point.

Steve i put this at the wiki:

Upgrading from EVMS 6.06 LTS Systems

    *

      Since 7.10, EVMS support was dropped by upstream and moved to Universe in Ubuntu. Users from previous LTS Release should be aware of this issue and act accordingly as suggested at https://wiki.ubuntu.com/Evms and https://bugs.edge.launchpad.net/bugs/115616. The common solution is to remove evms from console.

Closed as per verification of release notes.