Description of problem: Encrypted USB disk fails to automount under gnome. The device can be mounted manually. Version-Release number of selected component (if applicable): How reproducible: always Steps to reproduce: 1. Insert encrypted USB flask disk 2. GNOME recognizes the disk and prompts for password. 3. after inserting password, nothing happens. 4. Mounting the disk manually works. Actual results: gnome-mount recognize the disk, unlocks it, but never mounts Expected results: disk should be mounted Additional info: We need to remove 90-dm rule from udev, as I understand the kernel patch required is in. ( https://bugzilla.redhat.com/show_bug.cgi?id=214639 ) reproducer : $ cryptsetup --verbose --verify-passphrase luksFormat /dev/sda $ cryptsetup luksOpen /dev/sda sda $ mkfs.ext3 /dev/mapper/sda $ cryptsetup luksClose sda $ gnome-mount --verbose -d /dev/sda The above will unlock the device, but not mount it. I am able to mount it manually $ mount /dev/mapper/luks_crypto_657a9e2f-887a-484c-b34b-14eb1475f022 /mnt/media From hald/linux/blockdev.c, we are able to see that when we are using whole blockdev, we should look for fakevolume, rather than target itself void hotplug_event_begin_add_blockdev (... .. if (target != NULL) { HalDevice *slave_volume; char *ftarget = g_strconcat (target, "/fakevolume", NULL); slave_volume = hal_device_store_match_key_value_string (hald_get_gdl (), "linux.sysfs_path", ftarget); g_free(ftarget); .. reasoning : whole blockdev when encrypted, create a fakevolume, rahter than then sysfs_path we need to look for.
Created attachment 358830 [details] patch
Created attachment 360732 [details] patch fixes one bug. look at both blockdev, and partition.
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~ RHEL 5.5 Beta has been released! There should be a fix present in this release that addresses your request. Please test and report back results here, by March 3rd 2010 (2010-03-03) or sooner. Upon successful verification of this request, post your results and update the Verified field in Bugzilla with the appropriate value. If you encounter any issues while testing, please describe them and set this bug into NEED_INFO. If you encounter new defects or have additional patch(es) to request for inclusion, please clone this bug per each request and escalate through your support representative.
Hmm. I've made the HAL change, and udev should be fixed now, but it doesn't seem to work (although I could have sworn it worked when testing a few months ago). I can upload the hal rpm's somewhere public if you want to test.
Okay, the HAL part stays in, and we file another bug with udev to remove the 90-dm rule. If you're testing this you need to comment out the ignore_device line in /etc/udev/rules.d/90-dm.rules before you plug in the USB device. I'll add a note to the errata.
I can verify the above information resolves the problem of gnome failing to automount an encrypted USB disk. I was running 5.4 with the 2.6.18-164.11.1.el5 kernel and hal-0.5.8.1-52 and hal-devel-0.5.8.1-52 and was experiencing the same problem. I followed the advice above and downloaded the updated hal packages from 5.5 beta (hal-0.5.8.1-58 and hal-devel-0.5.8.1-58). After commenting out the line in /etc/udev/rules.d/90-dm.rules and restarting the system, the automount worked as expected with the encrypted USB device. Thanks for the help!
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0256.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days