cryptsetup

LVM unusable after uncleanly unplugging USB disk

Bug #223583 reported by Dennis Noordsij
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cryptsetup
Confirmed
Undecided
Unassigned
cryptmount (Ubuntu)
Confirmed
Undecided
Unassigned
cryptsetup (Ubuntu)
Fix Released
Undecided
Unassigned
lvm2 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

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

Revision history for this message
Phillip Susi (psusi) wrote :

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.

Changed in lvm2 (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Leo (leorolla) wrote :

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

Changed in cryptmount (Ubuntu):
status: New → Confirmed
Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
RW Penney (rwpenney) wrote :

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.

Revision history for this message
Leo (leorolla) wrote :

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

Leo (leorolla)
Changed in cryptsetup:
status: New → Confirmed
Revision history for this message
ciiccii (theguns) wrote :

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?

Revision history for this message
Jean-Louis Dupond (dupondje) wrote :

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.

Changed in cryptsetup (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.