Ubuntu

Device-mapper errors: dm-linear, lookup failed

Reported by Richard Kleeman on 2007-05-19
302
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
Ubuntu Website
Undecided
Unassigned
Baltix
Undecided
Unassigned
evms (Ubuntu)
High
Unassigned
linux-source-2.6.22 (Ubuntu)
Undecided
Kyle McMartin
update-manager (Ubuntu)
Critical
Michael Vogt

Bug Description

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

FOR MORE INFORMATIONS:
https://wiki.ubuntu.com/Evms

Related branches

Soren Hansen (soren) on 2007-05-20
Changed in linux-source-2.6.22:
status: Unconfirmed → Confirmed
Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.22:
status: Confirmed → Unconfirmed
Richard Kleeman (kleeman) wrote :

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

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

Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.22:
status: Unconfirmed → Rejected
Richard Kleeman (kleeman) wrote :

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

Richard Kleeman (kleeman) wrote :

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

Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.22:
assignee: nobody → kyle
status: Rejected → Needs Info
Changed in evms:
assignee: nobody → kyle
status: Unconfirmed → Needs Info
Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.22:
status: Needs Info → Rejected
Changed in evms:
assignee: kyle → keybuk
importance: Undecided → High
status: Needs Info → In Progress
Bogdan Butnaru (bogdanb) wrote :

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

LGB [Gábor Lénárt] (lgb) wrote :

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.

SergeyS (ssedreev) wrote :

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?

Luca Cavalli (luca-cavalli) wrote :

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.

TuxFan (make) wrote :

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.

Andy Wingo (andywingo) wrote :

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.

Wolf Halton (saphil) wrote :

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

Noah Slater (nslater) wrote :

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.

Leonel Nunez (leonelnunez) wrote :

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

Marco Cimmino (cimmo) wrote :

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.

wgscott (wgscott) wrote :

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.

wgscott (wgscott) wrote :

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

Dave Hall (skwashd) wrote :

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

amias (amias) wrote :

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.

Marco Cimmino (cimmo) wrote :

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.

jdm64 (jdm64) wrote :

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.

Darik Horn (dajhorn) wrote :

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.

Elie De Brauwer (elie) wrote :

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.

Alex Ruddick (alexrudd0) wrote :

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.

Joan Tur (joantur) wrote :

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.

Mathieu Laurent (mla) wrote :

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

Kees Cook (kees) wrote :

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

Andrew Corrigan (acorriga) wrote :

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.

Russell John (russell.john) wrote :

I've had the same problem on Kubuntu Gutsy.

Russell John (russell.john) wrote :

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

Gonzalo Vera (gvz) wrote :

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

Changed in evms:
status: In Progress → Fix Released
Matthew East (mdke) on 2007-10-11
Changed in evms:
status: Fix Released → Confirmed
Changed in evms:
assignee: keybuk → nobody
milestone: ubuntu-7.10-rc → none
Kees Cook (kees) on 2007-10-11
Changed in update-manager:
status: New → Fix Released
description: updated
Changed in evms:
status: Confirmed → Won't Fix
Changed in linux-source-2.6.22:
status: Invalid → Confirmed
Changed in linux-source-2.6.22:
status: Confirmed → Invalid
Changed in update-manager:
assignee: nobody → mvo
status: Fix Released → Confirmed
importance: Undecided → Critical
milestone: none → ubuntu-7.10
Steve Langasek (vorlon) on 2007-10-12
Changed in update-manager:
status: Confirmed → Fix Released
68 comments hidden view all 148 comments
Alex Mayorga (alex-mayorga) wrote :

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.

Marco Cimmino (cimmo) wrote :

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!

Paul Smith (psmith-gnu) wrote :

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

Max Rabkin (max-rabkin) wrote :

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

Alex Mayorga (alex-mayorga) wrote :

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.

foolishchild (j-clark) wrote :

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

Marco Cimmino (cimmo) wrote :

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

Michal Suchanek (hramrach) wrote :

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

Michal Suchanek (hramrach) wrote :

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

Marco Cimmino (cimmo) 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?

James (purpleidea) wrote :

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

chuck (ctong) wrote :

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.

ulugeyik (durduran) wrote :

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.

Hagy Hag (elektroschock) wrote :

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.

description: updated

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.

Richard Kleeman (kleeman) wrote :

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

Marco Cimmino (cimmo) on 2007-12-14
description: updated
Michael Erskine (msemtd) wrote :

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 :)

Mackenzie Morgan (maco.m) wrote :

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.

Richard Kleeman (kleeman) 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.]

Michal Suchanek (hramrach) wrote :

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.

Aymeric PETIT (mulx) wrote :

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

Heinvandijk (dijkvan) wrote :

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.

dominik (dominik-holler) wrote :

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

Rob (robklg) wrote :

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

Michal Suchanek (hramrach) wrote :

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.

Andres Mujica (andres.mujica) wrote :

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.

Changed in ubuntu-release-notes:
status: New → Confirmed
Changed in ubuntu-website:
status: New → Confirmed
Steve Langasek (vorlon) wrote :

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.

Andres Mujica (andres.mujica) wrote :

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.

Matthew Nuzum (newz) on 2009-08-20
Changed in ubuntu-website:
status: Confirmed → Invalid
Christian Reis (kiko) wrote :

Closed as per verification of release notes.

Changed in ubuntu-release-notes:
status: Confirmed → Fix Committed
status: Fix Committed → Fix Released
Displaying first 40 and last 40 comments. View all 148 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers