With gnome 2.18 I plugged my LUKS encrypted USB stick in, a password dialog would appear, I enter the password and an icon on the desktop appears for the volume. With gnome 2.20 the password dialog appears, I enter the password and nothing appears to happen. If I look in /dev/mapper I see it does create the mapper device, which I can mount and all is fine. So appearantly it fails in the last step, it should still create a folder with the volume name in /media and mount the mapper device on it. Reproducible: Always Steps to Reproduce: Happens 99% of the time 1. Insert LUKS encrypted USB stick 2. Enter password 3. Expect volume to appear Actual Results: volume does not appear (it does create the mapper device, but doesn't mount the mapper device under /media/<volume label> Expected Results: Volume should appear on the desktop and be mounted under /media/<volume label> According to the gentoo gnome 2.20 forum thread there is atleast one other person experiencing this.
@gentopia: can you guys help on this? Thanks :)
I can confirm the bug. I've found that if you restart dbus (which also restarts hal) and log out and log back in, the volume will mount. This only works once though; when you un-mount the volume, you need to restart dbus... and log back out and in if you want gnome to mount it for you.
I've recently created a luks encrypted usb disk as well and I can confirm that. If plugged in the first time after boot, the password prompt appears, the volume appears as well, filling in the passphrase creates the mapper device but then clicking on the volume makes it disappear. Thereafter, disconnecting (making sure the mapper device is closed) and reconnecting the device doesn't help.
This happens on both my x86_64 and my i386 btw.
I'll try to post a trace of udevmonitor tomorrow.
Here's a patch to fix the problem... Sorry, I can't remember where I found it, but kudos to whoever made it. --- udev_node.c 2007-12-18 15:50:56.000000000 -0800 +++ udev_node.c.new 2008-02-02 19:55:19.000000000 -0800 @@ -409,7 +409,7 @@ strlcat(filename, udev->name, sizeof(filename)); if (stat(filename, &stats) != 0) { dbg("device node '%s' not found", filename); - return -1; + goto already_removed; } if (udev->devt && stats.st_rdev != udev->devt) { info("device node '%s' points to a different device, skip removal", filename); @@ -422,6 +422,7 @@ if (retval) return retval; + already_removed: setenv("DEVNAME", filename, 1); num = udev->partitions; if (num > 0) {
(In reply to comment #6) I don't quite understand what it does but it indeed makes it work for me. Although now gnome-mount will crash on each plug of the crypted disk. It still mounts it and makes all the magic so that I can use the files. I can post a backtrace if it's of any interest for someone here.
Hello, I googled a bit and found on launchpads bugzilla a fix tagged "the gentoo way" :p. So I share it here with you. Since I forgot the link and the file to patch is different, too I just put the patch up here. Credit goes to that person on launchpad though. hth Note: This works great w/o gnome-mount crashing --- 64-device-mapper.rules 2008-03-01 13:27:00.000000000 +0100 +++ 64-device-mapper.rules 2008-03-01 13:19:34.000000000 +0100 @@ -1,5 +1,6 @@ # do not edit this file, it will be overwritten on update +KERNEL=="dm-[0-9]*", NAME="%k", SYMLINK+="%c" KERNEL=="device-mapper", SYMLINK+="mapper/control" KERNEL!="dm-*", GOTO="device_mapper_end" Since this file gets overridden on update this patch should be part of the ebuild imho. Maybe I'll cook something up but only if this works for anybody else!
confirming this works great for me as well. adding maintainers listed in udev ebuild to get their input on the "fix".
wfm2 thanks a bunch. By far the cleanest solution IMHO.
as far as I can tell this has been fixed by recent updates (in the last 2 months). My work box which is ~amd64 (and not yet gnome 2.22) has been mounting and unmounting luks encrypted volume properly for at least 2 weeks without having to do any tricks.
I currently experience this problem with the following combination of packages: sys-fs/udev-125-r2 sys-apps/hal-0.5.11-r1 gnome-base/gnome-mount-0.7 sys-fs/device-mapper-1.02.27 The problem is exactly as described in the orignial bug reporters description, besides i can reproduce it with internal disk partitions too, so it's not usb-specific. I tried the following: --- $ gnome-mount -b -d /dev/sda1 gnome-mount 0.7 Setup clear-text device for /dev/sda1. Clear text device is /dev/mapper/luks_crypto_022ba190-0c78-44af-bcc4-c3fe6f69f69a. Mounting. ** (gnome-mount:9439): WARNING **: /org/freedesktop/Hal/devices/volume_part_1_size_0_0 does not have a mountable filesystem --- Then I googled a little bit and found interesting bug reports at debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467200 http://www.nabble.com/Bug-445474:-gnome-mount---LUKS-volume-opened,-but-not-mounted-td18423842.html Maybe someone more into udev, hal and friends can find the right way to ultimately fix this bug. I will try to fiddel around with my udev-rules...
policykit setup aren't support at this point in time, so you'll have to come back with tests against gnome-mount 0.6.
It's the same thing with gnome-mount-0.6. The first command shows the password prompt and results in the luks partition being unlocked successfully, but not mounted in 99% of the time, with an error message complaining about a zero sized block device, if i understand correctly: $ ls -l /dev/mapper/ lrwxrwxrwx 1 root root 16 14. Aug 21:47 control -> ../device-mapper $ gnome-mount -b -d /dev/hda1 gnome-mount 0.6 Setup clear-text device for /dev/hda1. Clear text device is /dev/mapper/luks_crypto_3a87153d-cbef-488c-ae6f-6e5118c68c87. Mounting. ** (gnome-mount:31242): WARNING **: /org/freedesktop/Hal/devices/volume_part_1_size_0 does not have a mountable filesystem $ ls -l /dev/mapper/ lrwxrwxrwx 1 root root 16 14. Aug 21:47 control -> ../device-mapper brw-r----- 1 root disk 254, 0 15. Aug 21:00 luks_crypto_3a87153d-cbef-488c-ae6f-6e5118c68c87 But I can mount it by hand afterwards: $ sudo mount -v /dev/mapper/luks_crypto_3a87153d-cbef-488c-ae6f-6e5118c68c87 /mnt/test mount: you didn't specify a filesystem type for /dev/mapper/luks_crypto_3a87153d-cbef-488c-ae6f-6e5118c68c87 I will try type reiserfs /dev/mapper/luks_crypto_3a87153d-cbef-488c-ae6f-6e5118c68c87 on /mnt/test type reiserfs (rw) Reading of the links in comment #12 suggests, that this happens because of a race condition caused by a temporarily created cleartext device that gets confused somehow with the final cleartext device, is tried to be mounted instead, but vanishes in the same moment, so the mount fails.
Please, re-open this bug, it's not fixed. I've same problem, but with an LUKS crypted SD card on a ThinkPad X40. When I boot up my PC, I'm asked by gnome-mount for a password for my device. I enter it and nothing is mounted. Pull out the card and re-insert it, Nautilus see a "crypted data" for a short while (maybe 1/2th sec) and the diseaper. This append maybe 80% of the time, and sometimes it get mounted (after ~20 tries). If I suspend to ram (not to disk), my success ratio grows up to 50% ! I've searched the web and there is a lot of reports for removable media (USB HDD, USB keys, SD cards, ...) that are not automounted since gnome 2.20 / 2.22. I've also looked in kernel, and the CONFIG_DM_UEVENT, but no significatives changes. The debian bug #455746 seems to bring a solution (in device-mapper area), but I've no idea how to check this against Gentoo : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455746 Maybe the sys-fs/device-mapper need to take a look ?
Please consider to re-open the bug, issue still here Issue still here with the recent sys-fs/udev-128 sys-fs/cryptsetup-1.0.6-r1 sys-apps/hal-0.5.11-r3 Here is my error message : gnome-mount 0.6 Initialisation de périphérique non chiffré pour /dev/mmcblk0p1. Le périphérique non chiffré est /dev/dm-0. Montage. ** (gnome-mount:14132): WARNING **: /org/freedesktop/Hal/devices/volume_part_1_size_0 does not have a mountable filesystem ** (gnome-mount:14153): WARNING **: Setup failed for /org/freedesktop/Hal/devices/volume_uuid_381241fb_059d_4c94_b030_5cdcadf3de8c: org.freedesktop.Hal.Device.Volume.Crypto.SetupError : /dev/mmcblk0p1 is already setup?
please open a new bug since it's dependant on the new hal/udev releases it seems.
(In reply to comment #17) > please open a new bug since it's dependant on the new hal/udev releases it > seems. > Done, bug #238870
