DVD writer won't eject
 

My DVD writer won't eject. I had the same problem with a different drive on a different PC and wrecked about twenty disks trying to get them out with the paperclip method. This time I think it started after I was trying to write on a disk and the computer couldn't handle it and got stuck in a loop which it couldn't get out of.
I was on Ubuntu 11.10 but I have just switched to Debian 6.0.4 in the hope that it would fix it.

I've looked for relevant threads, but most of them are old and none have solved the problem.

This thread:
http://www.linuxquestions.org/questi...d-line-726616/

Made a suggestion in Message 34 (last but one) to type: ps aux |grep gvfsd-cdd

Which resulted in:
root 3928 0.0 0.0 3304 764 pts/1 S+ 18:35 0:00 grep gvfsd-cdd

Which I imagine is a process running and owning the device. It suggests that I should kill that proceess, I think I should type: kill 3928
but I'm a bit wary about trying that without a little advice!

This is the relevant entry in fstab:
/dev/scd0 /media/cdrom0 udf,iso9660 users,noauto 0 0

This was suggested somewhere:
/dev/hdc /mnt/cd iso9660,udf ro,user,noauto,noexec,unhid
But I've no idea whether that is safe to try.

It's an infuriating problem, particularly since it concerns such a simple function!

I don't see eject -i0 (that's a zero) in that thread, try that then eject, here's hoping...

This is what happens;

root@Asus:/home/chris# eject -i0
CD-Drive may be ejected with device button

The tray does not open.

It may be relevant to mention that a motor runs whenever I try to eject, but there is a clunk as though some lock is still in place. It's as though there need to be two actions and they aren't synchronised.

There's no mechanical problem because it ejects when the ribbon cable is disconnected.

Did you try the -i0 then a plain eject? I have seen that fail, but I've also seen it work. One other thing to try is (I'm not on linux atm so you'll have to dig for this) explicitly specifying a driver or interface named generic-mmc or generic-mmc-raw or something along those lines, ring changes on those options for whatever's doing your burning. iirc when I did that it didn't fix the immediate problem, I still had to reboot, but the problem stopped recurring.

jthill
I typed eject -i0 then pressed the eject button.

Sorry - I don't know what Linux atm is or how to install a driver.

Try (as root) "eject /dev/sr0" (that's a zero)

syg00 I have tried that without success.

Would it be worth trying the kill command or changing the line in fstab as mentioned in my original post?

No, your kill idea won't work - that process is just the grep command you entered.
Try "eject /dev/scd0" (sorry about that, I don't use Debian, and I wasn't reading obviously).

Try rebooting the computer & eject right when computer is starting before dvd is mounted.

atm is just "at the moment" :-)

The drivers I'm referring to are already installed, they're choices of how to talk to the hardware you have. Sometimes you have to give your tool a hint. What are you actually using to talk to the dvd burner? gvfs is a gnome thing, are you using brasero? I was using command-line tools, wodim via genisoimage, there's a driver= option for those times when the hardware's not playing nice. If you're using a gui burner I hope someone can help you find where to pick the access method.

This was suggested one of the threads I looked at but it doesn't work. Eject only works if I disconnect the ribbon cable before switching on. This suggests to me that it's not a hardware or firmware problem.

jthill
I know what a driver is, but I thought Linux organised them rather more slickly than other OSs I could mention so I haven't looked into them. I did see a tool in a menu once but it didn't list any drivers, so I suppose you have to download them from somewhere.

I usually use brasero, but when the problem started I also tried K3B because I know that it has more functionality when you need it. That didn't work either, but it does give a report - nothing useful in it unfortunately.

I've just used a paperclip to open the drive, put a disk in, pressed the button and it ejected successfully.

It's now not working again.

Are you unmounting the drive before trying to eject the disc?

I'm trying to get this thread around to finding some way way to do what you want to do so the problem you're having doesn't recur or at least you don't have to reboot to fix it. Please say what you were actually trying to do when your burner wedged this way, and how you went about it, so someone here can figure out an alternate route that will actually work. I've actually encountered the symptoms you're reporting, and solved them, but it was months ago for a one-off and I idiotically did not keep notes on what I did to fix it. So between you not saying what you want to do and me not remembering how I fixed this while doing what I wanted to do, the best I can offer is help trying to find your way out of this. Whatever the cause of the symptoms you're reporting, it's some very unusual combination of circumstances, and the thing to do now is to try to identify them. So far, the most concrete information you've given about those circumstances is "I think it started after I was trying to write on a disk" and that you usually use brasero but tried k3b after the problem already started "because I know that it has more functionality when you need it", but you don't say what you tried to do with it and don't post the results of what you tried. Surely you can see that you could hardly have made it more difficult to help you if you'd been trying.

