Bug 449226 - HAL mounting of encrypted USB device doesn't work.
HAL mounting of encrypted USB device doesn't work.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
9
i686 Linux
low Severity low
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-31 12:48 EDT by Nick Lamb
Modified: 2013-03-05 22:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-09 20:31:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
system logs of HAL (verbose, logging to syslog) (52.95 KB, text/plain)
2008-05-31 12:48 EDT, Nick Lamb
no flags Details

  None (edit)
Description Nick Lamb 2008-05-31 12:48:15 EDT
Description of problem:

HAL-assisted mounting of encrypted devices doesn't work.

Version-Release number of selected component (if applicable):
hal-0.5.11-1.fc9.i386

How reproducible:

I've tried this a few dozen times. It worked once, but I wasn't logging that
time so I have no idea how it was different.


Steps to Reproduce:
1. Create a LUKs encrypted partition on a USB drive
2. Insert USB drive
3. At the prompt enter the LUKS passphrase
4. Check to see if the encrypted partition was mounted
  
Actual results:

The partition isn't mounted, the device mapper is set up, but the mount never
takes place.

Expected results:

The partition should be mounted, and visible on the GNOME desktop / in Nautilus.

Additional info:

I am attaching a log of the mess from the HAL daemon for a typical hot plug
event. A USB storage device is inserted and becomes /dev/sdb, the objective is
to get the only partition unlocked with LUKS and mounted, and the logs show HAL
not quite managing to achieve this.

For me the alarm bells starting ringing when a REMOVE event shows up in the
middle of the proceedings. Obviously having one part of HAL trying to tear all
this down while another is trying to create it is a recipe for disaster. Should
this REMOVE event occur? I didn't remove anything, but perhaps the LUKS setup
causes the kernel device mapper to emit a REMOVE for some insane reason?

Running kernel is kernel-2.6.25.3-18.fc9.i686
installed udev is udev-120-5.20080421git.fc9.i386
Comment 1 Nick Lamb 2008-05-31 12:48:15 EDT
Created attachment 307283 [details]
system logs of HAL (verbose, logging to syslog)
Comment 2 Scott Glaser 2009-04-09 14:22:00 EDT
Are you still running Fedora 9, or have you upgraded to 10 or Rawhide? In
either case, can you let us know whether the issue is still happening, and give
the current version of the HAL packages you're using?


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Nick Lamb 2009-04-09 20:31:39 EDT
I am running Fedora 9

I have just re-tested as requested. I was unable to reproduce the problem after several attempts this evening. So I believe that over the passing months the issue has been fixed (or masked by other changes), installed versions of packages I deem likely to be related are:

hal-0.5.11-2.fc9.i386
udev-124-2.fc9.i386

Therefore I've marked the bug as CLOSED ERRATA on the basis that one of the existing bug fix releases for these packages probably included the relevant fix. If a different resolution is more appropriate feel free to change it.

Note You need to log in before you can comment on or make changes to this bug.