CD-ROM tray closes automatically after eject

Just to add that when I finally manage to quickly take out the dvd
from the drive, and push the eject button, it ejects the tray but
doesn't reinsert the tray of the device

It's the same for me

The cd/dvd-rw drive is a PATA device

$ sudo lshw -C disk
  *-cdrom
       description: DVD-RAM writer
       product: DVDRAM GSA-4163B
       vendor: HL-DT-ST
       physical id: 0
       bus info: scsi@0:0.0.0
       logical name: /dev/cdrom
       logical name: /dev/cdrw
       logical name: /dev/dvd
       logical name: /dev/dvdrw
       logical name: /dev/scd0
       logical name: /dev/sr0
       version: A103
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 status=ready
     *-medium
          physical id: 0
          logical name: /dev/cdrom

Cool, confirmed :)
I'm not sure about the package though

Also on Kubuntu:

root@upstairs-linux:~# apt-cache policy eject hal
eject:
  Installed: 2.1.5-9ubuntu2
  Candidate: 2.1.5-9ubuntu2
  Version table:
 *** 2.1.5-9ubuntu2 0
        500 http://gb.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
hal:
  Installed: 0.5.11-4ubuntu3
  Candidate: 0.5.11-4ubuntu3
  Version table:
 *** 0.5.11-4ubuntu3 0
        500 http://gb.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

root@upstairs-linux:~# eject -v
eject: using default device `cdrom'
eject: device name is `cdrom'
eject: expanded name is `/dev/cdrom'
eject: `/dev/cdrom' is a link to `/dev/scd0'
eject: `/dev/scd0' is not mounted
eject: `/dev/scd0' is not a mount point
eject: `/dev/scd0' is not a multipartition device
eject: trying to eject `/dev/scd0' using CD-ROM eject command
eject: CD-ROM eject command succeeded

root@upstairs-linux:~# lshw -C disk
  *-cdrom
       description: DVD-RAM writer
       product: DVD_RW ND-4570A
       vendor: _NEC
       physical id: 3
       bus info: scsi@5:0.1.0
       logical name: /dev/cdrom
       logical name: /dev/cdrw
       logical name: /dev/dvd
       logical name: /dev/dvdrw
       logical name: /dev/scd0
       logical name: /dev/sr0
       version: 1.03
       serial: [_NEC DVD_RW ND-4570A 1.0306080300
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 status=ready
     *-medium
          physical id: 0
          logical name: /dev/cdrom

I can confirm the problem:
When I try to eject a cd/dvd, Ubuntu intrepid inserts the cdrom right back in the cd/dvd drive.

OS Ubuntu 8.10 Beta 64-bit fully updated.

I can confirm the problem:
When I try to eject a cd/dvd, Ubuntu intrepid inserts the cdrom right back in the cd/dvd drive.

on a asus p5q motherboard

hal basically didn't change in intrepid, so I guess the new kernel treats the polling ioctls differently/badly. WHen killing hald-addon-cdrom, the phenomenon disappears, so I'm pretty sure it is that.

Indeed the CDROM_DRIVE_STATUS ioctl in the current intrepid kernel now actually closes the CD-ROM door instead of just saying "tray open/no CD". Reproducible with

  perl -e 'open F, "/dev/scd0"; ioctl (F, 0x5326, 0x7fffffff);'

It also happens with using "0" as argument, so it doesn't depend on the flags you pass.

Given that the ioctl documentation about CDROM_DRIVE_STATUS has a possible value of CDS_TRAY_OPEN, it does not say that it causes the tray to close, and it behaved correctly in earlier kernel versions, I am inclined to claim that this is a kernel regression.

CDROM_DISC_STATUS does the same.

I just tested it again, and the ioctl was actually a red herring. The tray already gets closed when merely opening the device:

- open CD tray
- head < /dev/scd0
  bash: /dev/scd0: No medium found

> opening /dev/scd0 causes tray to be closed
I don't suppose this makes it udev 's fault, right?

Mmh. I'd say that this is actually a feature, I've got no problem with that.

If you set O_NDELAY when opening, the tray does not get closed.

That's as it should be. The previous description was correct,

savvas: No. Udev doesn't open devices. You mean HAL, but see my previous comment.

It is really the open(), the ioctl() seems to be innocent. See my updated report and test case in the upstream bug.

I can reproduce the behaviour in Martin's test case (https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/283316/comments/11) on one of the optical drives in my desktop, but not on the other.

I cannot reproduce any misbehavior using eject(1), only manually opening the drive when the tray is open.

There is a fix identified in the upstream bug report.

This bug is currently targeted for 8.10, but would require a new kernel. What is the plan?

I can reproduce it 100% when ripping CDs (using my own script, which calls cdparanoia+eject).
At other times, it's intermittent and seems to depend on the machine's load, which doesn't really surprise me.

Matt, so far we just found out which commit introduced this. I'm not terribly scared of entirely reverting it (the other bug it introduces is less bad), but ATM I'm picking apart the commit and check which bit causes the tray closing. With a little luck, I can come up with a patch which keeps the return value correct and fixes this tray closing bug.

I'm inclined to pass on this due to the lateness of the cycle. My recommendation is open a release note task and document for the Gold release and we could take it in on the first post Intrepid upload.

Unfortunately some simple bisecting of that patch doesn't lead to anything which both fixes this bug and keeps correct return values. So if we want to fix this in intrepid, I suggest to revert the entire patch [1] and live with the status always being CDR_DISK_OK or CDR_TRAY_OPEN. Hardy has the very same problem ([1] wasn't applied in hardy yet), and it did not cause much harm so far.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=210ba1d1724f5c4ed87a2ab1a21ca861a915f734
Note that there is some fuzz, scsi_test_unit_ready() was replaced by sr_test_unit_ready()