When I run this command it doesn't show root it shows my user name

because you're running it as a user.

the output is the command you've entered. i.e. ps is telling you that you ran it, and piped it's result to grep which looked for "gvfsd-cdd" (whatever that is). the only result it found was you looking for "gvfsd-cdd".

Thank you rkelson

EDDY1 and rkelson: I think you may have missed the first command of the two in my original message. I think it is an attempt to find out what process if any is locking the drive.

This command

will tell you what processes are using the drive. Of course, you need to put the right device node there if it isn't /dev/sr0.

Anyhow, you didn't answer my previous question:

rkelsen No, I didn't know how to do that. I've now looked it up and I've got a few ideas for commands to try:

umount /dev/sr0 (you mentioned sr0)
umount /dev/scd0 (scd0 appears in fstab)
umount /media/cdrom0 (cdrom0 appears in fstab)

Apart from once, it has been working today, but I'll try next time it gets stuck. The software is obviously trying to eject as I can hear it, would the software try to eject a disk even though it knew it was mounted, that seems illogical?

I've given some thought to cause and effect - I think that if the disk has something wrong with it the software gets locked into a loop which it can't get out of. Even after I have rebooted and removed the disk manually it will still be a problem. It seems to resolve itself spontaneously.

I will also go through my DVD-RWs and format them and chuck out any dodgy ones, which should lessen the problem in future, but may prompt the problem to happen now.

You can't eject a disc which is still mounted.

Modern GUI interfaces will do both steps (i.e. umount and eject) with one click (eg: KDE's device notifier widget), but the drive will ignore it's eject button while a disc is mounted.
Part of your problem is that you don't know what device you're using. You need to figure that out. There are a gazillion ways of doing this.

The first 3 that come to mind:
Look at the output of dmesg
Look under /dev/
Look under /sys/block

I'd ignore anything in fstab, since that file is ignored for removable media. It could contain anything really.

It's just got stuck again trying to eject an empty tray using K3B, so I tried unmounting it using the following commands:

I then used a paperclip to open the tray, then loaded a DVD-RW (that I had previously formatted successfully) and tried to write a file onto it with K3B. It errorred with this debugging output:

I then ejected the disk with K3B without problem!
As a further test I:
- removed the disk.
- closed the empty tray with K3B - success.
- ejected the empty tray with K3b - stuck again!

umount won't eject the disc. You need to use umount, then eject.

That output makes me think you might have a permissions problem.

Is your user in the cdrom group? Find out by running this command:

Also, please post the output of this command:

And this one too:

I realised that (too late of course!), but it possibly still proved that the problem was not caused by the disk being mounted. I have just done the unmount and eject commands with all three objects I mentioned above - it sticks.

I then tried:
chris@Asus:~$ groups
chris cdrom floppy audio dip video plugdev netdev bluetooth scanner
chris@Asus:~$
I think this means that I have the permissions so it's not a permissions problem.

I then tried:
chris@Asus:~$ ls -la /usr/bin/wodim
-rwxr-xr-x 1 root root 359108 Oct 18 2010 /usr/bin/wodim
chris@Asus:~$
and:
root@Asus:/home/chris# ls -la /dev/sr0
brw-rw----+ 1 root cdrom 11, 0 Feb 8 01:32 /dev/sr0
root@Asus:/home/chris#

This is an earlier suggestion of yours:
root@Asus:/home/chris# fuser /dev/sr0
root@Asus:/home/chris#

From that output, we can conclude that your user does have correct permissions over the device. BUT your burning utility (wodim) isn't properly set up to burn discs as a user.

Log in as root (or switch user) and do this:

Then it should let you burn discs properly.

As to your ejecting problem, I've done some reading and it seems that HAL polling can disrupt the normal operation of some drives. If you want to try disabling it, you need to run this command:

If that doesn't solve the problem, then you can re-enable polling with this:

root@Asus:/home/chris# chmod +s /usr/bin/wodim
root@Asus:/home/chris#

I assumed you'd want me to check the results:
root@Asus:/home/chris#
ls -la /usr/bin/wodim
-rwsr-sr-x 1 root root 359108 Oct 18 2010 /usr/bin/wodim
root@Asus:/home/chris#
I understand that this is changing permissions although I'm not quite sure what.

I also did the hal command, I've reset that though because after rebooting twice it worked with a disk in but then refused to eject an empty tray. Could the empty tray be relevant?

It gives the wodim command escalated privileges so that it can communicate directly with the drive without requiring you to log in as root.
I dunno. I wouldn't rule out the possibility that you may have damaged the drive with a paperclip after all that.

lol! No it's not damaged it - there's a solid lump of plastic there. I'm sure it's a software problem for several reasons:
- it works most of the time
- it works without the ribbon cable
- I've had it before with a different PC and a different drive
- it happens mostly with an empty drive

How is the drive jumpered? Is it on "Cable Select"? That can cause these kinds of odd behaviours. If so, try putting the jumper on Master and using the end connector of the ribbon cable.

Edit: If that doesn't work, I got nuthin' else.

rkelson: I've taken out the cable select cable, put in a plain one and altered the drive jumpers from cable select to master and slave. I've also realised that I missed your message 21. I'll follow your suggestions therein.

Message 21:



[ 2.224354] sda: sda1 sda2 < sda5 sda6 >
[ 2.268427] sd 2:0:0:0: [sda] Attached SCSI disk
[ 2.295672] sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 2.295678] Uniform CD-ROM driver Revision: 3.20
[ 2.295841] sr 2:0:1:0: Attached scsi CD-ROM sr0
[ 2.304518] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 2.304582] sr 2:0:1:0: Attached scsi generic sg1 type 5

