I just wanted to burn a CD from a .iso

Aldo Foot lunixer at gmail.com
Sat Jan 19 02:52:39 UTC 2008


On Jan 18, 2008 5:50 PM, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> 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
>
> --
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080118/8b134e52/attachment-0001.htm>


More information about the fedora-list mailing list