I just wanted to burn a CD from a .iso

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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
    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
	    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



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux