On Wed, 26 Dec 2007, Robert Moskowitz wrote: > Scott Ehrlich wrote: >> On Tue, 25 Dec 2007, Robert Moskowitz wrote: >> >>> Scott Ehrlich wrote: >>>> On Tue, 25 Dec 2007, Robert Moskowitz wrote: >>>> >>>>> Scott Ehrlich wrote: >>>>>> On Tue, 25 Dec 2007, Robert Moskowitz wrote: >>>>>> >>>>>>> Frank Cox wrote: >>>>>>>> On Tue, 25 Dec 2007 17:37:32 -0500 >>>>>>>> Robert Moskowitz <rgm at htt-consult.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Sense Key: 0x2 Not Ready, Segment 0 >>>>>>>>> >>>>>>>> >>>>>>>> Get some canned air and blow the dirt off of the sensor in the drive. >>>>>>> No change. >>>>>>> >>>>>>> The drive is the coffee mug tray style. so even opening the plastic >>>>>>> housing for the drive does not let me 'see' the sensor, but I used a >>>>>>> lot of canned air and no change in behaviour.... >>>>>>> >>>>>>> Perhaps I have to go out to the drug store and buy one of those drive >>>>>>> lens cleaner disks? >>>>>>> >>>>>> >>>>>> Have you tried removing/reseating the data cable on both ends? >>>>> USB. I thought I mentioned that.... >>>>> >>>>>> I've seen this work a handful of times. Also, SCSI or other? If SCSI, >>>>>> is it properly terminated, and with the correct ID? I once replaced a >>>>>> SCSI hard drive, and due to some technical change that completely >>>>>> baffled me, using the same cable, and ensuring IDs were all correct >>>>>> (unchanged), could not get the system to properly boot? In the end, a >>>>>> colleague with similar knowledge ended up relocating the SCSI >>>>>> terminator on the cable itself. No reason why it needed to be >>>>>> relocated, but that solved the problem. >>>>> Yeah if those SCSI terminators get a little dirty ;) >>>>>> Try cabling and see what happens... >>>>> >>>>> Using 2.0 cables. Of course the server is an old Compaq SFF that only >>>>> supports USB 1.1 >>>> >>>> What do the logs say about any possible USB errors? How about tail -f >>>> path_to_log_file and unplugged/replugging to see what the active messages >>>> are? >>>> >>> Dec 25 20:46:02 onlo kernel: usb 1-2: reset full speed USB device using >>> uhci_hcd and address 2 >>> Dec 25 20:46:02 onlo kernel: usb 1-2: reset full speed USB device using >>> uhci_hcd and address 2 >>> Dec 25 20:46:03 onlo kernel: sr 0:0:0:0: scsi: Device offlined - not ready >>> after error recovery >>> Dec 25 20:46:03 onlo kernel: sr 0:0:0:0: rejecting I/O to offline device >>> Dec 25 21:53:01 onlo kernel: sr 0:0:0:0: rejecting I/O to offline device >>> >>> I terminated k3b at this point and unplugged and plugged in the usb cable >>> to the drive: >>> >>> Dec 25 21:54:07 onlo kernel: usb 1-2: USB disconnect, address 2 >>> Dec 25 21:54:28 onlo kernel: usb 1-2: new full speed USB device using >>> uhci_hcd and address 3 >>> Dec 25 21:54:28 onlo kernel: usb 1-2: configuration #1 chosen from 1 >>> choice >>> Dec 25 21:54:32 onlo kernel: scsi1 : SCSI emulation for USB Mass Storage >>> devices >>> Dec 25 21:54:37 onlo kernel: Vendor: HP Model: CD-Writer+ 8200f Rev: 1.0A >>> Dec 25 21:54:37 onlo kernel: Type: CD-ROM ANSI SCSI revision: 00 >>> Dec 25 21:54:37 onlo kernel: sr0: scsi3-mmc drive: 32x/32x writer cd/rw >>> xa/form2 cdda tray >>> Dec 25 21:54:37 onlo kernel: sr 1:0:0:0: Attached scsi generic sg0 type 5 >> >> k3b uses cdrecord among other utilities - it is simply a graphical >> front-end. >> >> Have you tried the command-line tools instead? >> >> I have a simple script that collects files, creates an ISO, then burns the >> ISO to disk. No GUI (k3b) involved. >> >> mkisofs -o /home/scott/files.iso -R -J -T files/ >> cdrecord -v dev=/dev/cdrom -multi /home/scott/files.iso >> eject > Why the -multi option? To permit multisession and not close the disc. If you want to close it (write once, that's it), then remove the -multi. Scott > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >