[Bug 484429] Re: Plugging in a LUKS device causes the following error: Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists
Bug Watch Updater
484429 at bugs.launchpad.net
Fri Oct 27 14:50:43 UTC 2017
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 Ubuntu
Foundations Bugs, which is subscribed to cryptsetup 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
More information about the foundations-bugs
mailing list