evms blocks access to disk devices

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

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.

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.

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.

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

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

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)

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
/dev/mapper/mainvg-rootlv
                       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
/dev/mapper/mainvg-homelv
                       80G 1,7G 79G 3% /home
/dev/mapper/mainvg-medialv
                      293G 284G 9,7G 97% /media
/dev/mapper/mainvg-varlv
                       20G 1006M 20G 5% /var

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

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:

http://ubuntuforums.org/showthread.php?t=708307

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.