dmsetup rename sometimes creates new device name but does not remove original device name

Bug #612310 reported by Daniel Kauffman on 2010-08-01
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
lvm2 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: lvm2

Running dmsetup rename sometimes creates a new device name but does not remove the original device name.

The behavior is observed when dmsetup rename is called from cryptdisks_start ... perhaps there is a timing issue when decrypting encrypted devices?

# ls /dev/mapper <--- encrypted devices are not present

# cryptdisks_start CRYPT <--- encrypted device is described in crypttab
Starting crypto disk...
CRYPT (starting)...
Key slot unlocked.
CRYPT (started)... [ OK ] <--- encrypted device has been mapped and renamed using dmsetup

# ls /dev/mapper
CRYPT_unformatted CRYPT <--- however, note that the intermediate device name is still present after being renamed

# dmsetup info CRYPT_unformatted
Device does not exist.
Command failed

# dmsetup info CRYPT
Name: CRYPT
State: ACTIVE
...<snip>...

# dmsetup remove CRYPT_unformatted
device-mapper: remove ioctl failed: No such device or address
Command failed

# rm CRYPT_unformatted <--- this succeeds in removing the intermediate device name

# dmsetup rename CRYPT CRYPT2 <--- when run from command line after cryptdisk_start has finished, this succeeds

This seems to be the cause of bug 502665, itself a regression from bug 475936.

I would be happy to provide additional information that would be helpful for resolving this.

Daniel Kauffman (sound-man-dan) wrote :

When a device is being renamed, if it is currently in use, the new device name is created but old device name is not removed. The attached forces cryptdisks_start to wait until it is safe to rename the device. In my case, the delay is typically about one second.

The attached is only a work-around, it seems to me that similar logic would be better suited somewhere in dmsetup.

tags: added: patch
Alasdair G. Kergon (agk2) wrote :

Might be udev-rule-related. See if works OK with current upstream, or in an independent (i.e. not Debian-based) distribution with up-to-date packages.

Daniel Kauffman (sound-man-dan) wrote :

Since filing the original report, I've migrated to Debian 6.0 Squeeze; in that environment, dmsetup is successfully run from /lib/cryptsetup/cryptdisks.functions *without* the above patch, that is, cryptsetup works by default.

Note that the patch (see comment #1) simply adds a short delay to /lib/cryptsetup/cryptdisks.functions. Therefore, I do not know whether the bug has been fixed (or was ever present) on Debian 6.0 or whether the bug is merely masked by a change in the timing of startup events, in which case the bug may possibly reappear.

Working system (for me) is running the following versions:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0 (squeeze)
Release: 6.0
Codename: squeeze

$ uname -a
Linux powerbox 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux

$ dmsetup --version
Library version: 1.02.48 (2010-05-20)
Driver version: 4.15.0

$ lvm version
LVM version: 2.02.66(2) (2010-05-20)
Library version: 1.02.48 (2010-05-20)
Driver version: 4.15.0

$ cryptsetup --version
cryptsetup 1.1.3

$ udevd --version
164

If the bug is still present on Ubuntu, the Debian configuration may offer some clues for resolving it.

Daniel,

did you change from using UUIDs to using /dev/mapper/ links in your /etc/fstab ?

UUIDs are nowadays unsupported for file systems on crypt devices.

See https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/719563.

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

Other bug subscribers