LVM unusable after uncleanly unplugging USB disk

[Dennis Noordsij]

Binary package hint: lvm2

When a disk containing an active LVM volume has been removed without properly closing the LVM volume first, LVM becomes unusable as the LVM mapping entries remain active but can never be closed anymore since the disk is gone.

ls -al /dev/mapper/
totaal 0
drwxr-xr-x 2 root root 180 2008-04-27 19:55 .
drwxr-xr-x 15 root root 14880 2008-04-28 12:21 ..
crw-rw---- 1 root root 10, 63 2008-04-27 21:53 control
brw-rw---- 1 root disk 254, 5 2008-04-27 19:55 encrypted-debian
brw-rw---- 1 root disk 254, 4 2008-04-27 19:55 encrypted-swap
brw-rw---- 1 root disk 254, 3 2008-04-27 19:55 luks_crypto_1c95cbac-b4a3-436e-9d75-56f8ff2d8947

luks_crypto_XXX is the partition on the USB disk. encrypted-debian and encrypted-swap are the LVM volumes which were enabled with vgchange -a y

Then, the disk was removed (perhaps laptop suspended, disk removed when packing it, laptop resumed, it's easy to accidentally unplug),

> vgchange -a n

  /dev/mapper/luks_crypto_1c95cbac-b4a3-436e-9d75-56f8ff2d8947: read failed after 0 of 4096 at 92643786752: Invoer-/uitvoerfout
  /dev/mapper/luks_crypto_1c95cbac-b4a3-436e-9d75-56f8ff2d8947: read failed after 0 of 4096 at 0: Invoer-/uitvoerfout
  /dev/encrypted/swap: read failed after 0 of 4096 at 805240832: Invoer-/uitvoerfout
  /dev/encrypted/swap: read failed after 0 of 4096 at 0: Invoer-/uitvoerfout
  /dev/encrypted/debian: read failed after 0 of 4096 at 90760478720: Invoer-/uitvoerfout
  /dev/encrypted/debian: read failed after 0 of 4096 at 0: Invoer-/uitvoerfout

So there is no real way to get rid of these anymore, and re-plugging this disk does not try to mount the Luks partition anymore. The only real way out is to reboot.

What should happen: the disk is not going to come back in the original mounted state, ever again. LVM should just forget about it, discard whatever is there, either automatically (preferred) or through a commandline switch (which would ideally be done directly by Ubuntu when one unplugs such a disk).

[Phillip Susi (psusi)]

I believe this is a design defect of the upstream lvm and likely won't be resolved any time soon. As a workaround, you should be able to destroy the rogue mappings with dmsetup.

[Leo (leorolla)]

This bug affects me too.

I marked other packages since they could contain a workaround for this problem themselves.

Perhaps:

? Let non-root users remove the LVM after checking that the corresponding physical device is absent.
? Not try to create the /dev/mapper/udisks-luks-uuid-xxxxxxxxxx when the disk is re-plugged generating an error message. Instead use the folder already there.
? Not try to create the /dev/mapper/udisks-luks-uuid-xxxxxxxxxx when the disk is re-plugged generating an error message. First delete it and then re-create it.
? Who knows...

[RW Penney (rwpenney)]

This is more of a feature request than a bug in cryptmount.
As already noted, the original source of the problem seems to be the behaviour of the LVM system.

[Leo (leorolla)]

Workaround:

sudo dmsetup remove /dev/mapper/udisks-luks-uuid-xxxxxxxxxx

It seems to have been fixed upstream. Source:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554600

[ciiccii (theguns)]

I have the same problem. The workaround provided by Leo is not working for me, because /dev/mapper/ does not contain the right uuid anymore.

 ls /dev/mapper/ -l
total 0
crw-rw---- 1 root root 10, 59 2010-08-25 14:15 control

The curios thing is, if i look into "Disk Utility" i can see that usb-device is in /dev/mapper-udisks-luks-uuid-***************************** . So, if i connect my usb-hdd i get the window which is asking me for a pass-phrase, and then i get the message, that one device with the same uuid is already present, but it's not true. Any ideas how i can avoid this without reboot?

[Jean-Louis Dupond (dupondje)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - Precise Pangolin. It won't be fixed in previous versions of Ubuntu because the package doesn't fit the requirements for backporting. See https://help.ubuntu.com/community/UbuntuBackports for more information.