Launchpad has imported 11 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=574933.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-03-18T20:50:39+00:00 Saikat wrote: Steps to reproduce: 1) Insert a USB stick with an encrypted partition 3) Pull out the USB stick 4) Intert the USB stick again Result: GNOME displays a dialog for the password. Once submitted, the following error comes up: Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists This is due to the mapping being Opened when the stick is first inserted, but never closed, which creates a conflict. Workaround: Do the following to resolve the conflict of the existing device in /dev/mapper. $ ls -al /dev/mapper (Identify the mount point for your drive, "sudo blkid" may help) $ sudo cryptsetup luksClose devkit-disks-luks-uuid-<uuid>-uid1000 What is expected: Someone (e.g. cryptsetup) should "cryptsetup luksClose" when it detects an old mapped device can no longer be accessed (perhaps in response to the same device being plugged in again). Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/6 ------------------------------------------------------------------------ On 2010-03-18T21:58:04+00:00 Milan wrote: Well, the problem is exacltly defined. But if devkit-disks/udisks create the mapping in reaction of inserting device event, it should also handle removal of device. Maybe I can add some --force option to cryptsetup, which remove all existing (or dead) crypt mapping of previous instance of newly appeared device. But cryptsetup cannot handle - force unmounting possible FS (it is another level, cryptsetup have no idea about FS) - trigger any event on device removal (cryptsetup is just binary to create mapping, someone must add some rule which run it - here udisks I guess?) I am reassigning this to udisks, but there is probably some part where cryptsetup can help, not sure. Please let me know if you have such request... Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/7 ------------------------------------------------------------------------ On 2010-03-18T22:06:27+00:00 Till wrote: pam_mount contains a helper program to cleanly mount/umount luks devices. Maybe you can use it for udisk, too. E.g. mount /dev/foo /mnt/foo will open it and ask for a passphrase, umount /mnt/foo will umount it and close the cryptsetup device if pam_mount is installed. Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/8 ------------------------------------------------------------------------ On 2010-03-18T22:32:00+00:00 David wrote: (In reply to comment #1) > Well, the problem is exacltly defined. > > But if devkit-disks/udisks create the mapping in reaction of inserting device > event, it should also handle removal of device. Right - I thought we already handled the force_unmount + luks_teardown but perhaps it broke some time ago. Anyway, the general problem is tracked here http://bugs.freedesktop.org/show_bug.cgi?id=24279 and it asks to automatically Do The Right Thing(tm) for devices set up via udisks (and only for devices set up via udisks). (And if I've learned anything the past half decade where I've been working on these things... is that it can be very dangerous to automatically do things like this (the same way that it's very dangerous to automount and autoassemble based on signatures). So that's why I'm keen on automatically cleaning up only after things set up via udisks.) > Maybe I can add some --force option to cryptsetup, which remove all existing > (or dead) crypt mapping of previous instance of newly appeared device. > > But cryptsetup cannot handle > - force unmounting possible FS (it is another level, cryptsetup have no idea > about FS) > - trigger any event on device removal (cryptsetup is just binary to create > mapping, someone must add some rule which run it - here udisks I guess?) > > I am reassigning this to udisks, but there is probably some part where > cryptsetup can help, not sure. Please let me know if you have such request... > I think it's probably wrong to make cryptsetup, mount, mdadm, lvm etc. worry about this - such cleaning up is generally considered "policy". Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/9 ------------------------------------------------------------------------ On 2010-07-30T11:06:45+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/18 ------------------------------------------------------------------------ On 2010-09-15T02:47:39+00:00 Tim wrote: A workaround for when luksClose fails: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=554600#25 Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/23 ------------------------------------------------------------------------ On 2010-09-15T07:57:52+00:00 Milan wrote: (In reply to comment #5) > A workaround for when luksClose fails: All <F12 .. rawhide> have fixed cryptsetup already in updtes, no workarounds for luksClose needed. Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/24 ------------------------------------------------------------------------ On 2010-09-27T13:24:13+00:00 Martin wrote: This just got fixed in udisks git trunk: http://cgit.freedesktop.org/udisks/commit/?id=16529b69f7b1ab33e2b92f99cc3bef17d6f20a25 Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/32 ------------------------------------------------------------------------ On 2012-04-04T16:33:13+00:00 Manuel wrote: Same problem here in Fedora 16 (Fresh install). Seems the bug got implemented again. Probably... "It's not a bug, it's a feature!" :) Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/50 ------------------------------------------------------------------------ On 2012-05-23T17:54:49+00:00 Bugra wrote: got the same issue on F16 with removable HD. Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/51 ------------------------------------------------------------------------ On 2012-08-16T17:48:14+00:00 Fedora wrote: This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/484429/comments/52 ** Changed in: udisks (Fedora) Status: Unknown => Won't Fix ** Changed in: udisks (Fedora) Importance: Unknown => Medium ** Bug watch added: freedesktop.org Bugzilla #24279 https://bugs.freedesktop.org/show_bug.cgi?id=24279 ** Bug watch added: Debian Bug tracker #554600 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554600 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-disk-utility in Ubuntu. https://bugs.launchpad.net/bugs/484429 Title: Plugging in a LUKS device causes the following error: Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists Status in udisks: Fix Released Status in cryptsetup package in Ubuntu: Confirmed Status in gnome-disk-utility package in Ubuntu: Invalid Status in udisks package in Ubuntu: Fix Released Status in cryptsetup source package in Lucid: Won't Fix Status in gnome-disk-utility source package in Lucid: Invalid Status in udisks source package in Lucid: Won't Fix Status in cryptsetup source package in Maverick: Won't Fix Status in gnome-disk-utility source package in Maverick: Invalid Status in udisks source package in Maverick: Fix Released Status in cryptsetup package in Debian: Fix Released Status in udisks package in Fedora: Won't Fix Bug description: Binary package hint: cryptsetup When creating an encrypted drive in Palimsest (Disk Utility), the application does not lock the disk when finished creating the encrypted partition. Failing to lock the drive manually without ejecting will give the appearance that the disk is no longer usable giving this error. Bringing the key to another computer works because the drive is not unlocked (luks mapper point is not already present) on that system. Steps to reproduce: 1) Go into palimsest (disk utility) and create an encrypted partition on an external disk. 2) Quit Palimsest 3) Pull the USB stick 4) Intert the USB stick Result: GNOME displays a dialog for the password. Once submitted, the following error comes up: Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists This is due to the mapping being Opened when the disk is created, but never closed, which creates a conflict. Workaround: Do the following to resolve the conflict of the existing device i /dev/mapper. $ ls -al /dev/mapper (Identify the mount point for your drive, "sudo blkid" may help) $ sudo cryptsetup luksClose devkit-disks-luks-uuid-<uuid>-uid1000 What is expected: Palimsest (Disk Utility) is expected to "cryptsetup luksClose" the mapped device when finished creating the encrypted partition. ProblemType: Bug Architecture: i386 CheckboxSubmission: 19ba8f45e3d3d7bf348103cee5a0eeaa CheckboxSystem: 099634613a96bc3665b92c4a813055e8 Date: Tue Nov 17 15:37:09 2009 DistroRelease: Ubuntu 9.10 Package: cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7 ProcEnviron: LANGUAGE= PATH=(custom, user) LANG=en_CA.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-12.41-generic SourcePackage: cryptsetup Uname: Linux 2.6.31-12-generic i686 To manage notifications about this bug go to: https://bugs.launchpad.net/udisks/+bug/484429/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