block fd loop5 psaux sdb tty tty20 tty33 tty46 tty59 urandom vcsa5
bsg full loop6 ptmx sdc tty0 tty21 tty34 tty47 tty6 vcs vcsa6
bus fuse loop7 pts sg0 tty1 tty22 tty35 tty48 tty60 vcs1 vcsa7
cdrom fw0 lp0 random sg1 tty10 tty23 tty36 tty49 tty61 vcs2 vga_arbiter
cdrw hpet MAKEDEV rfkill sg2 tty11 tty24 tty37 tty5 tty62 vcs3 xconsole
char initctl mcelog root sg3 tty12 tty25 tty38 tty50 tty63 vcs4 zero
console input mem rtc shm tty13 tty26 tty39 tty51 tty7 vcs5
core kmsg net rtc0 snapshot tty14 tty27 tty4 tty52 tty8 vcs6
cpu_dma_latency log network_latency scd0 snd tty15 tty28 tty40 tty53 tty9 vcs7
disk loop0 network_throughput sda sndstat tty16 tty29 tty41 tty54 ttyS0 vcsa
dri loop1 null sda1 sr0 tty17 tty3 tty42 tty55 ttyS1 vcsa1
dvd loop2 parport0 sda2 stderr tty18 tty30 tty43 tty56 ttyS2 vcsa2
dvdrw loop3 port sda5 stdin tty19 tty31 tty44 tty57 ttyS3 vcsa3
fb0 loop4 ppp sda6 stdout tty2 tty32 tty45 tty58 uinput vcsa4


loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 sda sdb sdc sr0

I reckon that means that it is sr0

This is no longer a problem now I have fixed some other problems which arose later, see thread 937690

I've finally found out what the problem is. Nothing to do with the operating system or firmware.

The proof of it not being an OS problem is that it still happens if you disconnect the ribbon cable. The statement in my post #28 that it worked without the ribbon cable is unfortunate as it must just have worked once or twice by chance.

There is a round magnetic puck (that clamps the disc from above as the drawer closes). If motor belt driving the drawer is slack or slippery it can't overcome its attraction to the drive spindle.

The proof that it is a mechanical problem is that if you temporarily remove the puck without a disk in the problem stops.

Other symptoms are:

• a loud "clunk" when it fails to open
• it sometimes needs a helping hand to close
• sometimes seems to think it's open when it's closed and vice versa

Solution: Open the drive case and clean the belt and associated pulleys with methylated spirit to get the belt gripping better. I would also very sparingly grease (not oil) the gear teeth.

I have fixed two drives like this.

The original information came from http://www.tomshardware.co.uk/forum/...ject-disc-tray Don't follow the advice to make a spacer from tape to move the two magnets apart to reduce the magnetic attraction, as the disk won't be held tightly enough. Even if you test it and the disk doesn't wobble, the grip isn't good enough and it can slip. Two methods are mentioned, one is better than the other but it is still not recommended.

I can't remember what I as on about in post #32!