Frank Cox wrote:
On Tue, 25 Dec 2007 17:37:32 -0500 Robert Moskowitz rgm@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?
On Tue, 25 Dec 2007, Robert Moskowitz wrote:
Frank Cox wrote:
On Tue, 25 Dec 2007 17:37:32 -0500 Robert Moskowitz rgm@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? 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.
Try cabling and see what happens...
Scott
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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@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
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@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?
Scott
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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@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
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@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
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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
What happens if you try the above? Will it be k3b? The commands it uses? The hardware?
What happens if you simply insert a writable CD, open it in the window manager, drag a file to the disk, and try to burn that file to disk?
Create your own ISO from the above then try to have the window manager burn it directly to disk.
Let us know.
Scott
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@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
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
I already have LOTS of isos to try and burn. From little 40Mb D~mnSmallLinux to any of the 6 Centos isos...
mkisofs -o /home/scott/files.iso -R -J -T files/ cdrecord -v dev=/dev/cdrom -multi /home/scott/files.iso eject
After I figure out the right device (should be in those /varlog/messages above!), I will try this.
What happens if you try the above? Will it be k3b? The commands it uses? The hardware?
Stay tune.
What happens if you simply insert a writable CD, open it in the window manager, drag a file to the disk, and try to burn that file to disk?
That is what started this. Whether an iso or a file I am told that I need a disk large enough for the files. Not what I put in.
Create your own ISO from the above then try to have the window manager burn it directly to disk.
Doesn't work.
Let us know.
Read the start of this thread.
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@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?
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip> 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
<snip sig stuff>
Stat of this thread is now gone, so if you've done this...
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
Try just reading a cd first. Does the device have any king od "write protect" switch?
Use cdrecord with some verbosity flags to get some clues. Are you insertinb them with the correct face up? Don't laugh - with no names w/o labels, ...
Use cdrecord to print some of the header info of the blank disc you're trying to write. You'll need to RTFM - I don't have it in front of me ATM.
Do you have another node that you can test a write on to see if the disc is really OK? Hopefully that would be an RW disc.
Have you tried reorienting the device (horiz <-> vertical) to see if that has an effect?
It sound like you'll need to leave the comfy confines of the GUI room to solve this one.
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip> 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
<snip sig stuff>
Stat of this thread is now gone, so if you've done this...
hmmm
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
And no such animal as a modules.conf anywhere on the system (per locate modules.conf)
Try just reading a cd first. Does the device have any king od "write protect" switch?
Will try the reading. No write protect switch. This CDRW was on a Win2000 system whose board started overheating and crashing. So it was working with Veritas just 2 weeks ago.
Use cdrecord with some verbosity flags to get some clues.
And I need clues to help me RTFM. Lot there ASSuMEing already knowing about SCSI and CD devices...
Are you insertinb them with the correct face up? Don't laugh - with no names w/o labels, ...
Well, I could believe the no label problem, but I have stacks of these Memorex CDR disks and it is off the spindle onto the try as I have been doing for a few years on the Win2000 system. And I just used some on my corporate HP notebook's DVD/CDRW drive with XP (but no iso software, and the system is too locked down to add anything they don't send you).
Use cdrecord to print some of the header info of the blank disc you're trying to write. You'll need to RTFM - I don't have it in front of me ATM.
I case of tBltD?
Do you have another node that you can test a write on to see if the disc is really OK? Hopefully that would be an RW disc.
See above.
Have you tried reorienting the device (horiz <-> vertical) to see if that has an effect?
No. There is just room to put it horiz above the systems that are on a shelf in a 19" rack....
It sound like you'll need to leave the comfy confines of the GUI room to solve this one.
Would if I could get more out of RTFM.
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
And no such animal as a modules.conf anywhere on the system (per locate modules.conf)
modprobe*
Try just reading a cd first. Does the device have any king od "write protect" switch?
Will try the reading. No write protect switch. This CDRW was on a Win2000 system whose board started overheating and crashing. So it was working with Veritas just 2 weeks ago.
Use cdrecord with some verbosity flags to get some clues.
And I need clues to help me RTFM. Lot there ASSuMEing already knowing about SCSI and CD devices...
OK. CentOS 4.x or 5.x? I'll try to help if I can. Only diff would be the device reported. I don't have usb. But with cdrecord, only the low-level drivers would change. All the sg* interface stuff would be the same.
<snip>
Use cdrecord to print some of the header info of the blank disc you're trying to write. You'll need to RTFM - I don't have it in front of me ATM.
<snip>
It sound like you'll need to leave the comfy confines of the GUI room to solve this one.
Would if I could get more out of RTFM.
I'll try to help.
<snip sig stuff>
William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
And no such animal as a modules.conf anywhere on the system (per locate modules.conf)
modprobe*
cat /etc/modprobe.conf
alias eth0 e100 alias ipv6 off alias net-pf-10 off
Try just reading a cd first. Does the device have any king od "write protect" switch?
Will try the reading. No write protect switch. This CDRW was on a Win2000 system whose board started overheating and crashing. So it was working with Veritas just 2 weeks ago.
Use cdrecord with some verbosity flags to get some clues.
And I need clues to help me RTFM. Lot there ASSuMEing already knowing about SCSI and CD devices...
OK. CentOS 4.x or 5.x? I'll try to help if I can. Only diff would be the device reported. I don't have usb. But with cdrecord, only the low-level drivers would change. All the sg* interface stuff would be the same.
5.1
Use cdrecord to print some of the header info of the blank disc you're trying to write. You'll need to RTFM - I don't have it in front of me ATM.
<snip>
It sound like you'll need to leave the comfy confines of the GUI room to solve this one.
Would if I could get more out of RTFM.
I'll try to help.
I appreciate any and all help.
On Wed, 2007-12-26 at 09:19 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
I didn't notice this before. the entries on the right specify who uses that module. Are they compiled in on your system? Custom kernel? I'd have thought those would show up in lsmod too.
My 5.1 has scsi_mod, sg, sd_mnod, libata and some chipset-specific modules.
It also has, in modprobe.conf alias scsi_hostadapter sata_via. The last is chipset-specific. I don't know if this line is needed at all on your system.
<snip>
HTH
William L. Maltby wrote:
On Wed, 2007-12-26 at 09:19 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
I didn't notice this before. the entries on the right specify who uses that module. Are they compiled in on your system? Custom kernel? I'd have thought those would show up in lsmod too.
Everything on this system came from the Centos 5/5.1 repos (5.1 are local mirrors).
My 5.1 has scsi_mod, sg, sd_mnod, libata and some chipset-specific modules.
It also has, in modprobe.conf alias scsi_hostadapter sata_via. The last is chipset-specific. I don't know if this line is needed at all on your system.
Well how do I find out?
<snip>
HTH
On Wed, 2007-12-26 at 10:03 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 09:19 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
I didn't notice this before. the entries on the right specify who uses that module. Are they compiled in on your system? Custom kernel? I'd have thought those would show up in lsmod too.
Everything on this system came from the Centos 5/5.1 repos (5.1 are local mirrors).
My 5.1 has scsi_mod, sg, sd_mnod, libata and some chipset-specific modules.
It also has, in modprobe.conf alias scsi_hostadapter sata_via. The last is chipset-specific. I don't know if this line is needed at all on your system.
Well how do I find out?
Geez Louise! I haven't worked on this stuff professionally since 12/01. And Over the decades I developed an excellent short-term memory.
... thinking ...
In the past I always made everything loadable modules because the target hardware was constantly changing. So I always had something like this in the modules.conf (at that time).
I really can't tell you how to find out. But in
/lib/modules/<your kernel>
there's a bunch of module* files. Man modules.dep and depmod is at least a starting point.
Now, you mention a local repo. Does your /lib/modules have an entry for the latest kernel? If not, maybe you just need a "depmod -a" run? If the dates aren't already matching when you transitioned to 5.1, same?
My sata_via appears in modules.{alias|pcimap|dep} and shows a dependency on it by sg_mod (a necessary module AFAIK). Since yours is usb based, I would expect that a similar line ending with something that says either usb* or *_<your chipset here (replace * with real values) would be needed.
<snip>
On Wed, 2007-12-26 at 10:03 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
I didn't notice this before. the entries on the right specify who uses that module. Are they compiled in on your system? Custom kernel? I'd have thought those would show up in lsmod too.
Everything on this system came from the Centos 5/5.1 repos (5.1 are local mirrors).
My 5.1 has scsi_mod, sg, sd_mnod, libata and some chipset-specific modules.
I'm almost certain that scsi_mod, sg and sd_mod are needed for all these scsi operations. The libata is needed by my sata_via driver, so may not be needed on your setup.
It also has, in modprobe.conf alias scsi_hostadapter sata_via. The last is chipset-specific. I don't know if this line is needed at all on your system.
Well how do I find out?
BTW. Try doing insmod on modules you suspect are needed. Then if one of them satisfies a dependency, or depends on another module that is loaded, the lsmod will show that.
Once you have the modules.dep correct (depmod -a?) and have identified the chipset module needed (*if* any and it's not already loaded), you can try adding the "alias scsi_hostadapter ..." line specifying that chipset module. Then whenever the system tries to use something that requires scsi_hostadapter, the driver for that chipset will be automatically loaded.
<snip>
On Wed, 2007-12-26 at 11:11 -0500, William L. Maltby wrote:
<snip>
Almost forgot. IIRC, usb devices are always scsi. My usb flash drives all appear as scsi. So we can be certain that you need a scsi stack of loadable modules similar to the ones on my system that I showed earlier.
On my 4.x, the only machine I have the flash drives in ATM), I see
sd_mod 17345 4 usb_storage 60937 2 scsi_mod 125901 2 sd_mod,usb_storage uhci_hcd 31705 0 ehci_hcd 31429 0
out of lsmod. I'm pretty sure you'll need those. But my usb is 2.0, so I'm not sure about the to *_hcd modules. I think those were common among the 1.x -> 2.x versions of usb.
On Wed, 26 Dec 2007, William L. Maltby wrote:
On Wed, 2007-12-26 at 11:11 -0500, William L. Maltby wrote:
<snip>
Almost forgot. IIRC, usb devices are always scsi. My usb flash drives all appear as scsi. So we can be certain that you need a scsi stack of loadable modules similar to the ones on my system that I showed earlier.
On my 4.x, the only machine I have the flash drives in ATM), I see
sd_mod 17345 4 usb_storage 60937 2 scsi_mod 125901 2 sd_mod,usb_storage uhci_hcd 31705 0 ehci_hcd 31429 0
out of lsmod. I'm pretty sure you'll need those. But my usb is 2.0, so I'm not sure about the to *_hcd modules. I think those were common among the 1.x -> 2.x versions of usb.
A few items that may be obvious but I'll still ask/suggest:
- Turn off the CD drive, and unplug the USB cable from both drive and PC
- Gracefully shut down the PC, then physically power off (if necessary)
- Plug the USB cable back into both devices (CD and PC)
- Turn on the CD drive
- Turn on the PC
Keep an eye on all status messasges. If all looks good, try to read a disk. If that works, try to burn a disk. Use command-line utils to start.
Let us know.
Scott
-- Bill
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
They are all there. See below
William L. Maltby wrote:
On Wed, 2007-12-26 at 11:11 -0500, William L. Maltby wrote:
<snip>
Almost forgot. IIRC, usb devices are always scsi. My usb flash drives all appear as scsi. So we can be certain that you need a scsi stack of loadable modules similar to the ones on my system that I showed earlier.
On my 4.x, the only machine I have the flash drives in ATM), I see
sd_mod 17345 4 usb_storage 60937 2 scsi_mod 125901 2 sd_mod,usb_storage uhci_hcd 31705 0 ehci_hcd 31429 0out of lsmod. I'm pretty sure you'll need those. But my usb is 2.0, so I'm not sure about the to *_hcd modules. I think those were common among the 1.x -> 2.x versions of usb.
Module Size Used by autofs4 24517 2 sunrpc 144253 1 ip_conntrack_ftp 11697 0 ip_conntrack_netbios_ns 6977 0 ipt_REJECT 9537 1 xt_state 6209 15 ip_conntrack 53025 3 ip_conntrack_ftp,ip_conntrack_netbios_ns,xt_state nfnetlink 10713 1 ip_conntrack xt_tcpudp 7105 17 iptable_filter 7105 1 ip_tables 17029 1 iptable_filter x_tables 17349 4 ipt_REJECT,xt_state,xt_tcpudp,ip_tables dm_multipath 21577 0 video 19269 0 sbs 18533 0 backlight 10049 0 i2c_ec 9025 1 sbs button 10705 0 battery 13637 0 asus_acpi 19289 0 ac 9157 0 lp 15849 0 sr_mod 19941 0 sg 36061 0 floppy 57125 0 ata_piix 18629 0 libata 115961 1 ata_piix e100 36809 0 mii 9409 1 e100 pcspkr 7105 0 i2c_piix4 12237 0 i2c_core 23745 2 i2c_ec,i2c_piix4 serio_raw 10693 0 usb_storage 76577 0 scsi_mod 133069 4 sr_mod,sg,libata,usb_storage parport_pc 29157 1 parport 37513 2 lp,parport_pc ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd dm_snapshot 20709 0 dm_zero 6209 0 dm_mirror 28741 0 dm_mod 58201 7 dm_multipath,dm_snapshot,dm_zero,dm_mirror ext3 123337 2 jbd 56553 1 ext3 ehci_hcd 32973 0 ohci_hcd 23261 0 uhci_hcd 25421 0
On Wed, 2007-12-26 at 12:14 -0500, Robert Moskowitz wrote:
They are all there. See below
William L. Maltby wrote:
<snip>
Almost forgot. IIRC, usb devices are always scsi. My usb flash drives all appear as scsi. So we can be certain that you need a scsi stack of loadable modules similar to the ones on my system that I showed earlier.
On my 4.x, the only machine I have the flash drives in ATM), I see
sd_mod 17345 4 usb_storage 60937 2 scsi_mod 125901 2 sd_mod,usb_storage uhci_hcd 31705 0 ehci_hcd 31429 0out of lsmod. I'm pretty sure you'll need those. But my usb is 2.0, so I'm not sure about the to *_hcd modules. I think those were common among the 1.x -> 2.x versions of usb.
Module Size Used by autofs4 24517 2 sunrpc 144253 1 ip_conntrack_ftp 11697 0 ip_conntrack_netbios_ns 6977 0 ipt_REJECT 9537 1 xt_state 6209 15 ip_conntrack 53025 3 ip_conntrack_ftp,ip_conntrack_netbios_ns,xt_state nfnetlink 10713 1 ip_conntrack xt_tcpudp 7105 17 iptable_filter 7105 1 ip_tables 17029 1 iptable_filter x_tables 17349 4 ipt_REJECT,xt_state,xt_tcpudp,ip_tables dm_multipath 21577 0 video 19269 0 sbs 18533 0 backlight 10049 0 i2c_ec 9025 1 sbs button 10705 0 battery 13637 0 asus_acpi 19289 0 ac 9157 0 lp 15849 0 sr_mod 19941 0 sg 36061 0 floppy 57125 0 ata_piix 18629 0 libata 115961 1 ata_piix e100 36809 0 mii 9409 1 e100 pcspkr 7105 0 i2c_piix4 12237 0 i2c_core 23745 2 i2c_ec,i2c_piix4 serio_raw 10693 0 usb_storage 76577 0 scsi_mod 133069 4 sr_mod,sg,libata,usb_storage parport_pc 29157 1 parport 37513 2 lp,parport_pc ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd dm_snapshot 20709 0 dm_zero 6209 0 dm_mirror 28741 0 dm_mod 58201 7 dm_multipath,dm_snapshot,dm_zero,dm_mirror ext3 123337 2 jbd 56553 1 ext3 ehci_hcd 32973 0 ohci_hcd 23261 0 uhci_hcd 25421 0
<snip>
Then, I'm almost out of ideas.
It seems to come down to either the scsi_hostadapter entry (see
/usr/share/doc/kudzu-1.1.95.23/README
or something else. Maybe the power/(dis)connect/reboot sequence Scott suggested will work.
Also, "man kudzu" and then run it with everything hooked up? If all is weel with your system, I guess it would add the scsi_hostadapter entry? Of course, that appeared only on my 5.1 with the via chip set. It may be a result of this
/usr/share/doc/xcdroast-0.98a15/README.atapi
since my unit is ATAPI.
Aha! Saw your "Trouble ... River City" reply to Scott. Your giving away our age! ;-=)
Timing's good though. I must now break off and do some things I've procrastinated about for over two weeks.
Please post results. I'll be interested to hear.
On Wed, 2007-12-26 at 13:16 -0500, William L. Maltby wrote:
<snip>
Aha! Saw your "Trouble ... River City" reply to Scott. Your giving away
s/Your/you're/
I *hate* when I do that!
our age! ;-=)
<snip>
William L. Maltby wrote:
On Wed, 2007-12-26 at 13:16 -0500, William L. Maltby wrote:
<snip>
Aha! Saw your "Trouble ... River City" reply to Scott. Your giving away
s/Your/you're/
I *hate* when I do that!
The fact that you know the difference also says something about your age; the fact that I had already noticed it, something about mine.
There. I have went and give away myself. :-(
our age! ;-=)
<snip>
--- Robert kerplop@sbcglobal.net wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 13:16 -0500, William L.
Maltby wrote:
<snip>
Aha! Saw your "Trouble ... River City" reply to
Scott. Your giving away
s/Your/you're/
I *hate* when I do that!
The fact that you know the difference also says something about your age; the fact that I had already noticed it, something about mine.
There. I have went and give away myself. :-(
our age! ;-=)
<snip>
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This might sound a lot crazy, but it is worth a try. Try removing the module cd_rom and inserting that module again. Do a lsmod to see if the order has change and try using the usb cd_rom to burn a cd rom and let us know if this works.
regards
steven
Steven Vishoot wrote:
--- Robert kerplop@sbcglobal.net wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 13:16 -0500, William L.
Maltby wrote:
<snip>
Aha! Saw your "Trouble ... River City" reply to
Scott. Your giving away
s/Your/you're/
I *hate* when I do that!
The fact that you know the difference also says something about your age; the fact that I had already noticed it, something about mine.
There. I have went and give away myself. :-(
our age! ;-=)
<snip>
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This might sound a lot crazy, but it is worth a try. Try removing the module cd_rom and inserting that module again. Do a lsmod to see if the order has change and try using the usb cd_rom to burn a cd rom and let us know if this works.
How do I do this? How do I remove a module then readd it?
On Thu, 2007-12-27 at 07:49 -0500, Robert Moskowitz wrote:
Steven Vishoot wrote:
<snip>
This might sound a lot crazy, but it is worth a try. Try removing the module cd_rom and inserting that module again. Do a lsmod to see if the order has change and try using the usb cd_rom to burn a cd rom and let us know if this works.
How do I do this? How do I remove a module then readd it?
Rmmod and insmod. Do "man" on those, it's easy.
<snip>
On Wed, 2007-12-26 at 09:45 -0500, William L. Maltby wrote:
On Wed, 2007-12-26 at 09:19 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
My 5.1 has scsi_mod, sg, sd_mnod, libata and some chipset-specific
s/mnod/mod/
modules.
<snip>
On Wed, 2007-12-26 at 08:43 -0500, William L. Maltby wrote:
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
<snip>
First, do mount and make sure that the media has not been mounted. If so, unmount it. That *might* be the root cause.
Do you have an /etc/cdrecord.conf? Might have some things like
CDR_DEVICE=2,0,0 cdrom= /dev/hdc -1 -1 burnfree
On 4.x, this last line seems to be the item used for specifying the device. This 4.x has only a CD-RW, not DVD. My 5.x show DVD capability too because I have a DVD burner on that one. An ls -l of /dev/d* should show some symbolic links of hd*. This on my 5.x.
cdrecord -dev=cdrom -prcap
Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'CDWRITER' Identifikation : 'IDE5224 ' Revision : '0012' Device seems to be: Generic mmc CD-RW.
Drive capabilities, per MMC-2 page 2A:
Does read CD-R media Does write CD-R media Does read CD-RW media Does write CD-RW media Does not read DVD-ROM media Does not read DVD-R media Does not write DVD-R media Does not read DVD-RAM media Does not write DVD-RAM media Does support test writing
Compare the cdrecord.conf against what this shows. It will not include devices like cdrom here. That is a symbolic link to /dev/hdc (in my case).
# cdrecord -scanbus
For me, ...
scsidev: 'ATA' devname: 'ATA' scsibus: -2 target: -2 lun: -2 ... scsibus1: 1,0,0 100) 'CDWRITER' 'IDE5224 ' '0012' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) *
Do you have an env variable (from bash prompt)
echo $CDR_DEVICE
I'll go over to my 5.X and re-write a 5.1 DVD now.
More after you reply.
HTH
On Wed, 2007-12-26 at 09:21 -0500, William L. Maltby wrote:
On Wed, 2007-12-26 at 08:43 -0500, William L. Maltby wrote:
<snip>
I'll go over to my 5.X and re-write a 5.1 DVD now.
Done using cdrecord. Worked like a champ.
cdrecord -v -dao <path to CentOS-5.1 iso image>
This indicates that the GUI stuff ought to work too since no -dev parameter was provided.
<snip>
On Wed, 2007-12-26 at 08:09 -0500, Robert Moskowitz wrote:
William L. Maltby wrote:
On Tue, 2007-12-25 at 21:59 -0500, Robert Moskowitz wrote:
<snip>
Do an lsmod and see if you see sg, maybe sd_mod, scsi_mod, ide_cd. Look at /etc/modules.conf (I think that's it - thngs changed in the last decade or so).
scsi_mod 133069 4 sr_mod,sg,libata,usb_storage ide_cd 40033 0 cdrom 36705 2 sr_mod,ide_cd
(also a plain-old cdrom installed via IDE (internal) on this server).
<snip>
From days past on LFS, when I was very active and less removed from the
professional activities, I can say with certainty that the sr_mod and ide_cd are for the plain old cd-rom on your IDE channel. They are not required for the usb stuff.
-
Robert -
Robert Moskowitz -
Scott Ehrlich -
Steven Vishoot -
William L. Maltby