Description of problem: Here's a for what it's worth informational bug report. I have a seagate 160 gig drive in an external usb enclosure. I realized that I had borked the formating of the drive when Solaris 10 would not mount the drive but MS Windows Professional 2000, Fedora 5 and Fedora 7 would mount the drive with no problem. (Sadly I can only use Solaris 10 at work, if I want a stable development platform. We bought AMD boxes in the hopes of someday using Linux but I digress. :-( ) fdisk -l reports ... Disk /dev/sde: 160.0 GB, 160041885184 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sde1 * 1 19457 156288321 6 FAT16 I was coping the files of the drive so that I could reformat it with a FAT32 ID. The copy worked find but would fail part way through. I thought heat would was a factor and tried again. The copied failed again. This time I tried coping files from the failed point onward. However, I started at the very last directory and worked backward. These worked ok. So I got brave and launched the rest of directory copies. I then went of the the Harry Potter book release thing with the kids. Sure enough the copy failed again. Well two hours waiting in line allowed heat to be factored out of the equation. I copied individual directories again until I got to the last directory where the copy failed. The other directories where light copies and the USB enclosure has a fan blowing over the drive. The room air is cool. The copy command was in the form of yes | cp -pR ISDocs20060525/AppDevlTools/OracleODBC /160bk/AppDevlTools When the copy command came to an exe file and I believe finished the copy an error message for the next file say: cp: overwrite `/160bk/AppDevlTools/OracleODBC/odbcIntoOracle.doc'? cp: overwrite `/160bk/AppDevlTools/OracleODBC/omwb_92012.exe'? cp: cannot stat `ISDocs20060525/AppDevlTools/OracleODBC/Oracle Migration Kit User\'s Guide -- Contents.htm': No such file or directory The 'cannont stat' and 'No such file or directory error messages' are from the /media/disk-1/ source directory being unmounted. /var/log/messages shows Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd and address 26 Jul 21 02:13:03 mowgli kernel: usb 5-4: device descriptor read/64, error -71 Jul 21 02:13:03 mowgli kernel: usb 5-4: device descriptor read/64, error -71 Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd and address 27 Jul 21 02:13:03 mowgli kernel: usb 5-4: device not accepting address 27, error -71 Jul 21 02:13:03 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd and address 28 Jul 21 02:13:04 mowgli kernel: usb 5-4: device not accepting address 28, error -71 Jul 21 02:13:34 mowgli kernel: scsi 8:0:0:0: rejecting I/O to dead device Jul 21 02:13:34 mowgli kernel: FAT: unable to read inode block for updating (i_pos 792171667) Jul 21 02:40:24 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd and address 29 Jul 21 02:40:24 mowgli kernel: usb 5-4: configuration #1 chosen from 1 choice Jul 21 02:40:24 mowgli kernel: scsi9 : SCSI emulation for USB Mass Storage devices Jul 21 02:40:24 mowgli kernel: scsi 4:0:0:0: rejecting I/O to dead device Jul 21 02:40:24 mowgli kernel: scsi 4:0:0:0: rejecting I/O to dead device ... Jul 21 03:00:30 mowgli kernel: FAT: Directory bread(block 152615) failed Jul 21 03:02:48 mowgli kernel: usb 5-4: USB disconnect, address 29 A power off and a power on of the Ultra USB enclosure automounts the disk to /media/disk-1 After the drive is automounted I the following in /var/log/messages Jul 21 03:02:48 mowgli kernel: usb 5-4: USB disconnect, address 29 Jul 21 03:02:48 mowgli hald[2443]: forcibly attempting to lazy unmount /dev/sde1 as enclosing drive was disconnected Jul 21 03:02:48 mowgli hald: unmounted /dev/sde1 from '/media/disk-1' on behalf of uid 0 Jul 21 03:02:53 mowgli kernel: usb 5-4: new high speed USB device using ehci_hcd and address 30 Jul 21 03:02:54 mowgli kernel: usb 5-4: configuration #1 chosen from 1 choice Jul 21 03:02:54 mowgli kernel: scsi10 : SCSI emulation for USB Mass Storage devices An individual file copy succeeds [root@mowgli disk-1]# pwd /media/disk-1 [root@mowgli disk-1]# cp -Rp ISDocs20060525/AppDevlTools/OracleODBC/Oracle\ Migration\ Kit\ User\'s\ Guide\ --\ Contents.htm /160bk/ISDocs20060525/AppDevlTools/OracleODBC/Oracle\ Migration\ Kit\ User\'s\ Guide\ --\ Contents.htm The tree command walks the "28872 directories, 341679 files" ok. lsusb Bus 005 Device 030: ID 067b:2507 Prolific Technology, Inc. Bus 005 Device 001: ID 0000:0000 ... Bus 001 Device 001: ID 0000:0000 Version-Release number of selected component (if applicable): Linux version 2.6.20-2925.11.fc7xen (kojibuilder.redhat.com) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Mon Jun 11 16:21:08 EDT 2007 How reproducible: It appears to be reproducible. The failure occurs at the same point in the directory. Steps to Reproduce: Details are in the post above. Actual results: A complete -Rp copy fails of the USB drive. Expected results: cd /media/disk-1 cp -Rp . /160_bk should copy the entire 160gig disk to an internal IDE drive. Additional info: dosfsck -nv /dev/sde1 dosfsck 2.11 (12 Mar 2005) dosfsck 2.11, 12 Mar 2005, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "mkdosfs" Media byte 0xf8 (hard disk) 512 bytes per logical sector 16384 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 39053312 bytes per FAT (= 76276 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 78123008 (sector 152584) 9763251 data clusters (159961104384 bytes) 63 sectors/track, 255 heads 0 hidden sectors 312576642 sectors total Checking for unused clusters. Checking free cluster summary. /dev/sde1: 374313 files, 8188069/9763251 clusters I will try Bug 242359 as the screen saver kicks in during the copy.
I blindly followed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359#c16 and added '"usbcore.autosuspend=0" (without the quotes) to the kernel command line in grub.conf' However, a more of /proc/cmdline shows more /proc/cmdline ro root=/dev/VolGroup00/LogVol00 rhgb quiet and Grub has more /etc/grub.conf # grub.conf generated by anaconda # ... default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.22.1-27.fc7) root (hd0,0) kernel /vmlinuz-2.6.22.1-27.fc7 ro root=/dev/VolGroup00/LogVol00 rhgb qu iet usbcore.autosuspend=0 initrd /initrd-2.6.22.1-27.fc7.img title Fedora (2.6.20-2925.11.fc7xen) root (hd0,0) kernel /xen.gz-2.6.20-2925.11.fc7 usbcore.autosuspend=0 module /vmlinuz-2.6.20-2925.11.fc7xen ro root=/dev/VolGroup00/LogVol00 r hgb quiet The copy still failed. Notice that the Xen kernel is not at 2.6.22 version and yum reports No Packages marked for Update/Obsoletion [root@mowgli ~]# date Sat Jul 21 16:18:34 MST 2007 Hence, I reassigned to Xen kernel thinking it is related to the other usb bug. I will look up grub configuration and try again.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.