Red Hat Bugzilla – Bug 209590
Fail to mount encrypted USB flash disk
Last modified: 2013-07-31 19:10:03 EDT
Description of problem:
GNOME fails to mount encrypted USB flash disk.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert encrypted USB flask disk
2. GNOME recognizes the disk and prompts for password.
3. after inserting password, nothing happens
i did some further investigation on this. the device doesn't get mounted,
however, it gets mapped - i can see the luks_crypto_XXX... device in /dev/mapper.
Mount of device
The device was encrypted using "cryptsetup luksFormat" in FC5.
Created attachment 139385 [details]
Patch to /etc/udev/rules.d/50-udev.rules to make gnome-mount work again for luks encrypted volumes
Yes, Harald please remove this rule (also for RHEL5). The right fix is in a
later kernel where dm is fixed. Thanks.
The kernel patch mentioned in comment 3 is available here
ignore_device was add because of bug #204157
Kernel fix mentioned in comment 3 and comment 4 will be in upstream kernel 2.6.19.
Later rawhide kernels based on 2.6.19-rcX should have this patch compiled in.
*** Bug 212875 has been marked as a duplicate of this bug. ***
unfortunately I am not authorized to see #204157 so I can't comment on what this
is about, but always having to patch the ude rules by hand becomes a bit
Would it be possible to comment in public about why this rule can't be removed?
Created attachment 145774 [details]
Updated patch file for Jan 15, 2007 udev update. Apply to /etc/udev/rules.d/50-udev.rules
Thanks for the reminder on this patch. I had forgotten about it.
With the new patch (attached to this report), things are working again.
*** Bug 216538 has been marked as a duplicate of this bug. ***
From Alasdair Kergon (firstname.lastname@example.org)
udev needs to completely ignore the 'add' event, and instead act on the 'change'
event. Until the change event arrives under no circumstances should udev
attempt to open the dm device or query any dm device properties. In future lvm2
and other applications will then wait until udev has completed processing the
'change' event before proceeding. udev will then be able to assume full
responsibility for /dev/mapper - the 'change' event will cause the nodes to be
added to /dev. There is no way to do this correctly in response to the existing
'add' event, because the dm properties udev needs to query are not yet defined
in-kernel at this point. The 'change' event is the new signal that the
properties are now fully defined.
*** Bug 218840 has been marked as a duplicate of this bug. ***
This bug is fixed in F7 (2.6.21-1.3194.fc7), and FC6 now has 2.6.20 kernels
(though i didn't test it), so i think this bug can be closed.