Error org.freedesktop.Hal.Device.Volume.Crypto.SetupError /dev/sdb is already setup error when mounting encypted drive

This had been a long standing issue in udev that has been fixed just recently. Can you please upgrade your system to the latest Feisty packages and test again? For me and many other people it now works out of the box.

If it does not work for you, please do the steps on https://wiki.ubuntu.com/DebuggingRemovableDevices. Thank you!

I did the debugging instructions after an update. At best, automounting encrypted partitions work inconsistently, sometimes they mount and sometimes not.

Here are the logs when it did not mount.

Additionally, after successfully entering the passphrase, the encrypted partition was opened and was mapped to

/dev/mapper/luks_crypto_e9c25c4a-3fff-464b-b3a0-ae5c289da5fd

I hope this helps.

And oh... thank you!

Hm, the logs look good so far. Can you please try this:

  1. killall gnome-volume-manager
  2. Remove the device
  3. plug in the device
  4. gnome-mount -vbd /dev/sdb1
  5. if 4. worked, : gnome-umount -vbd /dev/sdb1 and back to step 2

Please repeat this process until the device fails to mount and give me the output from the gnome-mount command. Thank you!

Thanks for the reply.

gnome-mount -vbd /dev/sdb1 always succeeds in mounting the first non-encrypted partition

however

gnome-mount -vbd /dev/sdb2 invariably fails with this message

gnome-mount 0.5
libhal-storage.c 1401 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set.
** (gnome-mount:7037): DEBUG: Crypto volume - UDI '/org/freedesktop/Hal/devices/volume_uuid_5dfd5a12_e5a4_4b01_9b61_2e1805e432ae'
** (gnome-mount:7037): DEBUG: Setting up /org/freedesktop/Hal/devices/volume_uuid_5dfd5a12_e5a4_4b01_9b61_2e1805e432ae for crypto
Setup clear-text device for /dev/sdb2.
** (gnome-mount:7037): DEBUG: Waiting for cleartext volume backed by /org/freedesktop/Hal/devices/volume_uuid_5dfd5a12_e5a4_4b01_9b61_2e1805e432ae..
** (gnome-mount:7037): WARNING **: Timeout for waiting for cleartext device... Exiting.

the "Timeout for waiting for cleartext device... Exiting" warning also comes up in gnome-mounting encrypted partition /dev/sdb3.

I hope this will help in resolving the problem. Thanks again!

I forgot to point out that /dev/sdb2 is also an encrypted partition

Any clue as to how I could work around the "timeout" problem?

bump.... any help?

I'm also getting this error, when investigating the mount problem by calling gnome-mount manually.

"Timeout for waiting for cleartext device... Exiting."

The mapper device is set up correctly by gnome-mount. As root, i am able to mount the mapper device without any problems. However, gnome-mount does not mount the filesystem.

I tried mounting the mapper device using gnome-mount... don't know if that is supposed to work at all... nevertheless... here is the output trying to mount /dev/mapper/luks.... using gnome-mount.

** (gnome-mount:7786): WARNING **: Given device '/dev/mapper/luks_crypto_5ed4dcfd-85ac-4e33-a899-83f61162d26f' is not a volume or a drive.

By the way, I'm running an up to date installation of feisty (10.03.). So this bug is surely not restricted to Herd4 - changed the title

No, you cannot mount the /dev/mapper/luks device with gnome-mount. You can, however, mount it with

  sudo mount /dev/mapper/luks /mnt

does that work?

Works for me, needs more information.

Ah, what does this show?

lsmod | grep dm

Martin, is it not supposed to work with pmount? Like it did in Dapper? I know the whole gnome-mount / gnome-volume-manager interaction changed...

Using mount as root works for me, but that is very inconvenient. I got used to the nice way it detected the LUKS volume (on my SD memory card via USB adapter), mapped it with dm-setup, prompted for passphrase in a Gnome dialog (cryptsetup-luks) and then called pmount and voila! I could unmount (from Disk Mounter applet), put in a diff SD card to get pics from my camera or whatever, then put the encrypted SD card back in and get re-prompted for password and auto-mounted it again...

# lsmod | grep dm
dm_crypt 14856 1
dm_mod 60236 3 dm_crypt

Sorry, not in Dapper, but in Edgy...

Michael, of course users are not supposed to mess around with 'sudo mount', that was just for testing this bug.

@Martin

in my comment i wrote

> The mapper device is set up correctly by gnome-mount.
> As root, i am able to mount the mapper device without
> any problems. However, gnome-mount does not mount
> the filesystem.

so yes... it works using manual mount...

It looks like my bug 87731 might be a dupe of this one.

I now regularly get this when mounting a LUKS volume the second time.

I have a very similar problem. My external HD (LUKS encrypted) doesn't get mounted since yesterday's software update. Everything worked well for me up to that update. Now I don't even get asked for a password, when I plug in the HD. I also don't get any error message. When I use cryptsetup LuksOpen and mount to access it manually, I can mount it without any problems. If you need any logs, just name them.

vikingr, that sounds like an entirely different problem. The output of

  gnome-mount -vbd /dev/sda1

(or whichever partition has the encrypted partition) would be appreciated.

Martin,

thanks for your message and sorry for posting in the wrong bug report.
Mysterioulsy, when I just plugged in the HD, I was asked for the password and the HD is mounted successfully. I haven't changed anything, so I hope it stays this way.

Apparently a hal bug; it sets up the /dev/mapper device correctly, but doesn't create a Volume for it. I'll keep the gnome-mount task open for now just in case.

I am having a similar problem. I've installed Edgy and made an encrypted home. I've wrote a tutorial about how it is done so you can see exactly what I've did on: http://pupeno.com/2006/12/17/encrypted-home-in-ubuntu-or-kubuntu-or-debian/

I've upgraded to Feisty by replacing "edgy" with "feisty" on sources.list and "aptitude dist-upgrade". After rebooting, my encrypted home wasn't mounted automatically and I can't mount it by hand. I'll try to dump as many relevant information here and wait some hours in case anybody needs more information until I'll rebuild the encrypted FS and restore from backups.

No mapping enabled:

pupeno@black:~$ ls /dev/mapper/
control
pupeno@black:~$

and this is what I have mounted:

pupeno@black:~$ mount
/dev/sda1 on / type reiserfs (rw,notail)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.20-14-generic/volatile type tmpfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
pupeno@black:~$

My first suprise is that my IDE (P)ATA HD is seen as /dev/sda and not /dev/hda. I see that this is because migration to libata, sounds nice. Maybe that's the problem with cryptloop?

Let's see some information about the crypted FS:

pupeno@black:~$ sudo cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: 76 99 15 04 37 2d bc e1 25 9b 33 0c 08 f4 6a c7 ec 11 7c 59
MK salt: 7c cf f7 0f aa 22 50 eb 05 78 24 79 bc 7b 2b 46
                9e 25 29 fc f1 f7 70 84 1a 4d f8 21 ea dd 44 38
MK iterations: 10
UUID: f9d7e9c3-9176-4d3b-9d20-4abb25e4ffaf

Key Slot 0: ENABLED
        Iterations: 69658
        Salt: c7 ed 53 74 a9 cd d8 da a7 1d 04 d4 06 28 9f 3e
                                fb ae 4e 93 da 09 d7 7e fc 14 1e aa 83 ef 75 18
        Key material offset: 8
        AF stripes: 4000
Key Slot 1: ENABLED
        Iterations: 69773
        Salt: d2 1e 82 0a 41 77 d4 23 8b 88 5c ed ea 14 33 b4
                                fe 2b 20 c5 c3 33 08 29 32 fd 28 46 a9 8a 39 bd
        Key material offset: 136
        AF stripes: 4000
Key Slot 2: ENABLED
        Iterations: 62620
        Salt: c8 5b ad 11 49 0d 03 02 2d ed 4c b3 bd 2e 98 3c
                                bf de a8 c0 fe af 68 f9 b9 1f e0 7c 0a 17 2a 4e
        Key material offset: 264
        AF stripes: 4000
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

So far it looks ok. Let's try opening it:

pupeno@black:~$ sudo cryptsetup luksOpen /dev/sda3 home
Enter LUKS passphrase:
key slot 2 unlocked.
Command successful.
p...

More info regarding my previous message.

Closing gnome-mount task, since this is a hal issue only.

Hmm, on latest Feist I do not get this any more. Can anyone confirm that it still happens on Feisty du jour?

Martin,

I again got the problem since yesterday. I really don't know what could've caused it, because for what I see there's been no updates of related packages.

I am still having this problem. A quick note, now it still fails but if I try again I get this message:

Error org.freedesktop.Hal.Device.Volume.Crypto.SetupError

/dev/sdc is already setup?

I get the same error (obviously different locations though, /dev/sdb etc...) with three different drives. I don't think it is relevant but to rule out an issue with the drives Etch mounts them all fine.

I've had a similar problem when trying to mount my USB key with LUKS volume on it.

Attached in [0] is the logs created for "dapper" as describes in https://wiki.ubuntu.com/DebuggingRemovableDevices

Cryptsetup version - 2:1.0.4+svn26-1ubuntu2

--- Scenario

First: I had to create my LUKS volume manually, unfortunately :( Hope this will be added as a feature as well...
I did test it and it works. [1]

I plug in my usb and it asks for password [2]

It doesn't mount anything, but give me an hal error [3] similar to the one Darren, describes.

-----------

[0] usb-LUKS.logs.tar.bz2
[1] luks-manually.png
[2] Screenshot-Unlock Encrypted Data.png
[3] Screenshot-gnome-mount.png

If any other information is need I'll gladly provide it, thanks ;)

Did some more testing today, and I found that if the system has 1 encrypted device already, in my case an encrypted /home, I can't mount my USB saying that it might already be in use.

If none exist it unlocks and mounts my USB just fine.

Hope this helps.

I can confirm the problem with a current feisty.

A few updates to this ticket:

1) All of my systems (3) experience this issue
2) I have this issue with the following devices:
3 20 gig USB hard drives formatted with ext3
1 64 meg USB key formatted with vfat
3) pmount works
4) Some of the volumes have labels some do not
5) All have different passwords that are between 10 and 20 characters with all types of characters including non-alphanumeric

Since this works for others I am trying to find some common issues on my side or configurations that might be causing this.
The hardware is:
Dell Inspiron 700m
IBM Thinkpad T60
Intel Mac Mini

Setup:
I setup the drives with luksformat or manually by creating the luks partition and using mkfs

Install
All three were early Fiesty installs that have been upgraded to release over the life of Fiesty development.

The only common items that I can think of are:
1) All were early installs while Fiesty was in development
2) All were setup by me

Is there a chance something in my systems are borked from all the updates?

Since the last upgrade (IIRC one of the packages was hal), mounting encrypted partitions works again on my system.

The same update also changed the unmount procedure: Instead of "Eject" I now have "Unmount Volume" in the context menu of the volume icon. Also I have to unmount each partition separately, before, when using eject, all partitions where unmount as soon as I clicked Eject on one of them. I don't know if this is a bug or a feature.

A further update, I tested on a fresh load and the same problem exists.

This leads me to believe that the issue with with the way I am creating these luks encrypted drives.

I have tried creating the devices the following ways:
The cryptsetup -luksformat method using the default options and then formatting the mapped device

then the luksformat tool (I think written by you Martin?) using the default vfat and with ext3.

I have tried it with 4 different flash drives and multiple drive enclosures with no luck via gnome-mount. Opening them and mounting them manually as well as using pmount work fine.

Can someone here who has a working drive tell me how they created it? Maybe I am doing something wrong?

I created my partitions with cryptsetup -luksFormat and then mke2fs / mkxfs. So I don't think that this is the reason for your problems.

After playing around I found an odd "solution" (Note that I placed solution in question marks).

I am unable to mount any encrypted device when I encrypt the entire drive such as /dev/sdc rather than /dev/sdc1.

If I format the device as one filesystem and then use luksformat to format the resulting /dev/sdx1 I now have a luks encrypted drive that will automatically mount using gnome-mount. I figured something had to be wrong with the partition type since I kept seeing unknown partition type in my logs when I tried to mount the drive.

I formatted the drive as vfat, then created a vfat luks container and moved a file to it. If I plug the drive into my wifes windows box it sees the drive as unreadable and if I use freeotfe I can mount it and it sees it as a proper luks encrypted volume...

So is this a normal issue and I never should have been able to encrypt a volume using /dev/sdc and should only use /dev/sdc1? Does this "solution" seem weird to anyone else?!

Well I have confirmed this in every way I could, if I use cryptsetup to encrypt an entire drive gnome-mount will not mount it, however if I encrypt just a partition (even if the partition is composed of the entire drive) it mounts fine. This is probably a different bug than this report so I will try and find the bug report system for gnome-mount, file a bug there and then open a new bug here and link it to that report.

Bug # 117011 opened for this... I opened it on gnome-mount since HAL seems to recognize the device properly. I also opened a bug upstream and linked it.

Works first time on an updated Fiesty, after unmounting and reinserting the contained partition is not mounted.

I have the same problem with Feisty. Somtimes my encrypted drive mounts correctly, somtimes it needs some retries and sometimes I'm complety unable to get it mounted with gnome-mount. Maybe it is important to say that my hole system is encrypted (excapt /boot)

Similar to other reports, the output of gnome-mount is:

xxx@yyy:~$ gnome-mount -vbd /dev/sdd1
gnome-mount 0.5
libhal-storage.c 1401 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set.
** (gnome-mount:15499): DEBUG: Crypto volume - UDI '/org/freedesktop/Hal/devices/volume_uuid_34655d4e_0de7_4dff_a35a_397494f2cbed'
** (gnome-mount:15499): DEBUG: Setting up /org/freedesktop/Hal/devices/volume_uuid_34655d4e_0de7_4dff_a35a_397494f2cbed for crypto
Setup clear-text device for /dev/sdd1.
** (gnome-mount:15499): DEBUG: Waiting for cleartext volume backed by /org/freedesktop/Hal/devices/volume_uuid_34655d4e_0de7_4dff_a35a_397494f2cbed..

** (gnome-mount:15499): WARNING **: Timeout for waiting for cleartext device... Exiting.
xxx@yyy:~$

The claretext device is created everytime (/dev/mapper/luks_crypto_+UUID), but often gome-mount don't recognice that. (The claretext device appeares long before gnome-mount is printing the timeout-warning!)

This problem is still present. When using gnome-mount, it works everytime (mounting/unmounting/mounting...). But when using nautilus, it sometimes can't be remounted whether with nautilus or gnome-mount after first unmounting. When this occurs, the label of the encrypted disc remains visible in nautilus, and in hal-manager (I mean the cleartext volume still appears), though the luks_crypto mapping has already disappeared. It seems to be the root of the subsequent problems: nautilus tries (through hal) to mount directly without remapping because it sees the cleartext volume listed in hal. When trying to unmount with nautilus, it fails again because it is already unmounted. When trying to teardown (using dbus-send), it fails again because the cryptsetup command used by hal to unmap the cleartext volume fails (quite understandably since there is no mapping at the time).

Using dbus-send commands, I can get things in order by calling the Volume.Crypto.Setup method. I then follow with Volume.Crypto.Teardown to destroy the mapping completely and it works correctly thereafter (until of course I mount and then unmount with nautilus, which leads to the same situation).

It seems that there is some kind of race condition because when I call Volume.Unmount followed by Volume.Crypto.Teardown rapidly, the exact same problem as with nautilus occurs. On the contrary, if I wait ten seconds between my two dbus-send commands, it works perfectly.

For reference, I used these commands:
dbus-send --print-reply --system --dest=org.freedesktop.Hal '/org/freedesktop/Hal/devices/volume_uuid_my_encrypted_partition_uuid' org.freedesktop.Hal.Device.Volume.Crypto.Setup string:'my passphrase'
dbus-send --print-reply --system --dest=org.freedesktop.Hal '/org/freedesktop/Hal/devices/volume_uuid_my_encrypted_partition_uuid' org.freedesktop.Hal.Device.Volume.Crypto.Teardown
dbus-send --print-reply --system --dest=org.freedesktop.Hal '/org/freedesktop/Hal/devices/volume_uuid_my_cleartext_mapping_uuid' org.freedesktop.Hal.Device.Volume.Mount string:'mymediamountpoint' string:'auto' array:string:''
dbus-send --print-reply --system --dest=org.freedesktop.Hal '/org/freedesktop/Hal/devices/volume_uuid_my_cleartext_mapping_uuid' org.freedesktop.Hal.Device.Volume.Unmount array:string:''

