Bug 239496

Summary: Hal doesn't mount USB portable hard drive
Product: [Fedora] Fedora Reporter: Oded Arbel <oded>
Component: halAssignee: David Zeuthen <davidz>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: mclasen, oliver, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-07 01:42:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
hal log from inserting a USB key that doens't get auto mounted by hal none

Description Oded Arbel 2007-05-08 21:07:22 UTC
Description of problem:
Ever since test4 came out (and I ran yum upgrade from my test3 installation), my
Western Digital MyBook portable harddrive isn't automatically mounted by hal. It
used to be that whenever I boot the computer I have to turn the harddrive off
and on again for hal to detect and mount it, but now its not mounting it at all.

A few USB disk-on-key style devices I have lying around are mounted properly, as
well as a palm NVFS exported using a USB mass storage software called "Softick
Card Export 2". All of them are detected and mounted by hal properly, but not
the WD portable hard drive.

Looking at /var/log/messages, here's the WD My Book connecting:
May  8 23:53:51 normandi kernel: usb 2-4: new high speed USB device using
ehci_hcd and address 4
May  8 23:53:52 normandi kernel: usb 2-4: configuration #1 chosen from 1 choice
May  8 23:53:52 normandi kernel: Initializing USB Mass Storage driver...
May  8 23:53:52 normandi kernel: scsi6 : SCSI emulation for USB Mass Storage devices
May  8 23:53:52 normandi kernel: usbcore: registered new interface driver
usb-storage
May  8 23:53:52 normandi kernel: USB Mass Storage support registered.
May  8 23:53:53 normandi scanbuttond: scanbtnd_open failed, error code: -19
May  8 23:53:53 normandi scanbuttond: scanbtnd_open returned -ENODEV, device
rescan will be performed
May  8 23:53:55 normandi scanbuttond: meta-backend: detaching scanner: "Canon
CanoScan LiDE 30"
May  8 23:53:55 normandi scanbuttond: meta-backend: attached scanner "Canon
CanoScan LiDE 30"
May  8 23:53:57 normandi kernel: scsi 6:0:0:0: Direct-Access     WD       3200JB
External  0108 PQ: 0 ANSI: 0
May  8 23:53:57 normandi kernel: SCSI device sdb: 625142448 512-byte hdwr
sectors (320073 MB)
May  8 23:53:59 normandi kernel: sdb: Write Protect is off
May  8 23:53:59 normandi kernel: sdb: assuming drive cache: write through
May  8 23:54:01 normandi kernel: SCSI device sdb: 625142448 512-byte hdwr
sectors (320073 MB)
May  8 23:54:02 normandi kernel: sdb: Write Protect is off
May  8 23:54:03 normandi kernel: sdb: assuming drive cache: write through
May  8 23:54:04 normandi kernel:  sdb: sdb1
May  8 23:54:05 normandi kernel: sd 6:0:0:0: Attached scsi disk sdb
May  8 23:54:07 normandi kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

and that's it. For comparison, here a minute later is a USB dok style media
player connecting:

May  8 23:54:43 normandi kernel: usb 2-6: new high speed USB device using
ehci_hcd and address 5
May  8 23:54:43 normandi kernel: usb 2-6: configuration #1 chosen from 1 choice
May  8 23:54:43 normandi kernel: scsi7 : SCSI emulation for USB Mass Storage devices
May  8 23:54:43 normandi scanbuttond: scanbtnd_open failed, error code: -19
May  8 23:54:43 normandi scanbuttond: scanbtnd_open returned -ENODEV, device
rescan will be performed
May  8 23:54:46 normandi scanbuttond: meta-backend: detaching scanner: "Canon
CanoScan LiDE 30"
May  8 23:54:46 normandi scanbuttond: meta-backend: attached scanner "Canon
CanoScan LiDE 30"
May  8 23:54:48 normandi kernel: scsi scan: INQUIRY result too short (5), using 36
May  8 23:54:49 normandi kernel: scsi 7:0:0:0: Direct-Access     GENERIC  USB
DISK DEVICE  1.00 PQ: 0 ANSI: 0 CCS
May  8 23:54:46 normandi kernel: SCSI device sdc: 2000561 512-byte hdwr sectors
(1024 MB)
May  8 23:54:47 normandi kernel: sdc: Write Protect is off
May  8 23:54:49 normandi kernel: sdc: assuming drive cache: write through
May  8 23:54:50 normandi kernel: SCSI device sdc: 2000561 512-byte hdwr sectors
(1024 MB)
May  8 23:54:51 normandi kernel: sdc: Write Protect is off
May  8 23:54:53 normandi kernel: sdc: assuming drive cache: write through
May  8 23:54:54 normandi kernel:  sdc: unknown partition table
May  8 23:54:55 normandi kernel: sd 7:0:0:0: Attached scsi removable disk sdc
May  8 23:54:56 normandi kernel: sd 7:0:0:0: Attached scsi generic sg3 type 0
May  8 23:54:51 normandi hald: mounted /dev/sdc on behalf of uid 500

and we can see hal mounting it.

Version-Release number of selected component (if applicable):
0.5.9-6.fc7

Comment 1 Oliver Cole 2007-08-06 20:45:44 UTC
Created attachment 160771 [details]
hal log from inserting a USB key that doens't get auto mounted by hal

I see this issue in hal-0.5.9-8.fc7. My USB key is loaded by the kernel:

Aug  6 21:14:40 ascension kernel: sd 12:0:0:0: [sdh] Attached SCSI removable
disk

But no "hald: mounted...". It does however work fine with cards inserted into
my USB card reader, possibly because the actual USB device was connected at
boot time?

Attached is hald --verbose=yes output.

Comment 2 Bug Zapper 2008-04-04 00:36:36 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 3 Bug Zapper 2008-05-07 01:42:50 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp