I'm knee deep in bugs/problems.
I just wanted to burn a .iso file to a CD. (Why is another sad
story.) On my desktop F7 x86_64 system.
I tried k3b, my normal tool. Tools: Burn CD Image. When I clicked
"Start", it hung, not even updating the window damage.
Why? ps shows that it was hung awaiting a process doing lsof on /dev/sr0.
strace showed that the lsof was doing a stat on an NFS mount point. I
have not idea why that would hang (but I could repeat it). I have no
ideas why lsof cared about the mount point. Two more mysteries.
I decided to burn the .iso using a script that I'd written a while
back. A wrapper for cdrecord. That failed too. It put out an
endlessly repeating stream of warnings (with no newlines):
Unable to open this SCSI ID. Trying to map to old ATA syntax.This
workaround will disappear in the near future. Fix your
configuration.Unable to open this SCSI ID. Trying to map to old ATA
syntax.This workaround will disappear in the near future. Fix your
configuration.
This script used to work on this machine. I don't know when it
stopped. The actual cdrecord command was:
cdrecord -v dev=2,0,0 speed=8 -dao driveropts=burnfree --padsize=128k InitialHDD.iso
The messages from that command, up until the repeated messages, were:
TOC Type: 1 = CD-ROM
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
WARNING: the deprecated pseudo SCSI syntax found as device
specification.
Support for that may cease in the future versions of wodim. For now,
the device will be mapped to a block device file where possible.
Run "wodim --devices" for details.
Another mystery: what is wodim? That one is easy: wodim is a fork of
cdrecord. So I was actually using wodim.
OK, what does "wodim --devices" say?
Segmentation fault
Another mystery. I wonder what the segfault is about. gdb says that
it is in strlen. But the stack dump isn't very useful without the
debug info:
#0 0x0000003602c77180 in strlen () from /lib64/libc.so.6
#1 0x0000003602c460bb in vfprintf () from /lib64/libc.so.6
#2 0x0000003602ce4228 in __vsnprintf_chk () from /lib64/libc.so.6
#3 0x0000003602ce416b in __snprintf_chk () from /lib64/libc.so.6
#4 0x0000000000437680 in list_devices ()
#5 0x000000000040cef4 in main ()
So: let's load the debuginfo package. Even though wodim's rpm is in
updates, the -debuginfo package is missing. Another mystery.
There is another cdrecord command that can find drives:
# wodim -scanbus
scsibus2:
2,0,0 200) 'HP ' 'DVD Writer 740b ' 'HI24' Removable CD-ROM
2,1,0 201) 'TSSTcorp' 'DVD-ROM TS-H352C' 'HP01' Removable CD-ROM
2,2,0 202) *
2,3,0 203) *
2,4,0 204) *
2,5,0 205) *
2,6,0 206) *
2,7,0 207) *
This seems to suggest that dev=2,0,0 should be correct, but we already
know it is not. Another mystery.
The cdrecord command worked when I used dev=/dev/scd0.
The script had another failure. It ended with "eject /dev/cdwriter".
There is no /dev/cdwriter on my machine. I'm sure that I've had that
pathname on my machines for years. I wonder why it went away.
Another mystery.
I decided, like a good citizen, to report the wodim problems. It
turns out that the bugzilla doesn't think that F7 has a "wodim"
component, even though that is the name of the .rpm that it came in.
Apparently cdrkit is the appropriate component name. Another
surprise.c
https://bugzilla.redhat.com/show_bug.cgi?id=429385
https://bugzilla.redhat.com/show_bug.cgi?id=429386
