Bug 209590

Summary: Fail to mount encrypted USB flash disk
Product: [Fedora] Fedora Reporter: Michal Babej <mbabej>
Component: udevAssignee: Harald Hoyer <harald>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: agk, davidz, desktop-bugs, dshaw, error, marc_schwartz, mbroz, nphilipp, pat, piergiorgio.sartor, redhat, smohan, wboessen
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-08 12:58:13 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Patch to /etc/udev/rules.d/50-udev.rules to make gnome-mount work again for luks encrypted volumes
Updated patch file for Jan 15, 2007 udev update. Apply to /etc/udev/rules.d/50-udev.rules none

Description Michal Babej 2006-10-06 04:10:00 EDT
Description of problem:
GNOME fails to mount encrypted USB flash disk.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Insert encrypted USB flask disk
2. GNOME recognizes the disk and prompts for password.
3. after inserting password, nothing happens
Actual results:
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.

Expected results:
Mount of device

Additional info:
The device was encrypted using "cryptsetup luksFormat" in FC5.
Comment 2 Wander Boessenkool 2006-10-25 15:07:50 EDT
Created attachment 139385 [details]
Patch to /etc/udev/rules.d/50-udev.rules to make gnome-mount work again for luks encrypted volumes
Comment 3 David Zeuthen 2006-10-25 15:17:53 EDT
Yes, Harald please remove this rule (also for RHEL5). The right fix is in a
later kernel where dm is fixed. Thanks.
Comment 4 David Zeuthen 2006-10-25 17:01:19 EDT
The kernel patch mentioned in comment 3 is available here

Comment 5 Harald Hoyer 2006-10-26 10:30:43 EDT
ignore_device was add because of bug #204157
Comment 6 Milan Broz 2006-10-26 12:28:43 EDT
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.
Comment 7 David Zeuthen 2006-10-29 17:41:26 EST
*** Bug 212875 has been marked as a duplicate of this bug. ***
Comment 8 Jens Lautenbacher 2007-01-16 21:19:29 EST
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
annoying :-) 

Would it be possible to comment in public about why this rule can't be removed?
Comment 9 Marc Schwartz 2007-01-16 23:15:17 EST
Created attachment 145774 [details]
Updated patch file for Jan 15, 2007 udev update. Apply to /etc/udev/rules.d/50-udev.rules
Comment 10 Marc Schwartz 2007-01-16 23:17:24 EST
Thanks for the reminder on this patch. I had forgotten about it.

With the new patch (attached to this report), things are working again.
Comment 11 Harald Hoyer 2007-01-17 06:26:23 EST
*** Bug 216538 has been marked as a duplicate of this bug. ***
Comment 12 Harald Hoyer 2007-01-17 06:28:26 EST
From Alasdair Kergon (agk@redhat.com)

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.
Comment 13 David Zeuthen 2007-01-30 13:41:28 EST
*** Bug 218840 has been marked as a duplicate of this bug. ***
Comment 14 Michal Babej 2007-06-08 12:58:13 EDT
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.