I've GNOME 2.14.1 installed. These are the versions of the software I'm using: [ebuild R ] gnome-base/gnome-mount-0.4-r4 [ebuild R ] gnome-base/gnome-volume-manager-1.5.15-r1 [ebuild R ] app-crypt/luks-tools-0.0.8 [ebuild R ] sys-fs/cryptsetup-luks-1.0.3-r2 Now, I've got a USB drive with some luks-encrypted partitions. I can mount them cleanly via pmount-hal via console: they immediately appear into /media, after giving pmount the password. However, gnome-volume-manager (and gnome-mount) simply don't work as they should. I'm asked for the password via a GUI, but then no partition is mounted. So I opened up a gnome-terminal, and tried to do: matteo@tulip ~ $ gnome-mount -b -d /dev/sda2 gnome-mount 0.4 ** (gnome-mount:17274): WARNING **: Setup failed for /org/freedesktop/Hal/devices/volume_uuid_8e36ed37_7d63_4706_82e9_59b5d4d3c986: org.freedesktop.Hal.Device.Volume.Crypto.SetupError : Error setting up /dev/sda2 - /sbin/cryptsetup not found It appears that gnome-mount expects cryptsetup into /sbin and not in /bin. So I set up a symlink into /sbin to try and see if it was the only issue. After that, what happens now is that trying to mount the luks-encrypted partition fails after a wait of ~20 seconds. matteo@tulip ~ $ gnome-mount -b -d /dev/sda2 gnome-mount 0.4 Setup clear-text device for /dev/sda2. ** (gnome-mount:17200): WARNING **: Timeout for waiting for cleartext device... Exiting. It would be really nice to have this fixed. Some other distros get it right (Ubuntu comes to mind). I really don't know what's wrong with our default setup. Some other people seem to be experiencing the same problem, too: http://forums.gentoo.org/viewtopic-t-456851-highlight-luks.html
An addition: after putting the cyrptsetup symlink in place (in /sbin), the luks devices are created correctly. matteo@tulip ~ $ ls /dev/mapper/ control luks_crypto_8e36ed37-7d63-4706-82e9-59b5d4d3c986 luks_crypto_dee7ebb0-e56d-4eba-ad56-381e981ce882 That is the reason why, if you try to gnome-mount the partition again, it says it's already set up.
I think the problem is somewhere in HAL. When gnome-mount sets up the crypto device, it waits for HAL to tell it that the crypto device has been added, or a 10 second timeout. However, it never receives that event.
It looks as though HAL never sees any of the devices within /dev/mapper, and appears [1] to be expecting devices such as /dev/dm-0. Seemingly recent versions of udev don't create these devices, since the multipath extra is no longer included (at least not in udev-096), and there's a comment in the udev rules file to ignore dm devices. As such, it looks like it's might need some HAL patching to get it to detect /dev/mapper devices. It would be worth some investigation on other systems as to how they have this working... [1] "Given a device file such as dm-0, the function looks for the corresponding device in /dev/mapper." - https://www.redhat.com/magazine/012oct05/features/hal/
I fixed it!! As mike said, hal wants the dm-X device nodes, which aren't created by udev. After commenting out a line in the udev rules file, it will create the device, but hal won't recognize it. After some grepping of hal's source, I found that it also wants the device to have major 253, while the correct major is 254 (hald/linux2/blockdev.c:496).
(In reply to comment #4) > I fixed it!! > > As mike said, hal wants the dm-X device nodes, which aren't created by udev. > After commenting out a line in the udev rules file, it will create the device, > but hal won't recognize it. After some grepping of hal's source, I found that > it also wants the device to have major 253, while the correct major is 254 > (hald/linux2/blockdev.c:496). > Could you post some patches?
Created attachment 99491 [details, diff] hal-0.5.7.1-device-mapper-nod-fix.patch Nearly there, but not quite. Here's a patch for hal that corrects the bad device mapper number. Sadly I also couldn't find where the nod number was stored in the kernel source, so it's still hardwired. At this point hal will be aware of /dev/dm-X devices because they will have nod numbers of 254. Unfortunately the default rules appear to tell udev to ignore dm-X devices (assuming that /dev/mapper devices are enough). So there's a second patch (that I'll attach in a minute) that needs to be applied to the udev rules to fix this...
Created attachment 99492 [details, diff] Patch for udev.rules file to fix device-mapper /dev/dm-X creation Unfortunately, now that at least tries to mount the thing. It still fails for me, but this time with the following: gnome-mount 0.4 ** (gnome-mount:7551): DEBUG: Crypto volume - UDI '/org/freedesktop/Hal/devices/volume_uuid_229317a7_1755_452f_bc07_341a7a053a81' Enter password to unlock encrypted data for /dev/sda5: ** (gnome-mount:7551): DEBUG: Setting up /org/freedesktop/Hal/devices/volume_uuid_229317a7_1755_452f_bc07_341a7a053a81 for crypto Setup clear-text device for /dev/sda5. ** (gnome-mount:7551): DEBUG: Waiting for cleartext volume backed by /org/freedesktop/Hal/devices/volume_uuid_229317a7_1755_452f_bc07_341a7a053a81.. ** (gnome-mount:7551): DEBUG: In crypto_setup_device_added for /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c ** (gnome-mount:7551): DEBUG: In crypto_setup_device_removed for /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c ** (gnome-mount:7551): DEBUG: In crypto_setup_device_added for /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c ** (gnome-mount:7551): DEBUG: /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c is backed by /org/freedesktop/Hal/devices/volume_uuid_229317a7_1755_452f_bc07_341a7a053a81 - will mount Clear text device is /dev/dm-2. Mounting. ** (gnome-mount:7551): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c ** (gnome-mount:7551): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c with mount_point='', fstype='', num_options=0 ** (gnome-mount:7551): WARNING **: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_d1a982bb_b7cc_4e8c_a31e_cd3b4aaf184c org.freedesktop.Hal.Device.Volume.PermissionDenied : Device has volume.ignore set to TRUE. Refusing to mount. It might work better with removable devices perhaps?
I applied the hal and udev patches to hal-0.5.7.1 and udev-103. I created a new hal-0.5.7.1-r99 cloned from hal-0.5.7.1-r2 in my portage overlay and added the hal patch to that one. No my luks encrypted usb stick mounts and unmounts fine. Great stuff!
More success My Trekstor 300GB USB 2.0 Harddisk was recognized as well. Really like this functionality.
Just for the record: Works fine with hal 0.5.8.1 and gnome-mount 0.5 after using the udev-fix (hal-patch does not seem to be necessary anymore)
The possible cases for udev-rules are: A. Ignoring the event completely (like we have now) Does not create device and hal gets no event KERNEL=="dm-[0-9]*", OPTIONS="ignore_device" B. Discarding the name of the device Gets udev to not create a device, hal gets an event with empty name KERNEL=="dm-[0-9]*", NAME="" C. Not doing anything Does create devices /dev/dm-*, hal gets the event KERNEL=="dm-[0-9]*", NAME="%k" D. Calling devmap_name to get the device name It does create no additional devices (only that that gets created all the time, but in past not by udev), hal gets a event with correct name. KERNEL=="dm-[0-9]*", NAME="" KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%c" (or NAME="%k", SYMLINK="%c") As I read some mails about that topic I think upstreams prefer something like rule C.
Another alternative: E. Query dmsetup for the name of the device: ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o name info" Only unresolved problem with all device mapper devices is: uevent about block device arrives before device is fully set up.
(In reply to comment #12) > Another alternative: > E. Query dmsetup for the name of the device: > ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ > PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o > name info" > This is implemented in the rules of udev-106-r2. Please report if that fixes the bug.
Since last report I had to reinstall my system. I used the following versions of packages sys-fs/udev-106-r2 sys-apps/hal-0.5.7.1-r99 (a cloned version of r5 that includes the device-mapper-nod-fix patch) sys-apps/pmount-0.9.13 app-crypt/luks-tools-0.0.12 gnome-base/gnome-mount-0.4-r5 Unfortunately there is no ebuild for any hal-0.5.8.1 version in the current portage tree. Now, this gives me when I run gnome-mount from the command line (/dev/sda1 is a LUKS encrypted volume on a USB stick): $ gnome-mount -v -b -d /dev/sda1 gnome-mount 0.4 ** (gnome-mount:5384): DEBUG: Crypto volume - UDI '/org/freedesktop/Hal/devices/volume_uuid_8ae97a21_74b1_4703_b0a5_b67af46cd29e' ** (gnome-mount:5384): DEBUG: Setting up /org/freedesktop/Hal/devices/volume_uuid_8ae97a21_74b1_4703_b0a5_b67af46cd29e for crypto Setup clear-text device for /dev/sda1. ** (gnome-mount:5384): DEBUG: Waiting for cleartext volume backed by /org/freedesktop/Hal/devices/volume_uuid_8ae97a21_74b1_4703_b0a5_b67af46cd29e.. ** (gnome-mount:5384): WARNING **: Timeout for waiting for cleartext device... Exiting. However, it works if I change the udev rules, as specified in the udev patch from before, i.e. my udev rules now look like: # dm devices # lookup device name and create device in /dev/mapper # use dmsetup, until devmap_name is provided by sys-fs/device-mapper #ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ # PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o name info", \ # NAME="mapper/%c" KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" KERNEL=="device-mapper", NAME="mapper/control" So, I probably need the new hal 0.5.8.1 for the proposed udev rules, but as long as that is not available I have to wait. Let me know when the new hal is in portage or where I can find a ebuild that is working so I can put it in my overlay and I will test it.
sys-apps/hal-0.5.8.1 is part of the gentopia overlay, and is imported into the gnome-experimental overlay, and possibly others... http://overlays.gentoo.org/svn/proj/gentopia/overlay/sys-apps/hal/hal-0.5.8.1.ebuild
(In reply to comment #14) > Since last report I had to reinstall my system. > > I used the following versions of packages > sys-fs/udev-106-r2 you are sure? I added this ebuild only some hours ago. > > However, it works if I change the udev rules, as specified in the udev patch > from before, i.e. my udev rules now look like: > > # dm devices > # lookup device name and create device in /dev/mapper > # use dmsetup, until devmap_name is provided by sys-fs/device-mapper > #ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ > # PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o > name info", \ > # NAME="mapper/%c" > KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", > SYMLINK+="%c" > KERNEL=="device-mapper", NAME="mapper/control" > > This is how the udev-rules from udev-106-r2 look for dm devices: ACTION=="add", SUBSYSTEM=="block", KERNEL=="dm-*", \ PROGRAM="/sbin/dmsetup -j %M -m %m --noopencount --noheadings -c -o name info", \ NAME="mapper/%c" KERNEL=="device-mapper", NAME="mapper/control" Perhaps you did not update your conf-files (etc-update or dispatch-conf).
> you are sure? I added this ebuild only some hours ago. Yes, you see the commented out lines? Those are yours. I commented those and added the rule from the old patch to make it work... (Your ebuild was the reason that I tried it out. It was on my TODO list to get this to work again after my reinstall, but your work made me reprioritize a bit ;-) I'll see if I can get the new hal to work. That won't be today anymore though...
Just tried this at home with hal-0.5.8.1 and udev-106-r2 (and a reboot), and it all seems fine. Luksformatted, luksopened, mkfsed and luksclosed the removable disk. Plugged it back in and was prompted for the password, after which the drive appeared (although there was quite a wait). A little bit of permission changing later, and I was dragging and dropping onto the encrypted partition fine. Unmount and remounted all worked as expected. I'm using the gnome-experimental overlay, which might potentially have an effect, but otherwise I'd say this bug is good to close and that Matthias' bug might unrelated? Thanks for the fix Luud!
Errr, sorry, was off by one, swap those names around. Sorry for the confusion! Thanks again Zzam!
Success here too with hal-0.5.8.1 and udev-106-r2, great work, thanks!
Verified with hal-0.5.8.1 and udev-106-r4. Well done! (Used hal ebuild as per advice from Mike in comment #15)
(In reply to comment #21) > Verified with hal-0.5.8.1 and udev-106-r4. > > Well done! > > > (Used hal ebuild as per advice from Mike in comment #15) > Great!!! :-) Using hal-0.5.8.1, udev-106-r4, gnome-mount-0.5 and KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", Does an easy way exist to use gnome-mount with [gpg] key files?
You're probably going to want to try hal 0.5.9 from the tree as well.
(In reply to comment #23) > You're probably going to want to try hal 0.5.9 from the tree as well. > Yep, it seems to work with hal 0.5.9 if you apply the udev patches. I couldn't get it to work without it.
hal-0.5.9-r1 solved all my permission issues with encrypted esata drive/partitions.
(In follow-up of comment #21) I cheered too soon. It does work, but only on the first mount after a reboot. Setup is as described in comment #21. Mounting fails when trying to mount an unmounted device again. Removing the device and plugging back in does not help. Only a reboot solves it (probably be because I do not know what is causing it). What I do see however is failed attempts to call hal_unmount. So this may be part of the problem. Adding that file doesn't solve it though. (For reference see also this forum topic: http://forums.gentoo.org/viewtopic-t-505977.html) hal-0.5.9 will not emerge (complains about autoconf not being able to run) hal-0.5.9-r1 does not mount at all (not even the first time around). I added two transcripts of my tests in an attachment: test_transcript.txt
Created attachment 118625 [details] Transcript of tests related to comment 26 See comment #26
Just upgraded along the Gentoo stable path. Current versions are: sys-fs/udev-104-r12 sys-apps/hal-0.5.9-r1 This broke the mounting. Checked the /etc/udev/rules.d/50-udev.rules file and changed lines 74-79 from # dm devices (ignore them) KERNEL=="dm-[0-9]*", OPTIONS="ignore_device" # create a symlink named after the device map name # note devmap_name comes with extras/multipath # KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" KERNEL=="device-mapper", NAME="mapper/control" to # dm devices (ignore them) # KERNEL=="dm-[0-9]*", OPTIONS="ignore_device" # create a symlink named after the device map name # note devmap_name comes with extras/multipath KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" KERNEL=="device-mapper", NAME="mapper/control" And installed the multipath-tools package to get the devmap_name tool sys-fs/multipath-tools-0.4.7-r1 (Note that the above is not yet stable so I added it to /etc/portage/package.keywords). Now it works fine for me again.
(In reply to comment #28) On reboot I noticed that udev is now getting in the way of lvm. So I changed the rules to ignore the dm-[0-9] devices, but not the higher devices. I.e. I removed the star from the ignore line and uncommented the line again. Now it works fine as my encrypted usb devices show up as devices with a dm name higher than 9 and udev ignores my lvm volumes on the internal disks (note that my lvm volumes are inside luks encrypted partitions). # dm devices (ignore them) KERNEL=="dm-[0-9]", OPTIONS="ignore_device" # create a symlink named after the device map name # note devmap_name comes with extras/multipath KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" KERNEL=="device-mapper", NAME="mapper/control"
Adding gentopia to CC as new co-maintainers of gnome-mount
This issue should be resolved with newer HALs and gnome-mount combinations. I personally know for a fact it's resolved in hal 0.5.10_rc2 & gnome-mount 0.6 since I use this feature daily.
This fixed it for me. Sorry, I can't find the place where I found it. --- /var/tmp/paludis/sys-fs/udev-118/work/udev-118/udev_node.c 2007-12-18 15:50:56.000000000 -0800 +++ /root/udev_node.c 2008-01-20 03:16:12.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 #31) > This issue should be resolved with newer HALs and gnome-mount combinations. I > personally know for a fact it's resolved in hal 0.5.10_rc2 & gnome-mount 0.6 > since I use this feature daily. Closing then.
