[Debburn-devel] LG CH08LS10 not burning CDs

surfed god at youhavechoice.com
Sat Jan 30 20:11:47 UTC 2010


Ok, i restested everything as it was 2am last night when i did and made some
oversights...

RIP, cant get cdrecord to work, it will not accept my dev=/dev/sr0 or
dev=scsi:1,0,0 but i did get dmesg errors when inserting disk

so i booted into Mint Linux on USB stick (my main distro is Arch Linux) and
got same results, then rebooted with ACPI changed to ATA. Disk access was
very slow, took forever to open up apps BUT burning worked altough at low
speeds 1x - 3x for DVD.
Now I am confused.... Why did it work for a few burns under ARCH before
failing again? If it is another process accessing the drive how do i figure
out wich?
Thank you for your help
Sascha

On Sat, Jan 30, 2010 at 5:13 AM, Thomas Schmitt <scdbackup at gmx.net> wrote:

> Hi,
>
> Age Jan Kuperus wrote:
> > I looked for processes that tried to access sr0 and
> > found several
> > children of udevd (they seem to be run in sequence):
> > /lib/udev/devkit-disks-part-id /dev/sr0
> > /sbin/blkid -o udev -p -u noraid /dev/sr0
> > /lib/udev/cdrom_id --export /dev/sr0
>
> I don't know about devkit-disks-part-id and
> cdrom_id but libblkid is a known reader of block
> devices.
> Nevertheless, this should not constantly try to
> read from the drive. At most for a short while
> after a media was inserted.
>
> So if it can slow down a complete DVD run, then
> this is not the normal behavior.
> One should try to get advise from the distro
> community.
>
> (Ted T'so, Eduard Bloch and me once tried to get
>  libblkid, wodim and libburn into better
>  co-existence. This ended with the result that
>  none of the available locking mechanisms was
>  sufficient in all cases.)
>
>
> > Hope this helps (and somebdy can fix it).
>
> The offending processes should at least restrict
> themselves to a short examination. In that case
> the user can load the tray manually, wait a while
> and only then start the burn run.
>
> The responsible programmers would be those who
> set up the udev stuff in the distro. Maybe they
> have to forward the problem upstream then.
>
> (Again, i would participate in a technical
>  discussion.)
>
>
> Have a nice day :)
>
> Thomas
>
>
> _______________________________________________
> Debburn-devel mailing list
> Debburn-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debburn-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debburn-devel/attachments/20100130/fc298a2e/attachment.htm>


More information about the Debburn-devel mailing list