cd blanking/recording

[Cyber Source]

There used to be a permission problem on the 2.6.9 kernels that you had 
to be root with k3b IF you had an actual SCSI drive on your system, I 
think it also had a problem with LVM, but that problem was solved in the 
2.6.10's, hopefully it's not back again.
Just for shits and giggles, since I'm running FC3 too, I checked my 
perms on /usr/bin/cdrecord and they are "-rwxr-xr-x  1 root root  
/usr/bin/cdrecord" and I burn just fine with k3b or nautilus. I haven't 
done the chmod u+s thing in a while, not needed anymore, depending on 
your /etc/fstab. I am running my system on SCSI hard drives and LVM but 
my burner is an IDE, here is the perms on that "brw-------  1 peter disk 
22 /dev/hdc".
Here is an excerpt of my fstab with my burner
"/dev/hdc                /media/cdrecorder       auto    
pamconsole,exec,noauto,managed 0 0"
Check those settings on your box, especially the fstab line.


advent systems wrote:

> Hi guys,
>    I'm trying to erase and record cd-rw's.  Using k3b when trying to 
> erase I get the error message "cdrecord did not exit cleanly, blanking 
> error".  when using nautilus, I get this message:
> "cdrecord: Cannot allocate memory. Cannot get SCSI I/O buffer.
> SCSI buffer size: 64512
> cdrecord: Warning: using inofficial libscg transport code version 
> (schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c    1.83 
> 04/05/20 Copyright 1997 J. Schilling').
> Linux sg driver version: 3.5.27
> scsibus: -2 target: -2 lun: -2
> devname: '/dev/hdc'
> scsidev: '/dev/hdc'
> cdrecord: Continuing in 5 seconds...
> cdrecord: Future versions of cdrecord may have different drive 
> dependent defaults.
> cdrecord: Asuming -tao mode.
> cdrecord: No write mode specified."
>
> I have chmod u+s /usr/bin/cdrecord and cdrdao.    When I start k3b 
> from a terminal as root it works fine which tells me it's a permission 
> problem but I still can't figure it out.  I'm running FC3 
> w/2.6.11-1.27 kernel.  It's doing the same thing on 3 different 
> boxes.  It worked before which leads me to believe also that updating 
> might have something to do with it.
>    Any ideas welcome.
>
> Bob Randal
>