Bugzilla – Bug 105445
USB storrage not mounted
Last modified: 2007-06-05 11:04:22 UTC
I tested on beta2 and beta1 and my usbstorage does not created subfs mount point (it works on SL9.3), but cardreader created subfs mount point well. on beta2 ======== wintermute:~ # lsusb Duplicate product spec at line 2453 product 0846:4240 WG111 WiFi Bus 005 Device 009: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 002: ID 046d:c00e Logitech, Inc. Optical Mouse Bus 002 Device 001: ID 0000:0000 Bus 001 Device 003: ID 046d:c402 Logitech, Inc. Marble Mouse (2-button) Bus 001 Device 001: ID 0000:0000 snip /var/log/messages Aug 18 11:34:43 wintermute kernel: scsi7 : SCSI emulation for USB Mass Storage devices Aug 18 11:34:43 wintermute kernel: usb-storage: device found at 9 Aug 18 11:34:43 wintermute kernel: usb-storage: waiting for device to settle before scanning Aug 18 11:34:48 wintermute kernel: Vendor: FUJITSU Model: MHF2043AT Rev: 0 0 Aug 18 11:34:48 wintermute kernel: Type: Direct-Access ANSI SCSI revision: 00 Aug 18 11:34:48 wintermute kernel: SCSI device sdb: 8452080 512-byte hdwr sectors (4327 MB) Aug 18 11:34:48 wintermute syslog-ng[18359]: Changing permissions on special file /dev/xconsole Aug 18 11:34:48 wintermute syslog-ng[18359]: Changing permissions on special file /dev/tty10 Aug 18 11:34:48 wintermute kernel: sdb: assuming drive cache: write through Aug 18 11:34:48 wintermute kernel: SCSI device sdb: 8452080 512-byte hdwr sectors (4327 MB) Aug 18 11:34:48 wintermute kernel: sdb: assuming drive cache: write through Aug 18 11:34:48 wintermute kernel: sdb: sdb1 Aug 18 11:34:48 wintermute kernel: Attached scsi disk sdb at scsi7, channel 0, id 0, lun 0 Aug 18 11:34:48 wintermute kernel: Attached scsi generic sg1 at scsi7, channel 0, id 0, lun 0, type 0 Aug 18 11:34:48 wintermute kernel: usb-storage: device scan complete on SL9.3 (another machine) ======== # lsusb Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 003: ID 046d:c016 Logitech, Inc. Optical Mouse Bus 001 Device 002: ID 04f2:0116 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 0000:0000 Bus 005 Device 012: ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter Bus 005 Device 001: ID 0000:0000 snip /var/log/messages Aug 18 11:44:52 brucus kernel: usb 5-4: new high speed USB device using ehci_hcd and address 12 Aug 18 11:44:52 brucus kernel: scsi3 : SCSI emulation for USB Mass Storage devices Aug 18 11:44:52 brucus kernel: usb-storage: device found at 12 Aug 18 11:44:52 brucus kernel: usb-storage: waiting for device to settle before scanning Aug 18 11:44:57 brucus kernel: Vendor: FUJITSU Model: MHF2043AT Rev: 0 0 Aug 18 11:44:57 brucus kernel: Type: Direct-Access ANSI SCSI revision: 00 Aug 18 11:44:57 brucus kernel: SCSI device sda: 8452080 512-byte hdwr sectors (4327 MB) Aug 18 11:44:57 brucus kernel: sda: assuming drive cache: write through Aug 18 11:44:57 brucus kernel: SCSI device sda: 8452080 512-byte hdwr sectors (4327 MB) Aug 18 11:44:57 brucus kernel: sda: assuming drive cache: write through Aug 18 11:44:57 brucus kernel: sda: sda1 Aug 18 11:44:57 brucus kernel: Attached scsi disk sda at scsi3, channel 0, id 0, lun 0 Aug 18 11:44:57 brucus kernel: Attached scsi generic sg0 at scsi3, channel 0, id 0, lun 0, type 0 Aug 18 11:44:57 brucus kernel: usb-storage: device scan complete Aug 18 11:44:58 brucus /etc/hotplug.d/block/50-hwscan.hotplug[20674]: new block device /block/sda Aug 18 11:44:58 brucus /etc/hotplug.d/block/50-hwscan.hotplug[20755]: new block device /block/sda/sda1 Aug 18 11:44:58 brucus hal-subfs-mount[20770]: registered at resmgrd and called(0) /bin/mount -t subfs -o fs=floppyfss,sync,procuid,nosuid,nodev,exec /dev/sda1 "/media/M_STN__DISK"
Please attach output of lshal if the device is attached
Created attachment 46463 [details] Output of lshal
Looks OK. Can you please: * unplug the mass storage device * $ rchal stop * $ hald --daemon=no --verbose=yes --retain-privileges * Wait for hald to settle down * Plug in the usb storage device and send the log messages occured since hald settled.
Created attachment 46485 [details] hald log
There is a error in HAL I think. The volume is detected as a vfat partition with volume label 'M326STN326 DISK' can you please do this as root: * rchal stop * strace -fqrv -s 512 -o /tmp/hal_strace hald --retain-privileges --verbose=yes --daemon=no * whait 30 sec * attach the device * whait 10 sec * stop strace and attach the file /tmp/hal_strace to this bug (please tar -cjf the file)
Created attachment 46659 [details] strace of hal
did you see the partition in the yast partitioner module? Can you change the volume label vor testing to TESTPARTITION ? What is the current volume label?
JFYI: Tomorrow our admins will disconnect network to our office from 09:00 to 14:00. Yes I see the partition in the yast partitioner module. I don't know how can I change volume label, if you know, please do it by yourself (I have backuped data on this disk).
Hm, I tried to format the device and add a new partition (FAT and Ext2) with the yast2 partitioner. I can remove the existing volume, but I can't add a new. I get always a error message from yast: --------------- Error Storage modification failed System error code was: -1007 Failure occurred during following action: Creating partition /dev/sdb1 --------------- Looks as there is more than only a problem with HAL. No Idea what the problem is. Now I get volume in HAL and can't also not mount directly. There is no sdb1 anymore. I reassign this to the yast guys. They must say, what the reason for this error is.
Parted failed to create the partition. YaST2 logs will show you more information.
Hm ... this was really strange. I couldn't format the device with ext2 and also problems to format the device with FAT. Need more than 5 trials to overwrite the current partition and create a full new FAT partition. And first as this worked I could format the device with ext2. There must be a problem with something. I think maybe with volumelabel or a bug in Yast. I attach all yast2 logs to the bug and reassign again to the yast guys.
Created attachment 46783 [details] Yast Logs
YaST told parted a cylinder number that is too big. So this should be a duplicate of bug #105441 and fixed in Beta 3. Please try again with Beta 3. *** This bug has been marked as a duplicate of 105441 ***
I don't understand how hal dependent on cylinder number, but which rpms I need update to test fix of this bug?
The problem with YaST2 in comment #13 should be fixed with the latest yast2-storage.
I can't confirm fix, because the previous (original) partition was replaced and now mount point creates on beta1 too.
Yes, this is not fixed for the HAL part. I tested a littlebit with the string for the volume lable: 'M\326STN\326 DISK\'. Looks like D-BUS don't accept the string. I get always this error message from dbus: 29973: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus- connection.c line 2764. This is normally a bug in some application using the D-BUS library. We checked this an it happen with character >= 0x80 I reassign this bug to timo as D-BUS Bug
to reproduce: hal-set-property --udi /org/freedesktop/Hal/devices/computer --key xxx --string `echo -e '\x80'` hal-set-property --udi /org/freedesktop/Hal/devices/computer --key xxx --string `echo -e '\x79'`
This is not a DBUS bug. This is a problem/bug of HAL. DBUS accept only valid utf8 strings. HAL must check (and if needed fix the string) for valid utf8 befor send string to DBUS.
added fix for new package
close bug now, package submitted