Bug 484395 - hal, dbus errors on mount of usb external drives
hal, dbus errors on mount of usb external drives
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
11
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-06 10:45 EST by Tom
Modified: 2013-01-10 00:03 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 09:45:13 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)

  None (edit)
Description Tom 2009-02-06 10:45:55 EST
Description of problem: Since the release of F10 I have had consistent problems when mounting my usb external drives, one of which is a Western Digital WD-2500 250G with a single LUKS encrypted partition formatted ext-3, the other two are Sandisk Cruiser usb sticks, 4G and 8G, both with a single LUKS encrypted partition formatted ext-3. I have all the hal and dbus updates installed, as well as all current updates of all packages, but something is screwy somewhere. The errors surface on every power-up of the drives, sometimes they mount even with the errors, other times the mount fails.  If the mount succeeds, many times I have to su and 'umount' and 'cryptsetup luksClose /dev/mapper/luks_crypto*' the drive manually as the entry ends up in .hal-mtab~ as opposed to .hal-mtab.  'mv -v .hal-mtab~ .hal-mtab' will allow the unmount function when clicked to succeed though. This occurs on both i386, and x86_64, I personally use the latter.  I have tested against F9 i386 and x86_64 live cd, this problem does not occur under F9 at all.  This is quite serious, as I am unable to adequately access the drives.


Version-Release number of selected component (if applicable):
hal-0.5.12-14.20081027git.fc10.x86_64
(dbus-1.2.4-2.fc10.x86_64 ???)

How reproducible:
Almost 100% of the time

Steps to Reproduce:
1. Plug in usb drive (power on if WD-2500)
2. At prompt: Enter password, press OK
3.
  
Actual results: (Some of the messages I receive...)
Cannot mount volume.
Error org.freedesktop.Hal.Device.UnknownError.
An unknown error occurred

Cannot mount volume.
Error org.freedesktop.Hal.NoSuchDevice.
No device with id /org/freedesktop/Hal/devices/
volume_uuid_0cffd91c-5d4d-4c2d-b79b-8f52b46ed937

Unable to mount 250.1 GB Encrypted Data
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Unable to mount wd2500-luks
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Expected results:
Drive mounts and un-mounts properly

Additional info:
I have seen many suggestions regarding similar problems, and have tried many such as adding myself to the hal and dbus groups, this has no impact on the problem.  I have also tried authorizing myself in policy kit, to allow all drive operations, also no help.  Also, the problem occurs when running as root, so it's pretty severe.
Comment 1 Wojciech Sluszniak 2009-04-11 12:07:32 EDT
Same problems here. I'm using LaCie external 2,5 inch drive (which is actually Hitachi  HTS543232L9A300 drive). One encrypted partition (primary) and one ntfs (extended).
Fedora 10 is fully updated.
Comment 2 cornel panceac 2009-04-29 03:15:34 EDT
a similar problem here:i have one encrypted partition on a 40 gb hitachi hard disk, trying to mount it asked for password then error, in f9 live, f10 live and f11 snapshot1 live cds. in f11 preview live cd i get only "unable to mount location. can't mount file", when i try to open the <hard disk icon>.
alos, on preview live cd i see two 3.2 gb partitions wich i am unable to access, and doesn't really exist on this thinkpad x40. so for me, the live cd storage support is worst in f11preview. 