If cd/dvd disk is inserted that is Not mounted (Dvd with un-mountable UDF..)
before unmount and ejection, then it does not even open cd/dvd doors
but re-insert it right away without even opening it.
If the eject button is pressed again briefly after first time, then it can be opened..
Tested on amd64

I would agree with Martin Pitt's proposal that the patch which introduced this behavior be reverted such that the drive does not unexpectedly close any longer. That is really the more important issue here; it will be confusing for users.

It happens for me when I eject a CD manually (pressing the button on the disc drive to open the tray), or when I click the eject button next to the drive in Nautilus, or when I am finished burning a CD or DVD image and the drive is ejected. In all three situations the drive tray being sucked back in is highly unexpected behavior.

Martin's proposal is most definitely the most agreeable. It is very unexpected behavior for the tray to snap shut almost right away.

I can also verify that on occasion the disc will unmount and then remount without any movement of the tray whatsoever.

I can confirm problem.

OS: Intrepid Ibex 8.10 64bit

Same here on a pata system with last Intrepid Kernel 2.6.27-7.
The only way to get the try out is to press the eject button one moire time immediately after first eject...

Confirm the same problem.

OS: Intrepid Ibex 8.10 64bit

Even after a successful write with K3b the tray opens then closes.

This should be fixed with udev 126:

Summary of changes from v125 to v126
=======================

Kay Sievers (9):
   ...
   ...
   rules: run vol_id on opticals only if media is found

After upgrading to udev 126, we no longer reproduce this issue except after writing a DVD-R with k3b.

Ozan Çağlayan [2008-10-28 7:02 -0000]:
> Kay Sievers (9):
> rules: run vol_id on opticals only if media is found
>
> After upgrading to udev 126, we no longer reproduce this issue except
> after writing a DVD-R with k3b.

That's curious. I can *only* reproduce it if there was a media in the
CD drive, thus this change should not make any difference. Anyway,
I'll read through bug 280931 and check whether it has a viable
workaround.

Release notes text added:

== CD eject problems ==

After ejecting a CD tray containing a disc, the tray will be immediately retracted, making it difficult to remove the disc ([[https://launchpad.net/bugs/283316|bug 283316]]. This can be worked around by pressing the eject button again before the disc is fully mounted, after which it will stay open. We expect to fix this in a post-release update.

Same here on the RC and on the Final.

Hi - yes I have the same issue.

The device is described thus:

 *-cdrom
       description: DVD-RAM writer
       product: DVD RW DRU-840A
       vendor: SONY
       physical id: 1
       bus info: scsi@1:0.0.0
       logical name: /dev/cdrom
       logical name: /dev/cdrw
       logical name: /dev/dvd
       logical name: /dev/dvdrw
       logical name: /dev/scd0
       logical name: /dev/sr0
       version: SS01
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 status=nodisc

I am running the Intrepid 8.10 final release from 30 oct with updates as of today 11.00 am South Africa time.
The hardware is fine under Windows XP

Thanks

i can confirm this issue exists, brasero is currently (for me at least) impossible due to the speed at which the tray opens and closes itself

i made a one-line fix to /etc/udev/rules.d/60-persistent-storage.rules that seemed to solve the problem without even rebooting the machine, it was mentioned in another thread...look for the following in said file:

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

just beneath the second line, add the following (make sure to back up your original):

ENV{DEVTYPE}=="disk", KERNEL=="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

(the subtle difference is in the "KERNEL" portion)

i'll attach my "version" of the file in case anyone would like to try it themselves as a temporary workaround:

> i'll attach my "version" of the file in case anyone would like to try it
> themselves as a temporary workaround:

Any possible consequences we should know about?

This last fix by prower solved the bug for me.

Here's a debdiff template I made for you, it's attached.
Edit it and reupload it, propose it as a patch :)

I posted a very similar fix in my report about this problem the 25th but nobody seemed to care.

So much for trying to help.

prowrer said "it was mentioned in another thread"

I personally didn't check every duplicate as it was marked as a duplicate.

> I personally didn't check every duplicate as it was marked as a duplicate.
>
Rephrased: I personally didn't have time to check every duplicate and
what they said. If you believe you're the one who should get their
name, edit the template debdiff accordingly. As I said, it's a
template.

(Note: not that the patches are always used)

But wait until we get some more confirmations on this, you never know
what this could do for other drivers/media

I'm experiencing the same issue on lucid amd64 with an Optiarc DVD RW AD-7243S.
Either the CD gets ejected and pulled in immediatly after or it is not ejected at all (braseros auto-eject after burning).

Experiencing the same with Kubuntu 10.04. I'll rip a CD with Audex and once ripping has finished it will eject the CD. Unfortunately the tray closes again almost instantly.

I was experiencing the same on Karmic and now on Lucid.

Also getting this on Lucid

sudo sysctl -w dev.cdrom.autoclose=0

Work for me as a fix. Is this a regression?

I can confirm the <code>sudo sysctl -w dev.cdrom.autoclose=0</code> patch solves this problem under Lucid.

I can confirm that the above command fixes the auto retract problem. Now all we need is an official fix for this two year old issue :S

I have now added a second drive and have to enter
sudo sysctl -w dev.cdrom.autoclose=0
every time I boot the machine otherwise the tray closes automatically again.

Has anyone noticed a slight lack of involvement from the devs? I remember awhile back that any bug would usually get attention within a day or so. I don't know what's going on here.

If sudo sysctl -w dev.cdrom.autoclose=0 works for you, I suggest adding it to /etc/sysctl.conf, so it's ran at each boot.

@TGP1994: The ORIGINAL issue reported in this bug was fixed...what you and others are having is a different bug that displays the same symptom. If you want this resolved, you should open a NEW bug by typing 'ubuntu-bug linux' from the command line. Then subscribe me (robbie.w), I can then target the bug to Lucid and we can try fixing it in 10.04.2 or an SRU.

-Robbie

Oh, I never thought of actually ubuntu-bug'ging the linux package.

Anyhow, I'll subscribe you to my issue.

For any one whose problem with the CD tray closing was not resolved here a new bug report on this has opened at https://bugs.launchpad.net/ubuntu/+source/udev/+bug/581404

Hello, I thought I'd bump this as it's still vary annoying. What bothers me most about this is that there is some process that is obviously hammering the optical drive with requests. This might not disrupt throughput to/from the drive, but it can't be good for it.

I'd like to test with a patched kernel that would hopefully print the PID and/or name of the application responsible. Is there anyone who could write such a patch?

Another note is that only the first opdrive is effected, the second on my system operates without issue.

I'd like to be able to have the drive auto-close, so disabling this nice feature is not an option for me... even if it where to work around this bug.

Just iso-testing Oneiric ubuntu.com/daily-live/20111007 (the first final test image) and this thing reared it's ugly head.

I had not seen this since Intrepid. Did someone copy some old, bad code?

BTW this has been known to break optical drives in the past ............... including two of my own :^(

To others testing that encounter this:

Just let the disc go back in, then make the language selection/live menu appear, then select "Boot first hard disc" and you can then SAFELY remove the disc w/o damaging your optical drives ;^)

Arrgh, I wrote that very poorly. Should be:

Just let the disc go back in, LET IT REBOOT, and then make the language selection/live menu appear, then select "Boot first hard disc" and you can then SAFELY remove the disc w/o damaging your optical drives ;^)

This appears to have cost me an ASUS DRW-24B1ST/BLK/B/AS.

How ticked off would you be?

Erick - It would help if you were to provide a test case for recreating this bug report. I tried booting a Ubuntu Oneiric AMD64 Desktop CD and choose to Try Ubuntu and then to shutdown the system. The disc ejected fine and did not close automatically after the eject.

Sorry Brian, wasn't thinking clearly ;^(

I had just completed an installation with http://cdimage.ubuntu.com/daily-live/20111007/oneiric-desktop-i386.iso and after clicking on restart now (rather than continue testing), the reboot process appeared to work as normal, but when the disc ejected the tray just automatically closed.

My first thought was, oh no (with expletives), but I just let the reboot complete then hit a key to display the boot menu and selected boot from first hard disc. I then just ejected the disc using the icon on the desktop and thought all would be fine, but as I continued to try more tests (this time with Lubuntu images) my optical drive would no longer consistently eject or retract as it should :^(

I've previously only seen this with Intrepid (which released with this bug) and Fedora perhaps a year or so ago (don't remember the version, but I believe I was trying some grub 2 dual/multi-boot scenarios, I don't commonly use Fedora and I'd think that info is irrelevant here anyway).

I notice however that there has since been a new release listed on the iso-tracker: http://cdimage.ubuntu.com/daily-live/20111007.1/oneiric-desktop-i386.iso, so I need to formulate a safe testing plan. After leaving my testing box shut down nearly all day yesterday the optical drive seems to be working OK again so I hope I got lucky.

Regarding the "drive breakage", what seems to happen is that something electronic gets "confused" following this. I don't understand electronics well enough to understand, but I have both Sony and Lite-on SATA drives in the closet that no longer work properly after encountering this with Intrepid and Fedora some time ago. I have a number of old IDE CD-ROM drives so I may just swap one of those in to see what happens. I'll report back after more testing.

OK, I swapped in an old CD-ROM drive, tested it a bit, and very easily reproduced this by installing 20111007 again. Upon completing the installation and selecting reboot now the CD ejected and immediately retracted :^(

The most worrisome part is that even following my procedure - letting the drive do it's thing, clicking on enter, waiting for reboot, unhiding the boot menu, selecting boot from first hard disc, etc. - once removing the disc by clicking on eject, the drive acts "funny" for quite a while. But after a few reboots, trying a known good Natty disc, etc. the drive seems to be working properly again.

So now I'm going to try 20111007.1 and see if it's still reproducible. If so I'll file a new bug report against ubiquity so apport can collect some info. Don't know what else to do.

I'm having an absolutely horrible experience here :^(

I've never been stuck like this before. Post installation the CD fails to eject at all now, the display says remove and close tray but the tray is not open ............... but pushing the button fails to open the tray.

More sadly the newly installed DE fails to boot. But this old CD ROM is also in question.

If the devs are only testing in VM's I'd suggest they try some actual hardware installs. I'm going to wait until next week and try again since I don't have a warehouse full of spare drives!

Erick, also you really need to open a new bug. Your bug is very unlikely to be exactly the same as this "fix released" bug from 2008.

Jeremy, I agree, and that's exactly what I said in the last sentence in comment #189.

But I'm stuck ATM. This old CD drive is acting up since that failure with 20111007 so I haven't been able to adequately test 20111007.1. I'd hoped disconnecting the drive for a while might help but it didn't.

Now I need to decide whether to risk a fairly new CD/DVD drive or not. If I break it I won't be able to afford a replacement for weeks :^(

OK, I made some progress. I harvested a couple more optical drives from old PC's that I'd not yet had time to look at and 20111007.1 seems to be OK, but 20111007 was junk and holds a potential to destroy optical drives.

I've also retested with that original Asus drive and it's also OK with 20111007.1 but I will not mess with 20111007 anymore, it's going in the waste bin. I'll watch for any recurrence of this with upcoming Oneiric rebuilds.

Normally I wouldn't be so concerned with the cost of an optical drive or two, but 2011 has not been kind to me financially ;^)

Anyway, no need for a new bug report ATM.

Just thought to add, I will try to save both the 20111007 and 20111007.1 installs just in case any of the devs do want to look at any of the logs or such.

The difference between the two has been an udev change:

  https://launchpad.net/ubuntu/+source/udev/173-0ubuntu4

I don't fully understand the ramifications of that patch towards
picking up CD-ROM events, but all other package updates which went
into the 1107.1 build has anything remotely to do with CD handling.

So if it's confirmed that 1107 has that bug, but 1107.1 not, then most
likely that udev change magically fixed the problem.

Martin, I can absolutely confirm that the bug does NOT exist in 20111007.1 because I cross-tested with my Intel box w/o a problem. I really wanted to be certain because IMHO the worst two kinds of bugs are those that either damage hardware or result in data loss.

My goal as a tester is to try and ensure that every new Ubuntu user is as impressed as I was when I found Gutsy ;^)

Regarding the udev change I'd have no idea, that's too technical for me, but looking at past progress notes here that makes sense - particularly given my past history with similar behavior in both Fedora and Ubuntu.

I'm now testing Lubuntu live images.

Just a heads up so no one wastes any time on this, the 20111009-i386 iso is also working great ;^)

the 20111010 amd64 desktop iso just did it to my cd drive , completed installation but when I went to reboot it didn't eject the drive just clicked repeatedly , I shutdown with ALT>SYSREQ>B and during startup POST I could eject the cd with the drive open button .

Still working perfectly here with 20111011-i386. I missed the builds yesterday due to a power outage.

Problem still exists in Ubuntu 11.10.

I solved my problem by swapping the cd drives of two different boxes. They both work fine now, where as before only one did. So... particular hardware combinations trigger this bug?

Problem exists in Kubuntu 12.04.

Same problem in Kubuntu 12.04

Same bug in Ubuntu 12.04

This is still happening for me on up to date 13.10. What's going on? Was this fixed and then the fix got reverted, or what?

@Shock
I had this problem, but it got fixed by dusting/cleaning the CD-drive.

Upgrading from Kubuntu 16.04 LTS to 20.04 LTS introduced this bug into my system, so I've gotten in the habit of pressing the physical Open button just as the tray starts to close again, after which it doesn't try a second time.

My hypothesis is that it's trying to read the drive after it opens, which triggers the close as a side-effect.