From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
I upgraded to fc3 and cannot record CDs any more. All CD utilities
hang under fc3, including cdrecord, and all work fine under fc2.
I have a CW058D ATAPI CD-R/RW drive.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install fedora core 3
2. insert Cd and try to write to it
Actual Results: all CD utilities hang
Expected Results: should be able to record CDs
please try an update kernel
I did. I updated it to the latest possible (2.6.10 I believe) using
Red Hat Network.
Updating to the latest kernel version does not fix the problem.
then we have a problem Houston...
Found a few interesting things. Mainly, when it hangs, if I press the
button on the CD drawer it continues and burns the CD normally. Here
are the versions.
FC3, 2.6.9: works if I press button drawer
FC3, after upgrade to 2.6.10: doesn't work at all
Fedora Core 3 on AMD64 Opteron system.
Gets worse here. Try to record a CD-R using
cdrecord -v -tao -eject -dev=4,0,0 speed=4 driveropts=burnfree isoname...
Result: system freeze.
Kernel ist 2.6.10-1.760_FC3 and cdrecord is 2.01.1-5
And one thing is identical for me, too. One the last 2.6.9 kernel it
you may try a kernel <= 2.6.7 . If it works there, this should be
assigned to component kernel.
Mine gave out altogether. I got an external USB burner working ok, an
HP CD-writer. Bought brand new SONY DVD recorder, external USB and
firewire, 'cause I don't have DVD burner anyway, will try later.
Having problems with memory stick under 2.6.10-1.760_FC3, went back to
2.6.9: Got system freeze at startup with new SONY DRX-710UL, external
DVD Dual Layer. 2.6.10 booted; hardware browser sees it but that's it;
Best work-around: use my external HP CD-writer with 2.6.9
I have a freeze up in a similar manner on an Opteron (x86_64) under
kernel 2.6.10-1.760_FC3. The output follows:
[root@shuttle ~]# cdrecord --scanbus
Cdrecord-Clone 2.01-dvd (--) Copyright (C) 1995-2004 JÃ¶rg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
Note: The author of cdrecord should not be bothered with problems in
scsibus: -2 target: -2 lun: -2
And there it hangs. There are two drives in the system:
hdc: CD-ROM Drive/F5D, ATAPI CD/DVD-ROM drive
hdd: CW078D ATAPI CD-R/RW, ATAPI CD/DVD-ROM drive
dmesg says the second drive is confused:
ide-cd: cmd 0x1e timed out
hdd: lost interrupt
hdd: cdrom_pc_intr: The drive appears confused (ireason = 0x03)
wow, haven't seen the last message :) confused..
Had the same problem on a NEC TXI notebook. After many hours, reboots, and a
spindle of CDROMs, I discovered a fix:
Prior kernel installations required a kernel option in GRUB "hdc=ide-scsi".
Cdrecord began crashing with Fedora Core (2.6.10-1.741_FC3). Kernel option had
been automatically set during the upgrade to "ro root=LABEL=/ hdc=ide-scsi rhgb
acpi=on hdc=ide-scsi" /dev/sdc0 appeared in place of /dev/hdc.
Same for Fedora Core (2.6.11-1.14_FC3), which also mounted the CD 8 times, when
Removing both instances of "hdc=ide-scsi" seems to have fixed the crashing. The
/dev/hdc device magically appeared. All that remained to get the drive to
record was to enable "Execute" permissions for the device.
Reading the System Logs side by side gave a hint that the ide-scsi system had
changed and the kernel option was no longer needed. I suspect this only happens
when a new kernel is installed on an existing system.
A case of dogged persistance overcoming a lack of knowledge.
Jim - a Linux Newbee
(In reply to comment #13)
Just installed 2.6.12. Same set of prpblems. Nothing working; plus my grub.conf
looks totally different from Jim's (yours).
I'm thinking it may be unusual hardware. It's a COMPAQ that was only sold in
Britain under a special set of model names.
> Had the same problem on a NEC TXI notebook. After many hours, reboots, and a
> spindle of CDROMs, I discovered a fix:
> Prior kernel installations required a kernel option in GRUB "hdc=ide-scsi".
> Cdrecord began crashing with Fedora Core (2.6.10-1.741_FC3). Kernel option had
> been automatically set during the upgrade to "ro root=LABEL=/ hdc=ide-scsi rhgb
> acpi=on hdc=ide-scsi" /dev/sdc0 appeared in place of /dev/hdc.
> Same for Fedora Core (2.6.11-1.14_FC3), which also mounted the CD 8 times, when
> Removing both instances of "hdc=ide-scsi" seems to have fixed the crashing. The
> /dev/hdc device magically appeared. All that remained to get the drive to
> record was to enable "Execute" permissions for the device.
> Reading the System Logs side by side gave a hint that the ide-scsi system had
> changed and the kernel option was no longer needed. I suspect this only happens
> when a new kernel is installed on an existing system.
> A case of dogged persistance overcoming a lack of knowledge.
> Jim - a Linux Newbee
I can confirm that the fix given in comment #13 fixed my problems as well. My CD
burner originally appeared under '0,0,0' in the output of 'cdrecord -scanbus',
and I had a device called /dev/scd0 and no /dev/hdd. Removing the kernel option
'hdd=ide-scsi' caused the device to now appeared as /dev/hdd, and the drive then
appeared as '1,1,0' in the bus scan. No burning in the former, and a normal burn
in the latter.
If ide-scsi is no longer used, could we configure the kernel package not to set
that option in grub.conf, or put something in the release notes about that?
I think there is s.th. in the Release Notes about that.
After a little research, I see that there was a small section about it in the
release notes for FC2, but it has not appeared in subsequent ones. As I upgraded
directly from FC1 to FC3, I missed it. Apologies for that.
However, I am still curious about the feasiblity of my first suggestion. If
ide-scsi is depreciated (or really, not working), why is the kernel package
still setting that option in my grub.conf? I know that it was there before when
I was still running a 2.4 kernel, which is where it likely originally came from,
but how difficult would it be to filter the list of kernel options and remove
the depreciated ones? Is it worth filing a bug under the kernel?
It just a dumb copy and paste of the old options line. Yes, it would be possible
to filter the deprecated lines, and a bug report is maybe worth it.