I didn't fully understand the way the /usr/lib/hal/scripts/luks-* and /usr/lib/halt/scripts/linux/luks-* scripts work, so I am unable so far to propose a correction. I hope that these indications will help you to correct this problem.

Cordially.

This sounds to me like a duplicate of bug 148003 - you might want to check whether the fix posted there also solves this problem.

Sorry, I didn't see it. Today's update from gutsy-proposed effectively solved that problem. Thanks.

This bug happened on 8.10 and is still happening with 9.04. Here is what I get:

1 - Plug dmcrypt-encrypted USB external HD in (the whole /dev/sdb is encrypted, not a partition within)
2 - luks_crypto_69d35537-7865-4698-84c5-04283f517fbc appears in /dev/mapper
3 - "Encrypted data" volume appears in my Nautilus "Workplace" (Poste de travail in French)
4 - I double click on "Encrypted data"

Problem: I get a dialog saying

"Error org.freedesktop.Hal.Device.Volume.Crypto.SetupError
/dev/sdb is already setup?"

Then about 10 seconds later, I get this message:

"DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

To get it mounted properly, I have to (manually) do:

sudo mount /dev/mapperluks_crypto_69d35537-7865-4698-84c5-04283f517fbc /media/blackvault

Marking as new since the problem resurfaced.

JFTR: I am receiving similar messages here, but the volume is actually mounted correctly.

Thanks for re-informing us about this.

Can you please include the information requested at https://wiki.ubuntu.com/DebuggingHal as separate attachments. Thanks.

Thanks for caring about this bug. So here are the files and the procedure:

- Opened my "home" in Nautilus
- Double-clicked on the "encrypted filesystem" drive (that was already plugged-in)
- Got the "/dev/sdc already setup ?" message

Brilliant, thank you for the logs, should be very helpful. As one last thing, can you run
apport-collect 88213
and let it attach all the extra system info, then we should be able to send this on. Thanks :)

I can't run the command... I did not gave all thr priveleges and I cant' find how to allow "change everything".

apport-collect 88213 (105)
Logging into Launchpad...
Downloading bug...
Bug title: Error org.freedesktop.Hal.Device.Volume.Crypto.SetupError /dev/sdb is already setup error when mounting encypted drive
Ignoring task https://api.edge.launchpad.net/beta/ubuntu/+source/gnome-mount because it is closed
Collecting apport information for source package hal...
Uploading additional information to Launchpad bug...
   short text data...
Error connecting to Launchpad: HTTP Error 401: Unauthorized
You have to allow "Change anything" privileges.

When you run the command, Firefox should open and ask you to sign in, that is where you will see the Change All button.

Firefox opened once, then I gave "Read anything" credentials... and since then the command does not ask me to login anymore, even after logging out of firefox. I can't get to this login/preference screen where I could set the permissions. Should I file a bug for "apport-collect" ?

You should be able to change the settings for this in your Launchpad profile. No matter, can you manually provide the following information as separate attachments.

uname -a > uname-a.log
cat /proc/version_signature > version.log
dmesg > dmesg.log
sudo lspci -vvnn > lspci-vvnn.log

Thanks.

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as triaged and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Well, thank you and Canonical for such a high level of support !

On Tue, May 19, 2009 at 5:13 PM, Teej <email address hidden> wrote:

> Thanks for reporting this bug and any supporting documentation. Since
> this bug has enough information provided for a developer to begin work,
> I'm going to mark it as triaged and let them handle it from here. Thanks
> for taking the time to make Ubuntu better!
>
> ** Changed in: hal (Ubuntu)
> Importance: Undecided => Medium
>
> ** Changed in: hal (Ubuntu)
> Status: Incomplete => Triaged
>
> --
> Error org.freedesktop.Hal.Device.Volume.Crypto.SetupError /dev/sdb is
> already setup error when mounting encypted drive
> https://bugs.launchpad.net/bugs/88213
> You received this bug notification because you are a direct subscriber
> of the bug.
>

BTW, this bug vanished in Karmic

http://www.freedesktop.org/wiki/Software/hal/