the live cd's are all i686.
Comment 3 Richard Hughes 2009-05-11 12:02:26 EDT
Could you please report success or failure with the Fedora 12 Beta live cd, or better with rawhide. The stack has been completely re-written for F12, and it's likely the bug is already fixed. See http://blog.fubar.dk/?p=105 for more details.
Comment 4 Wojciech Sluszniak 2009-05-11 19:07:29 EDT
It looks promising, but I haven't tested it for a long time.
(Fedora 10.93)
Comment 5 Tom 2009-05-11 21:22:39 EDT
The previous comment from Richard references Fedora 12, is this intentional or a typo as I see no indication that Fedora 12 development has began let alone progressed to beta stage.  Is this meant to be a reference to F11, if so, I have  tried F11 alpha, but not beta, alpha of F11, had the same issue at the time I tested it some months ago.
Comment 6 Richard Hughes 2009-05-12 04:12:35 EDT
(In reply to comment #5)
> The previous comment from Richard references Fedora 12, is this intentional or
> a typo as I see no indication that Fedora 12 development has began let alone
> progressed to beta stage.  Is this meant to be a reference to F11, if so, I
> have  tried F11 alpha, but not beta, alpha of F11, had the same issue at the
> time I tested it some months ago.  

Yes, sorry. F11. I'm one release ahead :-)
Comment 7 Richard Hughes 2009-05-12 04:16:47 EDT
>John Poelstra <poelstra@redhat.com> changed:
>         Version|10                      |rawhide
>          Blocks|                        |446452(F11Blocker)

Why?!

You've changed the version to rawhide, and in rawhide it's not even HAL that handles this, it's DeviceKit-disks.

This is reported on F10, and the reporters haven't even tried a new rawhide for success or failure yet, with any meaningful debugging. The stack has been _completely_ rewritten from F10 to F11.

F11Blocker doesn't mean "this bug is important" it means that it blocks the release, and when it works for me with an encrypted external USB drive (which I use everyday) and when there are workarounds (luksOpen) then I really don't think this is a blocker.
Comment 8 Tom 2009-05-13 07:15:32 EDT
Richard, I just tried the F11 x86_64 preview release live cd.  When I plug in any of my encrypted storage devices, I get absolutely nothing now.  There is no indication from gnome that it is even aware that a device was added, let alone that the device has a luks partition.  This has changed since I had the alpha of F11 installed; under alpha the device was recognized but failed to mount cleanly.

The encrypted partitions can still be mounted via the cli, but this is really unacceptable in a modern os with native support for encrypted file systems.

I'm gonna have to say that I agree with this bug being left as a blocker, this really must be fixed as I am sure that there are many users that carry confidential data on usb drives and such, and not all of them want to manually use cryptsetup to mount their drives.
Comment 9 Jesse Keating 2009-05-18 14:08:57 EDT
This is working for me as well with encrypted usb stick.  I agree with Richard that this isn't a blocker, just a bug we'd like to see fixed.  Removing blocker flag.
Comment 10 Mikko Huhtala 2009-05-20 02:39:45 EDT
> This is working for me as well with encrypted usb stick.

On my machine, it depends on the USB stick. Some work, some never do. It is a show-stopping problem if you happen to have the wrong make of a USB stick.

See comments in #498430 (which is probably a duplicate of this bug).
Comment 11 Tom 2009-05-20 06:54:50 EDT
I have three machines at home, all different makes/models, all recent builds. Since I filed this bug, I have acquired two additional external drives, an Iomega eGO (bus powered), another Western Digital (AC powered), and another USB stick.  I have encrypted them and tried this on all machines, and it occurs regardless of which machine, or media I use.

If they are not encrypted, they work fine 100% of the time.

Guess I'll just wait and see whether this is going to work in the F11 final release, before I review my options.
Comment 12 Mikko Huhtala 2009-05-21 02:10:08 EDT
I've tried one USB hard drive and two sticks. None of them have encrypted file systems. One stick does not work (1307:0163), the other stick and the hard drive do.
Comment 13 Mikko Huhtala 2009-05-27 11:52:52 EDT
I'm cross-posting this to here and #498430. Sorry about that.

The problematic USB stick drive now works without complaints from dbus or others. It gets mounted automatically as /media/4906-EAB6 instead of the usual /media/disk, but otherwise it seems to work correctly. The versions of dbus, hal and udev are unchanged, so I'm guessing that it's the kernel that made the difference (currently 2.6.29.3-155.fc11.i686.PAE).
Comment 14 Tom 2009-05-29 21:51:38 EDT
I haven't been monitoring this thread lately since it appears that I may continue to have problems into or past F11.  After more testing with with F11 preview I can say with certainty, that at least for me, F11 is not fixing things, it's making them worse, and enabling rawhide in F10, fixes absolutely nothing. 

This is definitely a Fedora specific bug, as OpenSUSE, and Ubuntu, recognize and mount properly.  But that said, I don't like either of them so I'll have to wait things out and hope that this gets fixed.  With the testing that I have done, there is next to no indication as to where the actual problem is, besides what I initially reported in the bug report.  I tried looking at the code, but good lord!  Way to much for a guy that hasn't programmed in C++ since 1998.

Hopefully someone will have an AH HA! moment and inadvertently figure out what causes this, or make sure the problems don't worsen in F11.
Comment 15 Bug Zapper 2009-06-09 07:06:19 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Tom 2009-06-10 09:45:13 EDT
I'm not sure what changed between the preview release of FC11 and the final version, but I can say that it certainly appears that as of yesterdays release, this problem ceased to exist in Fedora.

Everything now seems to work properly, no problems with mounting, unmounting, or accessing, either encrypted or unencrypted media on removable or fixed drives.

I would say this bug does not apply to the current release of FC11 and can be closed...

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