evms blocks access to disk devices

Bug #109320 reported by Ben Collins on 2007-04-23
Affects Status Importance Assigned to Milestone
evms (Ubuntu)

Bug Description

Binary package hint: evms

For several releases the Ubuntu kernel has been carrying around a patch that allows evms/lvm to interact more easily with block devices.

The basic idea of the patch is to revert some stricter locking on devices so that evms can claim to be handling a device, while still allowing userspace to access partitions without using evms.

This is a bad thing, mainly because it means I can mount /dev/sda1 even though evms is using it, or using the entire of /dev/sda.

However, we kept this patch because it was easiest, and kept some things from breaking. I'm not prepared to continue this any longer. We need to address the problem well before gutsy+1 (most likely the next LTS).

Aside from the odd use case above, which users should expect to break, normal operations are breaking as well. I have a system with 4 scsi drives, none of them being managed by evms or lvm, and yet I cannot mount the partitions on them after evms starts up. I had to explicitly exclude things in /etc/evms.conf.

So either the solution is we switch to using evms for everything, or we teach evms to not be so broad in the devices it claims. by default.

Related branches

Changed in evms:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Critical
status: Unconfirmed → Confirmed
Martin Pitt (pitti) wrote :

Unmilestoning, as agreed in yesterday's meeting, since evms is in universe now (due to general brokenness and lack of maintainership)

For the duplicate bug(s) refugees:
Removing all packages with evms in their name solved booting problem for me.
I also ran 'update-initramfs -u', but don't know if that was really necessary.

Thanks Pasi, I just removed evms packages and now it works.

On 6/25/07, Pasi Savolainen <email address hidden> wrote:
> For the duplicate bug(s) refugees:
> Removing all packages with evms in their name solved booting problem for
> me.
> I also ran 'update-initramfs -u', but don't know if that was really
> necessary.
> --
> evms blocks access to disk devices
> https://bugs.launchpad.net/bugs/109320
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

Alex Mauer (hawke) wrote :

This is a problem even though evms is no longer supported:

If the user elects not to remove the newly-unsupported evms package at upgrade time, the system becomes unbootable because of this problem.

Even booting into recovery mode is not possible.

The old kernel still works, and if the user knows to boot from it, and knows enough to run the 'update-initramfs -u' at that point, the system is recoverable...but if not, they're dead in the water.

I realise that evms is no longer supported, but the path away from it should be.

amano (jyaku) wrote :

It might be bad luck, but I want to report my problem anyway: I had the problem with the strange errors at startup as well. And I studied this bug. And I tried the solution to remove the package evms package. (and it remove evms-curses as well). When it tried to remove the packages, Synaptic froze, I waited for a few minutes and then killed X (Ctr-Alt-Backspace). After a minute on the pure console the system shot down, but wasn't able to boot up anymore : '[20.451476] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)'

A 'sudo fsck -c /dev/hda2' (my linux partition according to gparted) didn't solve the problem for me. So I am stuck and have to reinstall Gutsy again (probably). I don't know, if my problems are related to this bug, but wanted to report it anyway. Good luck with fixing it.

amano (jyaku) wrote :

Just to add: The bug was fixed by chrooting from the live disc and 'update-initramfs -u'. But the bug has potential to cause troubles. And I don't know how this package was installed. I didn't install it manually.

Michael Flaig (mflaig) wrote :

What is the current state of this bug?

I don't have any evms packages installed, but the default gutsy kernel stopps booting on my macpro after loading evms and printing out messages with waiting x seconds for sda to come up?! the messages are counting the "wait seconds" up. Booting stops here.
I think it is related to this bug - Is it?

The system was set up with feisty installer and upgraded to gutsy right away. I am using raid1 lvm and dm-crypt

Sticking to my self-compiled kernel package for now...

Download full text (4.9 KiB)

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
  * 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 (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
  * 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


Changed in evms:
status: Confirmed → Fix Released
Jojo (kuzniarpawel) wrote :

That's a serious bug. After installing Evms my lvm2 volumes could not be accessed anymore. So I tried to rescue them with Rescue broken system option from Gusty alternate cd. These are steps, which were necessary tu take in order to rescue system:

I got separate /boot and in lvm / , /home , /media , /var

1) From rescue broken system go chroot to / (in my case it was in lvm as mentioned above)
2) apt-get purge evms evms-cli
3) apt-get autoremove - to get rid of libevms-2.5
4) lvm
5) in lvm type -> vgcfgrestore
6) exit from lvm -> exit
7) depmod -a
8) update-initramfs -u
9) restart system
10) if your partitions don't mount edit /etc/fstab and change uuid to appropriate devices (in my case uuids were broken don't know why)

Jojo (kuzniarpawel) wrote :

here are my specs

uname -a
Linux jojo 2.6.22-14-generic #1 SMP Wed Oct 10 06:00:47 GMT 2007 i686 GNU/Linux

df -h
                       20G 2,1G 18G 11% /
varrun 887M 100K 887M 1% /var/run
varlock 887M 0 887M 0% /var/lock
udev 887M 92K 887M 1% /dev
devshm 887M 0 887M 0% /dev/shm
lrm 887M 34M 853M 4% /lib/modules/2.6.22-14-generic/volatile
                       80G 1,7G 79G 3% /home
                      293G 284G 9,7G 97% /media
                       20G 1006M 20G 5% /var

Ibai Q R (ibaiqr) wrote :

Taking evms out (As jojo explains two posts up) worked for me. Thank you.

Aki Rossi (lorkki) wrote :

For what it's worth, this bug also seems to be the reason as to why some users (including myself) have been unable to mount their NTFS volumes after an upgrade to Gutsy, at least without manually removing the device mappings made by evms during each boot. I presume that the reason why NTFS in particular appears to be affected is that evms can only "activate" volumes that aren't already in use and FUSE file systems can't be mounted by initrd. In any case, removing all evms-related packages solved the problem for me.

It might be a good idea to at least mention this somewhere, since it seems that the only solution circulating in common knowledge is to run 'dmsetup remove_all' again and again.

I not clear whether this bug has been sorted. I have been using the latest version of Gutsy, but as can be seen from the following forum post I have had a lot of problems similar to the bug listed above:


As it might not be the same cause could you please have a look at my problem and see if it matches exactly.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers