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