Debian Bug report logs - #549691
lvm2: lvremove fails to remove open logical volume which is not opened

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Jürgens <ma@jgs-wg.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Mon, 05 Oct 2009 19:43:50 +0200

Package: lvm2
Version: 2.02.39-7
Severity: normal

lvremove fails to remove my swap LV, although it is not mounted and not mentioned in /etc/fstab:

x:~# free -m
             total       used       free     shared    buffers     cached
Mem:           498        410         88          0         62        153
-/+ buffers/cache:        194        303
Swap:            0          0          0

x:~# cat /proc/swaps 
Filename				Type		Size	Used	Priority
x:~# lsof /dev/mapper/x-swap_1
x:~# fuser /dev/mapper/x-swap_1

x:~# lvremove --force /dev/x/swap_1 
  Can't remove open logical volume "swap_1"

x:~# lvchange -a n /dev/x/swap_1
  LV x/swap_1 in use: not deactivating


-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lvm2 depends on:
ii  libc6                        2.7-18      GNU C Library: Shared libraries
ii  libdevmapper1.02.1           2:1.02.27-4 The Linux Kernel Device Mapper use
ii  libreadline5                 5.2-3.1     GNU readline and history libraries
ii  lsb-base                     3.2-20      Linux Standard Base 3.2 init scrip

Versions of packages lvm2 recommends:
pn  dmsetup                       <none>     (no description available)

lvm2 suggests no packages.

-- no debconf information

Message #10 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Hugh Saunders <hugh@mjr.org>

To: 549691@bugs.debian.org

Subject: Auto-detection?

Date: Wed, 18 Nov 2009 19:40:33 +0000

I have this problem as well. I deactivated all swap and removed fstab
entries but was unable to remove the swap LV.
I rebooted, but was still unable to remove the LV, despite the box
coming up with no swap.  I decided that some autodetction was going
on, so I wrote junk to the beginning of the swap partition, then
rebooted and was able to remove the LV.

-- 
Hugh Saunders

Message #15 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Leonardo Boiko <leoboiko@gmail.com>

To: 549691@bugs.debian.org

Subject: re: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Mon, 8 Mar 2010 16:17:16 -0300

I had this problem because my old swap LV was listed in
/etc/initramfs-tools/conf.d/resume .  I changed it, update-initramfs
-u, reboot, and then I could remove the LV.

Message #22 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Martin Jürgens <ma@jgs-wg.de>, 549691@bugs.debian.org

Subject: Re: Bug#549691: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Sun, 4 Apr 2010 23:55:27 +0200

On Mon, Oct 05, 2009 at 07:43:50PM +0200, Martin Jürgens wrote:
> lvremove fails to remove my swap LV, although it is not mounted and not mentioned in /etc/fstab:

Too less information. A swap LV can be in use by a large amount of
things:
- Used as swap.
- Used as resume device.

Bastian

-- 
Warp 7 -- It's a law we can live with.

Message #27 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Celejar <celejar@gmail.com>

To: Debian Bug Tracking System <549691@bugs.debian.org>

Subject: lvm2: can't remove unmounted snapshot volume

Date: Tue, 06 Apr 2010 21:24:33 -0400

Package: lvm2
Version: 2.02.62-1
Severity: normal


I'm seeing the same problem trying to remove a snapshot volume.  It is not
mounted, but it can't be removed:

~# lvremove /dev/lizzie/var_backup 
  Can't remove open logical volume "var_backup"

~# lvchange -a n /dev/lizzie/var_backup 
  Can't change snapshot logical volume "var_backup"

~# mount
/dev/mapper/lizzie-root on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda3 on /boot type ext3 (rw)
/dev/mapper/lizzie-home on /home type ext3 (rw)
/dev/mapper/lizzie-usr on /usr type ext3 (rw)
/dev/mapper/lizzie-var on /var type ext3 (rw)
none on /tmp type tmpfs (rw)

Eventually, I noticed that after a suspend / resume cycle, mount now shows that
the snapshot volume is mounted where the original should be:

~# mount
/dev/mapper/lizzie-root_backup on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda3 on /boot type ext3 (rw)
/dev/mapper/lizzie-home on /home type ext3 (rw)
/dev/mapper/lizzie-usr on /usr type ext3 (rw)
/dev/mapper/lizzie-var_backup on /var type ext3 (rw)
none on /tmp type tmpfs (rw)

[Note that root / root_backup is now messed up, too.]

What on earth is going wrong here?  How is the snapshot usurping the place of
the origin volume?  And I have no idea what the trigger is.  This doesn't
generally happen - I've seen it once before, and now again, after using this
backup system for several months.  The last time, I resolved the problem by
going to runlevel 1 and remounting correctly, and then returning to runlevel 2.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.34-rc2-lizzie-00052-gae6be51
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lvm2 depends on:
ii  dmsetup                      2:1.02.45-1 The Linux Kernel Device Mapper use
ii  libc6                        2.10.2-6    Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1           2:1.02.45-1 The Linux Kernel Device Mapper use
ii  lsb-base                     3.2-23      Linux Standard Base 3.2 init scrip

lvm2 recommends no packages.

lvm2 suggests no packages.

-- no debconf information

Message #32 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Celejar <celejar@gmail.com>

To: 549691@bugs.debian.org

Cc: 573254@bugs.debian.org

Subject: failure removing snapshot volumes

Date: Thu, 8 Apr 2010 14:52:07 -0400

Hi,

I'm still having trouble removing my snapshot volumes.  I recalled that
my fstab mounts are based on UUID, which are identical for the origin
and the snapshot (so much for unique ;)), so I switched to path based
mounting, and so far I have not experienced the problem in exactly the
original form (although it only happened occasionally anyway, so
there's nothing conclusive here).

But I'm still having trouble with snapshot removal.  I'm using
rsnapshot's lvm integration: the utility creates a snapshot, mounts it,
does a rsync based backup of the snapshot, umounts the snapshot and
then removes it.  But rsnapshot keeps bailing, claiming that the
snapshot can't be removed.  When I try to remove it manually, I get the
"Can't remove open logical volume" error.  I generally find that after
waiting a few minutes and trying again, it works.  It isn't mounted
anymore, so why isn't it going away the first time(s)?

Celejar
-- 
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator

Message #37 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Martin Jürgens <mjuergens@gmail.com>

To: 549691@bugs.debian.org

Date: Mon, 12 Apr 2010 19:04:22 +0200

[Message part 1 (text/plain, inline)]

in my case the problem was caused due to the swap device being listed in
/etc/initramfs-tools/conf.d/resume . it would be nice if there was some hint
when the swap removal fails because of this.

[Message part 2 (text/html, inline)]

Message #42 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Timm Essigke <Timm.Essigke@uni-bayreuth.de>

To: 549691@bugs.debian.org

Subject: failure removing snapshot volumes

Date: Sat, 17 Apr 2010 19:10:34 +0200

Package: lvm2
Version: 2.02.62-1
Severity: critical


Hi,

I have the same problem as described in message #27.

I create snapshots by a script triggered by bacula, then run the backup 
on the snapshots and remove them by another script triggered by bacula. 
Removing some (!) snapshots fails on all ca. 25 computers running 
squeeze in my network. Several attempts of lvremove allow to remove some 
of the remaining snapshots. It seems to help to delete 
/etc/lvm/cache/.cache before lvremove. Some computers (servers with many 
KVM machines!) I had to reboot from rescue CD to get rid of the snapshots.

For my backup system this bug is a total show stopper!

Regarding message #32 I don't use UUIDs in fstab
Regarding message #37 I don't snapshot swap

Please help!

Timm

Message #47 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Tim Black <timblaktu@gmail.com>

To: 549691@bugs.debian.org

Subject: failures removing (and sometimes creating) lvm snapshot lvs

Date: Sat, 1 May 2010 22:42:27 -0700

I am also getting error removing (and sometimes creating) lvm snapshots using rsnapshot's lvm support. The errors are intermittent, and following the errors I can manually perform the same operation using lvcreate/lvremove at command line. 

I am using Karmic Ubuntu server with rsnapshot 1.3.1 and latest from CVS. 

Kernel: Linux servy 2.6.31-20-server #58-Ubuntu SMP Fri Mar 12 05:40:05 UTC 2010 x86_64 GNU/Linux

tim@servy:/usr/local/src/rsnapshot-1.3.1$ sudo lvm version
  LVM version:     2.02.39 (2008-06-27)
  Library version: 1.02.27 (2008-06-25)
  Driver version:  4.15.0

LVM2 Dependencies:
libc6 2.10.1-0ubuntu16
libdevmapper1.02.1 2:1.02.27-4ubuntu7
dmsetup 2:1.02.27-4ubuntu7
udev 147~-6.1

Like TImm with 2 m's I am not using UUIDs in fstab and am not snapshotting swap.

Some reports of my experiences here: http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/rsnapshot-24/lvm-rsnapshot-92311/#333940.

Tim with one m

Message #52 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Timm Essigke <Timm.Essigke@uni-bayreuth.de>

To: 549691@bugs.debian.org

Subject: failure removing LVM snapshots

Date: Mon, 03 May 2010 00:20:29 +0200

Hi Tim,

I am not sure, but I assume that your bug is a different one to what 
Celejar and I am experiencing.
For me snapshot removal worked fine before version 2.02.62-1. I was 
running the same scripts on all my computers for months without any 
problems.

I would greatly appreciate if this bug would gain more attention. I 
would try my best to give whatever information is needed to fix the bug.

Regards,

Timm (with two m ;-) )

Message #57 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Timm Essigke <Timm.Essigke@uni-bayreuth.de>

