Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
With recent udev you can try add workaround I tried to write here https://bugzilla.redhat.com/attachment.cgi?id=431413 (from Fedora equivalent bug https://bugzilla.redhat.com/show_bug.cgi?id=613909 ) Thanks, Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
On 07/09/2010 03:26 PM, Jonas Meurer wrote: Hey again, On 09/07/2010 Milan Broz wrote: On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote: # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. Ha! So finally the debug code found something locking the device! :-) HAL _must_ _not_ open temporary-cryptsetup device. It can scan final device but not the temporary one. (udev/udisks have this solved, I thought hal uses the same...) Maybe it is not the real problem but please fix hal too here. I discussed that with the hal maintainer. Hal already has a workaround to ignore temporary-cryptsetup-* devices (in hald/linux/osspec.c). The problem here seems to be that hal probes /dev/dm-4, and not the temporary-cryptsetup device. and the workaround doesn't ignore that one. so, Giorgos, please temporarily disable hal (/etc/init.d/hal stop), and see whether the issue disappears. In that case, hal is the problem for sure. But then still the problem is, how should hal distinguish temporary cryptsetup devices reliably, when '/dev/dm-X' is used? Milan, is there any better/cheaper solution than a lookup for symlinks in /dev/mapper/*? greetings, jonas Hi Jonas. Indeed, with hal stopped, the issue disappears: mordor:/home/gpall# cryptsetup --debug luksOpen /dev/sdb2 dataspace_crypt # cryptsetup 1.1.2 processing cryptsetup --debug luksOpen /dev/sdb2 dataspace_crypt # Locking memory. # Allocating crypt device /dev/sdb2 context. # Trying to open and read device /dev/sdb2. # Initialising device-mapper backend, UDEV is enabled. # Detected dm-crypt target of version 1.7.0. # Timeout set to 0 miliseconds. # Password retry count set to 3. # Iteration time set to 1000 miliseconds. # Password verification disabled. # Trying to load LUKS1 crypt type from device /dev/sdb2. # Initializing crypto backend (using secure memory). # Reading LUKS header of size 1024 from device /dev/sdb2 # Activating volume dataspace_crypt [keyslot -1] using [none] passphrase. # dm status dataspace_crypt OF [16384] Enter passphrase for /dev/sdb2: # Trying to open key slot 0 [1]. # Trying to open key slot 1 [3]. # Reading key slot 1 area. # DM-UUID is CRYPT-TEMP-temporary-cryptsetup-3744 # Udev cookie 0xd4d1bcb (semid 1081344) created # Udev cookie 0xd4d1bcb (semid 1081344) incremented # Udev cookie 0xd4d1bcb (semid 1081344) incremented # Udev cookie 0xd4d1bcb (semid 1081344) assigned to dm_task type 0 with flags 0xe # dm create temporary-cryptsetup-3744 CRYPT-TEMP-temporary-cryptsetup-3744 OF [16384] # temporary-cryptsetup-3744: Stacking NODE_ADD (254,4) 0:6 0660 # dm reload temporary-cryptsetup-3744 OF [16384] # dm resume temporary-cryptsetup-3744 OF [16384] # temporary-cryptsetup-3744: Stacking NODE_READ_AHEAD 256 (flags=1) # Udev cookie 0xd4d1bcb (semid 1081344) decremented # Udev cookie 0xd4d1bcb (semid 1081344): Waiting for zero # Udev cookie 0xd4d1bcb (semid 1081344) destroyed # temporary-cryptsetup-3744: read ahead is 256 # temporary-cryptsetup-3744: Setting read ahead to 256 # Udev cookie 0xd4d61a6 (semid 1114112) created # Udev cookie 0xd4d61a6 (semid 1114112) incremented # Udev cookie 0xd4d61a6 (semid 1114112) incremented # Udev cookie 0xd4d61a6 (semid 1114112) assigned to dm_task type 2 with flags 0x0 # dm remove temporary-cryptsetup-3744 OF [16384] # temporary-cryptsetup-3744: Stacking NODE_DEL (replaces other stacked ops) # Udev cookie 0xd4d61a6 (semid 1114112) decremented # Udev cookie 0xd4d61a6 (semid 1114112): Waiting for zero # Udev cookie 0xd4d61a6 (semid 1114112) destroyed Key slot 1 unlocked. # Calculated device size is 167973584 sectors (RW), offset 2056. # DM-UUID is CRYPT-LUKS1-b63c55b1055d47fb850bb733993f555b-dataspace_crypt # Udev cookie 0xd4dca41 (semid 1146880) created # Udev cookie 0xd4dca41 (semid 1146880) incremented # Udev cookie 0xd4dca41 (semid 1146880) incremented # Udev cookie 0xd4dca41 (semid 1146880) assigned to dm_task type 0 with flags 0x0 # dm create dataspace_crypt CRYPT-LUKS1-b63c55b1055d47fb850bb733993f555b-dataspace_crypt OF [16384] # dataspace_crypt: Stacking NODE_ADD (254,4) 0:6 0660 # dm reload dataspace_crypt OF [16384] # dm resume dataspace_crypt OF [16384] # dataspace_crypt: Stacking NODE_READ_AHEAD 256 (flags=1) # Udev cookie 0xd4dca41 (semid 1146880) decremented # Udev cookie 0xd4dca41 (semid 1146880): Waiting for zero # Udev cookie 0xd4dca41 (semid 1146880) destroyed # dataspace_crypt: read ahead is 256 # dataspace_crypt: Setting read ahead to 256 # Releasing crypt device /dev/sdb2 context. # Releasing device-mapper backend. # Unlocking memory. Command successful. mordor:/home/gpall# -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
reassign 586286 hal thanks On 10/07/2010 Γιώργος Πάλλας wrote: On 07/09/2010 03:26 PM, Jonas Meurer wrote: On 09/07/2010 Milan Broz wrote: On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote: # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. Ha! So finally the debug code found something locking the device! :-) HAL _must_ _not_ open temporary-cryptsetup device. It can scan final device but not the temporary one. (udev/udisks have this solved, I thought hal uses the same...) Maybe it is not the real problem but please fix hal too here. I discussed that with the hal maintainer. Hal already has a workaround to ignore temporary-cryptsetup-* devices (in hald/linux/osspec.c). The problem here seems to be that hal probes /dev/dm-4, and not the temporary-cryptsetup device. and the workaround doesn't ignore that one. so, Giorgos, please temporarily disable hal (/etc/init.d/hal stop), and see whether the issue disappears. In that case, hal is the problem for sure. Indeed, with hal stopped, the issue disappears: So this is a bug in hal. Thus reassigning the bugreport to package hal. It seems like hal properly ignored /dev/mapper/cryptsetup-temporary-* devices, but still probes /dev/dm-X devices which are temporary cryptsetup devices. That needs to be fixed. As Milan already pointed out in an earlier mail, a proper fix (for recent kernels) would be to read /sys/block/dm-X/dm/name in hald/linux/osspec.c, check whether that translates to 'cryptsetup-temporary-*', and ignore the device in that case as well. greetings, jonas signature.asc Description: Digital signature
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
On 07/08/2010 12:23 PM, Jonas Meurer wrote: Hey Giorgos, On 18/06/2010 Giorgos Pallas wrote: I am experiencing a reproducable behaviour everytime I unlock a LUKS partition (unrelated with booting). So: aris:/home/encmp/gpall# cryptsetup luksOpen /dev/sdb4 dataspace_crypt Enter passphrase for /dev/sdb4: device-mapper: remove ioctl failed: Device or resource busy At the same time something like: Jun 18 09:35:40 aris kernel: [ 4210.586137] device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433 appears at the kernel messages. can you provide the output of 'cryptsetup --debug luksOpen ...'? Thanks for the good job with cryptsetup!!! would you mind giving preliminary 2:1.1.3-1 packages a try to see whether that changes anything? you can find the packages at http://people.debian.org/~mejo/cryptsetup/ greetings, jonas Hello Jonas, I'm sending you the output requested: mordor:~/proj/cryptsetup-bug# cryptsetup --version cryptsetup 1.1.2 mordor:~/proj/cryptsetup-bug# cryptsetup --debug luksOpen /dev/sdb2 dataspace_crypt # cryptsetup 1.1.2 processing cryptsetup --debug luksOpen /dev/sdb2 dataspace_crypt # Locking memory. # Allocating crypt device /dev/sdb2 context. # Trying to open and read device /dev/sdb2. # Initialising device-mapper backend, UDEV is enabled. # Detected dm-crypt target of version 1.7.0. # Timeout set to 0 miliseconds. # Password retry count set to 3. # Iteration time set to 1000 miliseconds. # Password verification disabled. # Trying to load LUKS1 crypt type from device /dev/sdb2. # Initializing crypto backend (using secure memory). # Reading LUKS header of size 1024 from device /dev/sdb2 # Activating volume dataspace_crypt [keyslot -1] using [none] passphrase. # dm status dataspace_crypt OF [16384] Enter passphrase for /dev/sdb2: # Trying to open key slot 0 [1]. # Trying to open key slot 1 [3]. # Reading key slot 1 area. # DM-UUID is CRYPT-TEMP-temporary-cryptsetup-18450 # Udev cookie 0xd4dfa3d (semid 917505) created # Udev cookie 0xd4dfa3d (semid 917505) incremented # Udev cookie 0xd4dfa3d (semid 917505) incremented # Udev cookie 0xd4dfa3d (semid 917505) assigned to dm_task type 0 with flags 0xe # dm create temporary-cryptsetup-18450 CRYPT-TEMP-temporary-cryptsetup-18450 OF [16384] # temporary-cryptsetup-18450: Stacking NODE_ADD (254,4) 0:6 0660 # dm reload temporary-cryptsetup-18450 OF [16384] # dm resume temporary-cryptsetup-18450 OF [16384] # temporary-cryptsetup-18450: Stacking NODE_READ_AHEAD 256 (flags=1) # Udev cookie 0xd4dfa3d (semid 917505) decremented # Udev cookie 0xd4dfa3d (semid 917505): Waiting for zero # Udev cookie 0xd4dfa3d (semid 917505) destroyed # temporary-cryptsetup-18450: read ahead is 256 # temporary-cryptsetup-18450: Setting read ahead to 256 # Udev cookie 0xd4d3f6c (semid 950273) created # Udev cookie 0xd4d3f6c (semid 950273) incremented # Udev cookie 0xd4d3f6c (semid 950273) incremented # Udev cookie 0xd4d3f6c (semid 950273) assigned to dm_task type 2 with flags 0x0 # dm remove temporary-cryptsetup-18450 OF [16384] device-mapper: remove ioctl failed: Device or resource busy # Udev cookie 0xd4d3f6c (semid 950273) decremented # Udev cookie 0xd4d3f6c (semid 950273) decremented # Udev cookie 0xd4d3f6c (semid 950273): Waiting for zero # Udev cookie 0xd4d3f6c (semid 950273) destroyed # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. # dm reload temporary-cryptsetup-18450 NF [16384] # Udev cookie 0xd4d58f7 (semid 983041) created # Udev cookie 0xd4d58f7 (semid 983041) incremented # Udev cookie 0xd4d58f7 (semid 983041) incremented # Udev cookie 0xd4d58f7 (semid 983041) assigned to dm_task type 5 with flags 0x0 # dm resume temporary-cryptsetup-18450 OF [16384] # Udev cookie 0xd4d58f7 (semid 983041) decremented # Udev cookie 0xd4d58f7 (semid 983041): Waiting for zero # Udev cookie 0xd4d58f7 (semid 983041) destroyed # Udev cookie 0xd4d1219 (semid 1015809) created # Udev cookie 0xd4d1219 (semid 1015809) incremented # Udev cookie 0xd4d1219 (semid 1015809) incremented # Udev cookie 0xd4d1219 (semid 1015809) assigned to dm_task type 2 with flags 0x0 # dm remove temporary-cryptsetup-18450 OF [16384] # temporary-cryptsetup-18450: Stacking NODE_DEL (replaces other stacked ops) # Udev cookie 0xd4d1219 (semid 1015809) decremented # Udev cookie 0xd4d1219 (semid 1015809): Waiting for zero # Udev cookie 0xd4d1219 (semid 1015809) destroyed Key slot 1 unlocked. # Calculated device size is 167973584 sectors (RW), offset 2056. # DM-UUID is CRYPT-LUKS1-b63c55b1055d47fb850bb733993f555b-dataspace_crypt # Udev cookie 0xd4d401a (semid 1048577) created # Udev cookie 0xd4d401a (semid 1048577) incremented # Udev cookie 0xd4d401a (semid 1048577) incremented # Udev cookie 0xd4d401a (semid 1048577) assigned to dm_task type 0 with flags 0x0 # dm create
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote: # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. Ha! So finally the debug code found something locking the device! :-) HAL _must_ _not_ open temporary-cryptsetup device. It can scan final device but not the temporary one. (udev/udisks have this solved, I thought hal uses the same...) Maybe it is not the real problem but please fix hal too here. Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
On 07/09/2010 10:59 AM, Milan Broz wrote: On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote: # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. Ha! So finally the debug code found something locking the device! :-) HAL _must_ _not_ open temporary-cryptsetup device. It can scan final device but not the temporary one. (udev/udisks have this solved, I thought hal uses the same...) Maybe it is not the real problem but please fix hal too here. Milan So, should I file this bug to hal package? I'm running version 0.5.14-2 (latest in debian testing) Or will you reassign this bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
Hey again, On 09/07/2010 Milan Broz wrote: On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote: # WARNING: other process locked internal device temporary-cryptsetup-18450, retrying remove. # WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)] spying on internal device /dev/dm-4. Ha! So finally the debug code found something locking the device! :-) HAL _must_ _not_ open temporary-cryptsetup device. It can scan final device but not the temporary one. (udev/udisks have this solved, I thought hal uses the same...) Maybe it is not the real problem but please fix hal too here. I discussed that with the hal maintainer. Hal already has a workaround to ignore temporary-cryptsetup-* devices (in hald/linux/osspec.c). The problem here seems to be that hal probes /dev/dm-4, and not the temporary-cryptsetup device. and the workaround doesn't ignore that one. so, Giorgos, please temporarily disable hal (/etc/init.d/hal stop), and see whether the issue disappears. In that case, hal is the problem for sure. But then still the problem is, how should hal distinguish temporary cryptsetup devices reliably, when '/dev/dm-X' is used? Milan, is there any better/cheaper solution than a lookup for symlinks in /dev/mapper/*? greetings, jonas signature.asc Description: Digital signature
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
On 07/09/2010 02:26 PM, Jonas Meurer wrote: But then still the problem is, how should hal distinguish temporary cryptsetup devices reliably, when '/dev/dm-X' is used? Milan, is there any better/cheaper solution than a lookup for symlinks in /dev/mapper/*? this is infamous change which was reguired by udev (/dev/mapper/xyz is now symlink to /dev/dm-X node) HAL cat translate it to real name: - with recent kernel (I think 2.6.31, not sure now) you can simple read /sys/block/dm-X/dm/name also DM UUID should start with CRYPT-TEMP-* inside udev rule it should have defined in some variable also (DM_NAME, DM_UUID) There is similar code in util-linux-ng (mount) which prefers /dev/mapper name before displaying /dev/dm-X. I think using /sys/blocks/*/dm/name is simple - if you can ignore old kernels:) Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586286: [pkg-cryptsetup-devel] Bug#586286: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433
Hey Giorgos, On 18/06/2010 Giorgos Pallas wrote: I am experiencing a reproducable behaviour everytime I unlock a LUKS partition (unrelated with booting). So: aris:/home/encmp/gpall# cryptsetup luksOpen /dev/sdb4 dataspace_crypt Enter passphrase for /dev/sdb4: device-mapper: remove ioctl failed: Device or resource busy At the same time something like: Jun 18 09:35:40 aris kernel: [ 4210.586137] device-mapper: ioctl: unable to remove open device temporary-cryptsetup-3433 appears at the kernel messages. can you provide the output of 'cryptsetup --debug luksOpen ...'? Thanks for the good job with cryptsetup!!! would you mind giving preliminary 2:1.1.3-1 packages a try to see whether that changes anything? you can find the packages at http://people.debian.org/~mejo/cryptsetup/ greetings, jonas signature.asc Description: Digital signature
