Fedora Account System
Red Hat Associate
Red Hat Customer
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).
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...
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.
(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".
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
A workaround for when luksClose fails: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554600#25
(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.
This just got fixed in udisks git trunk: http://cgit.freedesktop.org/udisks/commit/?id=16529b69f7b1ab33e2b92f99cc3bef17d6f20a25
Same problem here in Fedora 16 (Fresh install). Seems the bug got implemented again. Probably... "It's not a bug, it's a feature!" :)
got the same issue on F16 with removable HD.
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