To: 549691@bugs.debian.org, Timm Essigke <Timm.Essigke@uni-bayreuth.de>, debian-kernel@lists.debian.org

Subject: workaround for LVM snapshot bug

Date: Wed, 19 May 2010 20:06:39 +0200

[Message part 1 (text/plain, inline)]

Hi,

I found a workaround for the bug, but I am sure it should not be like 
that (based on 
http://tuxrx.org/content/cant-remove-open-logical-volume-error). To 
reproduce:

% lvs

  LV      VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
...
  work    abraham -wi-ao  10.00g

% ls -l /dev/mapper/abraham-work*
lrwxrwxrwx 1 root root 7 May 19 19:40 /dev/mapper/abraham-work -> ../dm-7

% lvcreate -s -nwork_snap -L100m /dev/abraham/work
  Logical volume "work_snap" created

% lvs
  LV        VG      Attr   LSize   Origin Snap%  Move Log Copy%  Convert
...
  work      abraham owi-ao  10.00g
  work_snap abraham swi-a- 100.00m work     0.01

% ls -l /dev/mapper/abraham-work*
lrwxrwxrwx 1 root root 7 May 19 19:38 /dev/mapper/abraham-work -> ../dm-7
lrwxrwxrwx 1 root root 8 May 19 19:38 /dev/mapper/abraham-work-real -> 
../dm-10
lrwxrwxrwx 1 root root 7 May 19 19:38 /dev/mapper/abraham-work_snap -> 
../dm-9
lrwxrwxrwx 1 root root 8 May 19 19:38 /dev/mapper/abraham-work_snap-cow 
-> ../dm-11

% dmsetup remove /dev/mapper/abraham-work_snap
% dmsetup remove /dev/mapper/abraham-work_snap-cow
% lvremove /dev/mapper/abraham-work_snap
  Logical volume "work_snap" successfully removed

Now all traces of the snapshot are remove. If I only "dmsetup remove" 
the snapshot, but not the "-cow" it persists and prevents future snapshots.

I am not sure if it is a bug in lvm2 or rather in 
kernel-image-2.6.32-trunk-* and  kernel-image-2.6.32-5-* together with 
udev and dm. If I downgrade lvm2 from 2.02.62-1 to 2.02.39-7 the error 
remains. Instead downgrading to 2.6.26 works as before.

Shall I report the bug against linux-2.6?

The sample uses the symbolic links because I modified 
/lib/udev/rules.d/55-dm.rules according to message #44 of debian bug  
#581593, but with the block device the problem and solution is the same.

@Tim: I think you were right, that the bug is the same... Sorry!

I hope the workaround helps the maintainers to find the real source of 
the problem.

Regards,

Timm

[Message part 2 (text/html, inline)]

Message #62 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Peter Rajnoha <prajnoha@redhat.com>

To: Celejar <celejar@gmail.com>, 549691@bugs.debian.org

Subject: Re: Bug#549691: lvm2: can't remove unmounted snapshot volume

Date: Wed, 19 May 2010 22:10:49 +0200

On 04/07/2010 03:24 AM, Celejar wrote:
> I'm seeing the same problem trying to remove a snapshot volume.  It is not
> mounted, but it can't be removed:
> 
> ~# lvremove /dev/lizzie/var_backup 
>   Can't remove open logical volume "var_backup"
> 
> ~# lvchange -a n /dev/lizzie/var_backup 
>   Can't change snapshot logical volume "var_backup"
> 

As a quick and rough check, you can try to temporarily kill udev daemon and then
see if these commands pass. If yes, then this is just another instance of quite
common error seen where lvm2's udev synchronization feature is not used (a device
being opened and scanned from within udev rules while trying to deactivate it).

Message #67 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Peter Rajnoha <prajnoha@redhat.com>

To: Celejar <celejar@gmail.com>, 549691@bugs.debian.org

Subject: Re: Bug#549691: lvm2: can't remove unmounted snapshot volume

Date: Wed, 19 May 2010 22:36:29 +0200

On 04/07/2010 03:24 AM, Celejar wrote:
> Eventually, I noticed that after a suspend / resume cycle, mount now shows that
> the snapshot volume is mounted where the original should be:

Not exactly this case, I suppose, but maybe it's worth mentioning because
it's very similar...

