Description of problem: Attaching a USB floppy drive without a media give in 'dmesg': usb 5-1: new full speed USB device using uhci_hcd and address 6 scsi6 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 6 usb-storage: waiting for device to settle before scanning Vendor: SONY Model: USB-FDU Rev: 5.01 Type: Direct-Access ANSI SCSI revision: 00 Attached scsi removable disk sdc at scsi6, channel 0, id 0, lun 0 usb-storage: device scan complete and that is it. Adding or ejecting media will not show any other activity anywhere. When plugging a USB floppy drive with a floppy in it a picture is somewhat different: usb 5-1: new full speed USB device using uhci_hcd and address 7 scsi7 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning Vendor: SONY Model: USB-FDU Rev: 5.01 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdc: 1440 512-byte hdwr sectors (1 MB) sdc: Write Protect is on sdc: Mode Sense: 00 46 1e 80 sdc: assuming drive cache: write through SCSI device sdc: 1440 512-byte hdwr sectors (1 MB) sdc: Write Protect is on sdc: Mode Sense: 00 46 1e 80 sdc: assuming drive cache: write through sdc: unknown partition table Attached scsi removable disk sdc at scsi7, channel 0, id 0, lun 0 usb-storage: device scan complete Still no changes in /etc/fstab though. There will be an entry if I am __booting__ with a USB floppy driver already attached and with an inserted media but this does not mean at all that it will be mounted in any moment. After I got "sdc: unknown partition table" I can mount that floppy without any trouble with mount -r -t vfat /dev/sdc /some/mount/point and read it from a command line or via nautilus. On the top of it my older policy file in /usr/share/hal/fdi/95userpolicy which says: <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- --> <!-- Use 'usbfloppy' for USB floppy drives --> <deviceinfo version="0.2"> <device> <match key="storage.bus" string="usb"> <match key="storage.drive_type" string="floppy"> <merge key="storage.policy.desired_mount_point" type="string">usbfloppy</merge> </match> </match> </device> </deviceinfo> which is not that surprising because 'lshal' shows for 'USB-FDU' a string 'disk' for storage.drive_type and is totally numb about desired_mount_point. This is a sharp regress in a comparison with an older situation where all of the above used to work (including a capability to specify some sane mountpoint which does not jump around). Version-Release number of selected component (if applicable): hal-0.5.1-1 How reproducible: always
Err, in the original report a corresponding fragment should reaad: " ... my older policy file .... does not work anymore ...". Editing through a bugzilla peephole is not that effective.
On what kernel does this happen, try one that is pre 2.6.12-rc3 (this one looks like a duplicate of bug 156167). Also, please try to attach the output of lshal. I've also changed version from 'fc3' to 'devel' since hal 0.5.1 is not in fc3.
Created attachment 114129 [details] a full output from lshal with 'USB-FDU' attached > I've also changed version from 'fc3' to 'devel' since hal 0.5.1 is > not in fc3. Sorry, this was supposed to be devel and not fc3. I forgot to switch distribution tag. > On what kernel does this happen, At least on these: 2.6.11-1.1287_FC4 2.6.11-1.1286_FC4 2.6.11-1.1284_FC4 > try one that is pre 2.6.12-rc3 Hm, I do not have a supply of kernels going that far back. > (this one looks like a duplicate of bug 156167). Possibly, although not recognized floppy device may, or may not, be the same thing. > Also, please try to attach the output of lshal. OK. 'lsusb' does recognize the device properly.
Created attachment 114130 [details] an outptut from lsusb for 'USB-FDU' I was not paying attention and added these two attachments to bug 156167 too.
oh, ok, but you could add the output of lshal instead of lsusb?
Ah, ok, I see the output of lshal in comment 3. As visible it says storage.bus = 'scsi', not storage.bus = 'usb'. This happens because the scsi host interface event is before the USB interface events (even though the former references the latter). Thus, duplicate of bug 156167. *** This bug has been marked as a duplicate of 156167 ***