There's a flag set by lvm2 automatically for snapshot devices: DM_UDEV_LOW_PRIORITY_FLAG
(which I can't find in Debian version of the udev rules). This gives low
priority to snapshot devices while creating symlinks in /dev/disk/by-uuid.
Since only the FS UUID is used as a name here, we need to determinize the
naming and so we try to give preference to origin devices by setting proper
symlink priorities (symlink creation would be prone to races otherwise).

All these flags and synchronization works only in kernels >= 2.6.31.

Message #74 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Miguel Di Ciurcio Filho <miguel.filho@gmail.com>

To: 581339@bugs.debian.org, 549691@bugs.debian.org

Subject: Might be related to udisk daemon

Date: Sun, 5 Sep 2010 12:20:33 -0300

Take a look at this bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=577798#c5

And related thread:

https://www.redhat.com/archives/linux-lvm/2010-August/msg00029.html

I was having the same problem and following the suggestion in the
bugzilla solved the problem.

Message #79 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Daniel Dickinson <daniel@cshore.neomailbox.net>

To: Debian Bug Tracking System <549691@bugs.debian.org>

Subject: lvm2: snapshot claims open when nothing using it; can't be removed

Date: Sun, 20 Feb 2011 17:43:34 -0500

Package: lvm2
Version: 2.02.66-5
Severity: normal


1) Create lvm snapshot of root partition
2) Do backup
3) Unmount
4) lvremove group/volume-snapshot fails claiming open

mount doesn't report it as mounted
/proc/mounts doesn't have an entry for it
it's not swap

dmsetup remove volume--snaphot
and
dmsetup remove volume--snapshot-cow

then 

lvremove group/volume-snapshot

works

But why isn't it working with just lvremove?  It used to work on Lenny (though I wasn't using this backup method for a while so I don't know at what versions it became a problem).

oh, yes, as mentioned

lvchange -an  group/volume-snapshot

fails.

Could a maintainer ask a question I can check the answer to, that would help with the debug?  I suspect some ansychronous event thing is happening with udev or somesuch.



-- System Information:
Debian Release: wheezy/sid
  APT prefers squeeze-updates
  APT policy: (500, 'squeeze-updates'), (500, 'testing'), (100, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lvm2 depends on:
ii  dmsetup                      2:1.02.48-5 The Linux Kernel Device Mapper use
ii  libc6                        2.11.2-11   Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1           2:1.02.48-5 The Linux Kernel Device Mapper use
ii  libreadline5                 5.2-7       GNU readline and history libraries
ii  libudev0                     164-3       libudev shared library
ii  lsb-base                     3.2-27      Linux Standard Base 3.2 init scrip

lvm2 recommends no packages.

lvm2 suggests no packages.

-- no debconf information

Message #84 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Bryce Nesbitt <bryce2@obviously.com>

To: 549691@bugs.debian.org

Subject: See also downstream

Date: Sun, 12 Jun 2011 01:48:26 -0700

https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/656526

Message #89 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 549691@bugs.debian.org

Subject: Re: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Tue, 29 Nov 2011 11:11:33 +0000

Trying not too add too much noise to this bug... I just ran into this
and followed the advice to stop udev, then try to remove the volumes (in
my case they were snapshots created for backup purposes), and it worked.

I'm running stable:

ii  dmsetup                                               2:1.02.48-5
ii  linux-image-2.6.32-5-amd64                            2.6.32-38
ii  lvm2                                                  2.02.66-5
ii  udev                                                  164-3

Is it worth filing a bug against udev for this particular manifestation
of the "Can't remove open logical volume" bug?

Regards,

-- 
Sam Morris <sam@robots.org.uk>

Message #94 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Daniel Dehennin <daniel.dehennin@baby-gnu.org>

To: 549691@bugs.debian.org

Subject: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Sun, 27 May 2012 21:05:04 +0200

[Message part 1 (text/plain, inline)]

Hello,

After reporting[1] the workaround[2] of calling dmsetup directly to
schroot, Roger Leigh suggested me to make a report against LVM2 or udev.

I don't know where the problem is exactly, but on my system the bug in
100% reproductible:

#+begin_src
root@home:~# lvcreate -L2G -s /dev/hati/sid-amd64-sbuild -n test
  Logical volume "test" created

root@home:~# lvremove -f /dev/hati/test
  Unable to deactivate open hati-test-cow (254:15)
  Failed to resume test.
  libdevmapper exiting with 1 device(s) still suspended.
#+end_src

I can do that over and over again.

Any lvscan command ran after the failing hangs until I do:

#+begin_src
root@home:~# dmsetup resume /dev/hati/sid-amd64-sbuild
#+end_src

Ask whatever you want me to test to solve this issue, this makes sbuild
unusable on my system without my proposed workaround patch.

Thanks.

Footnotes: 
[1]  http://bugs.debian.org/674682

[2]  http://bugs.debian.org/549691#57

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF

[Message part 2 (application/pgp-signature, inline)]

Message #99 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 549691@bugs.debian.org

Cc: 549691-subscribe@bugs.debian.org

Subject: snapshot removal fails due to udev

Date: Sun, 3 Jun 2012 12:53:02 +0100

I also have this problem and it's 100% reproduceable.

Peter Rajnoha writes:

  As a quick and rough check, you can try to temporarily kill udev
  daemon and then see if these commands pass. If yes, then this is just
  another instance of quite common error seen where lvm2's udev
  synchronization feature is not used (a device being opened and scanned
  from within udev rules while trying to deactivate it).

How should we go about determining _which_ udev rules are at fault and
what is the correct fix ?  My system is pretty vanilla so whatever it
is it is almost certainly part of the standard Debian install which
should be fixed, perhaps even by a stable update.

Thanks,
Ian.

Message #104 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Serge Pawlowicz <debian@pawlowicz.name>

To: Debian Bug Tracking System <549691@bugs.debian.org>

Subject: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless

Date: Mon, 04 Jun 2012 13:38:02 +0100

Package: lvm2
Version: 2.02.88-2
Followup-For: Bug #549691

1) lvremove does not remove a snapshot, it claims it is being used
2) after unpredictable time and removal attempts, it finally removes the snapshot
3) if i switch off udev, lvremove claims it removes a snapshot, but it does not

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.18-vs2.3.2.9-beng (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lvm2 depends on:
ii  dmsetup             2:1.02.67-2
ii  initscripts         2.88dsf-22.1
ii  libc6               2.13-32
ii  libdevmapper1.02.1  2:1.02.67-2
ii  libreadline5        5.2-11
ii  libudev0            175-3.1
ii  lsb-base            4.1+Debian4

lvm2 recommends no packages.

lvm2 suggests no packages.

-- no debconf information

Message #109 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Serge Pawlowicz <debian@pawlowicz.name>, 549691@bugs.debian.org

Subject: Re: Bug#549691: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless

Date: Mon, 4 Jun 2012 17:03:44 +0200

On Mon, Jun 04, 2012 at 01:38:02PM +0100, Serge Pawlowicz wrote:
> Package: lvm2
> Version: 2.02.88-2

This is not the newest version.

> Kernel: Linux 3.2.18-vs2.3.2.9-beng (SMP w/8 CPU cores)

This is no Debian kernel.

Bastian

-- 
You can't evaluate a man by logic alone.
		-- McCoy, "I, Mudd", stardate 4513.3

Message #114 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Sergiusz Pawlowicz <sergiusz@pawlowicz.name>

To: 549691@bugs.debian.org

Subject: Re: Bug#549691: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless

Date: Tue, 5 Jun 2012 12:26:14 +0100

>> Package: lvm2
>> Version: 2.02.88-2
>
> This is not the newest version.

I have installed the newest one, and the situation is even worse, lvm
freezes, as described in bug #659762.

>> Kernel: Linux 3.2.18-vs2.3.2.9-beng (SMP w/8 CPU cores)
>
> This is no Debian kernel.

I can agree, but it is based on debian kernel, only linux-vserver
features are added.

I would tend to relate the lvm problems with udev, as on squeeze a
similar kernel works perfectly.

S.

Message #119 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Bastian Blank <waldi@debian.org>, 549691@bugs.debian.org

Cc: Serge Pawlowicz <debian@pawlowicz.name>

Subject: Re: Bug#549691: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless

Date: Wed, 6 Jun 2012 11:19:52 +0100

Bastian Blank writes ("Bug#549691: wheezy - we still have that problem, and it is a huge problem, as backup scripts based on snapshots are useless"):
> On Mon, Jun 04, 2012 at 01:38:02PM +0100, Serge Pawlowicz wrote:
> > Package: lvm2
> > Version: 2.02.88-2
> 
> This is not the newest version.
> 
> > Kernel: Linux 3.2.18-vs2.3.2.9-beng (SMP w/8 CPU cores)
> 
> This is no Debian kernel.

Do you think, then, that Serge will get better results if he
switches to a Debian kernel and upgrades lvm2 ?

Thanks,
Ian.

Message #124 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Martin Jürgens <ma@jgs-wg.de>

Cc: 549691@bugs.debian.org

Subject: Re: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Wed, 3 Oct 2012 12:13:17 +0200

Hi,

I have the same problem. lvremove fails to remove snapshot LVs in many
cases (but not 100% of the time).

As a workaround, I am currently using the "dmsetup remove" trick.

What can we do to fix this problem?

Here are the software versions I’m using:

lvm2               2.02.95-4
udev               175-3.1
dmsetup            2:1.02.74-4
libdevmapper1.02.1 2:1.02.74-4
systemd            44-4
linux-image-3.5.0  3.5.0-10.00.Custom (with Debian config)

The machine is an x86_64 AMD Athlon II X2 250.

I don’t have udisks installed, so I don’t have a file called
/lib/udev/rules.d/80-udisks.rules either. The suggested solution
from the RedHat bugzilla therefore is not applicable in my case.

To give a bit more information about how I reproduce this issue:

    lvcreate -n snap_web -L 1G -s plana/domu-web
    kpartx -a /dev/mapper/plana-snap_web
    mount /dev/mapper/plana-snap_web1 /mnt/snap_web

    # Run backup

    umount /mnt/snap_web
    kpartx -d /dev/mapper/plana-snap_web
    lvremove -f plana/snap_web

I have also tried using maximum verbosity and stracing lvremove,
but I don’t understand enough of how lvremove should work to
make any sense out of it (even when comparing the working and
non-working strace output).

Best regards,
Michael

Message #129 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Peter Rajnoha <prajnoha@redhat.com>

To: Michael Stapelberg <stapelberg@debian.org>, 549691@bugs.debian.org

Cc: Martin Jürgens <ma@jgs-wg.de>

Subject: Re: Bug#549691: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Wed, 03 Oct 2012 13:23:57 +0200

On 10/03/2012 12:13 PM, Michael Stapelberg wrote:
> To give a bit more information about how I reproduce this issue:
> 
>     lvcreate -n snap_web -L 1G -s plana/domu-web
>     kpartx -a /dev/mapper/plana-snap_web
...
>     kpartx -d /dev/mapper/plana-snap_web

Please, try "kpartx -s", where -s is for "sync mode" so
all udev processing is synced with kpartx as well.

Peter

Message #134 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Peter Rajnoha <prajnoha@redhat.com>, 549691@bugs.debian.org

Cc: Martin Jürgens <ma@jgs-wg.de>

Subject: Re: Bug#549691: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Wed, 03 Oct 2012 14:24:56 +0200

Hi Peter,

Peter Rajnoha <prajnoha@redhat.com> writes:
> Please, try "kpartx -s", where -s is for "sync mode" so
> all udev processing is synced with kpartx as well.
Thanks for this hint. I added the -s flag, but I can still reproduce the
snapshot removal problem:

lvremove --verbose -f plana/snap_web
    Using logical volume(s) on command line
    Archiving volume group "plana" metadata (seqno 1137).
    Removing snapshot snap_web
    Found volume group "plana"
    Found volume group "plana"
    Loading plana-domu--web table (253:1)
    Loading plana-snap_web table (253:9)
    plana/snapshot0 already not monitored.
    Suspending plana-domu--web (253:1) with device flush
    Suspending plana-snap_web (253:9) with device flush
    Suspending plana-domu--web-real (253:10) with device flush
    Suspending plana-snap_web-cow (253:11) with device flush
    Found volume group "plana"
    Resuming plana-snap_web-cow (253:11)
    Resuming plana-domu--web-real (253:10)
    Resuming plana-snap_web (253:9)
    Removing plana-snap_web-cow (253:11)
    Found volume group "plana"
    Resuming plana-domu--web (253:1)
  Unable to deactivate open plana-domu--web-real (253:10)
  Failed to resume domu-web.


-- 
Best regards,
Michael

Message #139 received at 549691@bugs.debian.org (full text, mbox, reply):

From: "anis.ocellata" <anis.ocellata@gmail.com>

To: 549691@bugs.debian.org

Subject: lvm2: lvremove fails to remove open logical volume which is not opened

Date: Sun, 11 Nov 2012 22:16:54 +0100

Hi,

I probably have the same problem.

It occurs in about 20% of the calls to lvremove,
but can be reproduced reliably using the description bellow.

Symptoms:

$ lvremove vg/lv-snap
Do you really want to remove active logical volume lv-snap? [y/n]: y
  /sbin/dmeventd: stat failed: No such file or directory
  Unable to deactivate open vg-lv-real (254:13)
  Failed to resume lv.
  Node /dev/mapper/vg-lv-snap-cow was not removed by udev. Falling back 
to direct node removal.

The dmeventd bug is unrelated.

Package versions:

wheezy/sid
linux-image-2.6.32-5-686   2.6.32-46
liblvm2app2.2:i386         2.02.95-4
lvm2                       2.02.95-4
libdevmapper1.02.1:i386    2:1.02.74-4
libudev0:i386              175-7
dmsetup                    2:1.02.74-4
udev                       175-7
udisks                     1.0.4-7

Steps to reproduce:

$ dd if=/dev/zero of=/tmp/data bs=1M count=64
$ losetup -f /tmp/data
$ dev="$(losetup -a | sed -n 's@^\(/dev/loop.\).*(/tmp/data)$@\1@p')"
$ vgcreate vg $dev
$ lvcreate -n lv -L 20m vg
$ for i in $(seq 1 50); do echo -n "[$i] "; date; lvcreate -n lvs -L 20m 
-s vg/lv || break; lvremove -f vg/lvs || break; sleep 1; done

Before the fail:

$ dmsetup info -c
Name             Maj Min Stat Open Targ Event  UUID 

vg-lvs-cow      254  11 L--w    1    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADbtS2ezxFQ80z6AyYJQVGrNrBm2KmYdiG-cow
vg-lv-real      254  10 L--w    2    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADPedDWlTT8u7iGzBUJatBw7XCaCJ2tazL-real
vg-lv           254   8 L--w    0    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADPedDWlTT8u7iGzBUJatBw7XCaCJ2tazL
vg-lvs          254   9 L--w    0    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADbtS2ezxFQ80z6AyYJQVGrNrBm2KmYdiG
$ dmsetup ls --tree
vg-lv (254:8)
 └─vg-lv-real (254:10)
    └─ (7:2)
vg-lvs (254:9)
 ├─vg-lv-real (254:10)
 │  └─ (7:2)
 └─vg-lvs-cow (254:11)
    └─ (7:2)
$ dmsetup table
vg-lvs-cow: 0 24576 linear 7:2 43008
vg-lv-real: 0 40960 linear 7:2 2048
vg-lv: 0 40960 snapshot-origin 254:10
vg-lvs: 0 40960 snapshot 254:10 254:11 P 8

After the fail:

$ dmsetup info -c
Name             Maj Min Stat Open Targ Event  UUID 

vg-lv-real      254  10 L--w    0    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADPedDWlTT8u7iGzBUJatBw7XCaCJ2tazL-real
vg-lv           254   8 L--w    0    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADPedDWlTT8u7iGzBUJatBw7XCaCJ2tazL
vg-lvs          254   9 L--w    0    1      0 
LVM-VXLpQ9Kays4OYlk4sa3YBygqFDzMXZADwd2xkixwuc6xoErS15OFrK22jInum17j
$ dmsetup ls --tree
vg-lv-real (254:10)
 └─ (7:2)
vg-lv (254:8)
 └─ (7:2)
vg-lvs (254:9)
 └─ (7:2)
$ dmsetup table
vg-lv-real: 0 40960 linear 7:2 2048
vg-lv: 0 40960 linear 7:2 2048
vg-lvs: 0 24576 linear 7:2 43008

Commenting out
> KERNEL=="dm-*", OPTIONS+="watch"
from /lib/udev/rules.d/80-udisks.rules didn't help, but stopping the 
udev daemon removes the symptoms.

Does anybody have at least a reasonable workaround?

Thanks.

Message #144 received at 549691@bugs.debian.org (full text, mbox, reply):

From: James Robertson <j@mesrobertson.com>

To: 549691@bugs.debian.org

Date: Wed, 21 Aug 2013 10:34:54 +1000

I am using a new up to date Wheezy system and was having very poor
success with lvmremove - specifically with mylvmbackup.  I needed this
to be reliable and it was probably failing roughly 70-80% of the time.

As a test I built the version in Sid (as of 21/08/2013) on my Wheezy
machine and this appears to have solved it.

I elaborated on Anis' test as follows so I could emulate closely what
mylvmbackup was doing

#!/bin/bash

for i in $(seq 1 50) ; do
    echo -n "[$i] "
    date
    lvcreate -n mysql_snapshot -L 512m -s vgedJY67/mysql || break
    mount /dev/vgedJY67/mysql_snapshot /mnt/mysql_snapshot && echo
"Mounted /mnt/mysql_snapshot" || break
    tar -czf /tmp/mysql.tar.gz /mnt/mysql_snapshot 2> /dev/null &&
echo "Backed up MYSQL" || break
    umount /mnt/mysql_snapshot && echo "Unmounted /mnt/mysql_snapshot" || break
    lvremove -f vgedJY67/mysql_snapshot || break
    sleep 1
done

Using the version in Wheezy I ran this script 10 times and the
furthest it got was to the 3rd loop with it mostly failing on the 1st!
 Terrible...

After using the Sid version (after a reboot) it seems to work 100%.  I
decided to up the retries of the loop to 500 just to be certain.  It
passed all 500... Great!


-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lvm2 depends on:
ii  dmsetup                   2:1.02.77-5.jamesr1
ii  initscripts               2.88dsf-41
ii  libc6                     2.13-38
ii  libdevmapper-event1.02.1  2:1.02.77-5.jamesr1
ii  libdevmapper1.02.1        2:1.02.77-5.jamesr1
ii  libreadline5              5.2+dfsg-2~deb7u1
ii  libudev0                  175-7.2
ii  lsb-base                  4.1+Debian8+deb7u1


-- Versions:

> apt-cache policy libdevmapper1.02.1 libdevmapper-event1.02.1 dmsetup lvm2
libdevmapper1.02.1:
  Installed: 2:1.02.77-5.jamesr1
  Candidate: 2:1.02.77-5.jamesr1
  Version table:
 *** 2:1.02.77-5.jamesr1 0
        100 /var/lib/dpkg/status
     2:1.02.74-7 0
        500 http://ftp.iinet.net.au/debian/debian/ wheezy/main amd64 Packages
libdevmapper-event1.02.1:
  Installed: 2:1.02.77-5.jamesr1
  Candidate: 2:1.02.77-5.jamesr1
  Version table:
 *** 2:1.02.77-5.jamesr1 0
        100 /var/lib/dpkg/status
     2:1.02.74-7 0
        500 http://ftp.iinet.net.au/debian/debian/ wheezy/main amd64 Packages
dmsetup:
  Installed: 2:1.02.77-5.jamesr1
  Candidate: 2:1.02.77-5.jamesr1
  Version table:
 *** 2:1.02.77-5.jamesr1 0
        100 /var/lib/dpkg/status
     2:1.02.74-7 0
        500 http://ftp.iinet.net.au/debian/debian/ wheezy/main amd64 Packages
lvm2:
  Installed: 2.02.98-5.jamesr1
  Candidate: 2.02.98-5.jamesr1
  Version table:
 *** 2.02.98-5.jamesr1 0
        100 /var/lib/dpkg/status
     2.02.95-7 0
        500 http://ftp.iinet.net.au/debian/debian/ wheezy/main amd64 Packages

Message #149 received at 549691@bugs.debian.org (full text, mbox, reply):

From: James Robertson <j@mesrobertson.com>

To: 549691@bugs.debian.org

Date: Mon, 30 Sep 2013 14:06:40 +1000

I just wanted to add some more information to this report.

My previous report was based on a VMware VM.  I re-tested again on
this server with and without VMware tools installed and got the same
results.

I recently installed a physical server with Debian Wheezy configured
with a software RAID10 on some 6G SAS disks.  Using the LVM2 packages
from Wheezy I ran the same loop test on this system and it was more
reliable but eventually failed at loop 266 when I ran it for 500
loops.  I built LVM2 from Testing (2.02.98-6) and it was able to pass
all 500 loops.

I also recently installed a new VMware VM on a different server and
Using the LVM2 packages from Wheezy but it ran all 500 loops
successfully??  No idea why this would work where the other 2 systems
didn't.

Message #154 received at 549691@bugs.debian.org (full text, mbox, reply):

From: Charles Taylor <chtaylor@gleim.com>

To: 549691@bugs.debian.org

Date: Tue, 17 Dec 2013 09:52:57 -0500

We are also experiencing this problem, and have for some time.

The fact that this bug has been allowed to exist for over 4 years in a
key server package is absolutely unacceptable, and is a black mark on
the whole of Debian.

Will someone please explain to the community why this hasn't been
fixed????

Message #159 received at 549691@bugs.debian.org (full text, mbox, reply):

From: James Robertson <j@mesrobertson.com>

To: 549691@bugs.debian.org

Cc: chtaylor@gleim.com

Date: Thu, 2 Jan 2014 11:51:15 +1100

I have been using my own backported version of LVM2 from testing on
all my Wheezy systems and the problem is gone for me.

I created a guide here if you want to backport yourself until someone
from Debian resolves the issue Wheezy.

http://wiki.bitbinary.com/index.php/LVM2_Backport_Debian_Wheezy

Message #164 received at 549691@bugs.debian.org (full text, mbox, reply):

From: George Tellalov <gtellalov@bigfoot.com>

To: Debian Bug Tracking System <549691@bugs.debian.org>

Subject: lvm2: More info: how to reproduce and fix

Date: Tue, 03 Jun 2014 12:56:06 +0000

Package: lvm2
Followup-For: Bug #549691

I had a problem with LVM refusing to remove a volume that wasn't in use and my
search led me to this bug report. Here I found out about dmsetup and playing
around with it I managed to remove the problematic volume. Here's how I did
it (on a pure wheezy install). 

First a way to reproduce the problem:

# lvcreate -n test -L 100M hdd
  Logical volume "test" created

# parted -s /dev/hdd/test mklabel msdos mkpart pri 32256b 100M
Warning: The resulting partition is not properly aligned for best performance.

# lvchange -a n hdd/test
  Logical volume hdd/test is used by another device.

This is it - nothing is mounted or accessed by any programs. Actually the
partition doesn't even have a file system to be mounted.

The problem seems to be that device mapper creates a device file for the new
partition and because of it the volume "test" is considered in use.

# dmsetup ls | grep test
hdd-test        (254:4)
hdd-testp1      (254:5)

And the solution is to remove the partition device and then the volume can be
deactivated and removed as well.

# dmsetup remove hdd-testp1
# lvchange -a n hdd/test
# lvremove hdd/test
  Logical volume "test" successfully removed

I'm not sure if this is related to the original bug report, but some of the
users' reports are probably related. I hope this helps.


-- System Information:
Debian Release: 7.5
Architecture: armhf (armv6l)

Kernel: Linux 3.6.11+ (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #179 received at 549691-done@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: 549691-done@bugs.debian.org

Subject: fixed

Date: Thu, 13 Aug 2015 08:48:01 +0000

All the snapshot related race conditions have been fixed quite some time
ago, closing.

Bastian

-- 
Is truth not truth for all?
		-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.

Send a report that this bug log contains spam.