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 don't want to take credit. The one who should is the Christian Krause on the red hat bugzilla. I'm just stumped that no dev reacted and that my report got marked dupe even though it was created a lot earlier than this one.

https://bugzilla.redhat.com/show_bug.cgi?id=453095#c26

My only question is: are users expected to take care of this themselves, or will this fix be distributed as an update anytime soon?

Thanks razor! I've updated the bug report, I'm sorry I haven't seen your report a bit earlier :(
Gentoo seems to have pushed this workaround as a fix for the bug

i should add an update to this as well, i was not trying to take credit for a patch or anything like that

as i mentioned i had seen the fix in the thread and just decided to mention it in this thread as i hadn't seen the solution reported

it's also important to note that other than the fact that it solves the problem in my case, i don't know what other potential consequences it might have so apply it at your own risk...but again in my own personal case, the only difference i've noticed is that my dvd tray doesn't try to bite my fingers off any more :>

i hope that it works for people, and i'm sure that once an appropriate solution is found this will be fixed upstream, it might be as simple as that one line change but i am no expert on udev

The fix works here too, anyone else to confirm this?
Can a developer / packager / someone push it for intrepid-proposed if possible? :)

Fedora have also released this workaround for testing:
http://rpm.pbone.net/index.php3/stat/22/idpl/8874918/com/changelog.html

Fix works for me.
On redhat and ubuntuforum written same fix.

i've done some testing on my own pc with different bits of storage hardware to see if they were affected by the workaround, including a usb stick, 250GB 2.0 hard drive and an external Pioneer DVD burner, as well as the separate CD and DVD burners that are already internal to the machine...i've yet to find any instances of things not being properly mounted/unmounted or any related data loss if that is helpful to anyone reading this thread.

i hope the issue is at least looked into soon as between that and the e1000e bug that i've been bitten by (in the final release and mentioned here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/127749) have made intrepid a difficult upgrade

Fix works for me. Thanks for saving my fingers. I was starting to feel like Ronnie Barker in 'Open all hours' with the till. Cheers razor.

I should note, the fix is somewhat strange. It would be better to change
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
to
ENV{DEVTYPE}=="disk", ATTR{removable}=="1", GOTO="persistent_storage_end"

This would be the same as adding
ENV{DEVTYPE}=="disk", KERNEL=="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
but four comparison operations cheaper for your processor, meaning it is FASTER, MORE EFFICIENT, and LESS POWER CONSUMING.

Thanks for reading.

Fix worked for me too!
Thanks to prower and razor :-)

It seems that this this actually an udev problem after all:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f755fd5657b619fd27160ad202fc5d773d096e9c

So it seems that the last ioctl kernel patch referenced above just fixed the return status enough to make the emitted change events actually work, so that udev's rules would kick in.

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

The fix/workaround by prower2000 worked for me too. Thanks.

When might the NON-programmers among us expect a fix for this problem ?

Thanks.

The udev patch in proposed works fine!

I'd already applied the patch manually some time ago, so I changed "/etc/udev/rules.d/60-persistent-storage.rules" back to it's virgin state, and checked to be sure the problem existed. It did.

I then applied your patch via proposed updates, and viola! It works great! I've tried all of my common programs and no glitches apparent!

I'm curious when this may be incorporated into the Live CD? Maybe a 8.10.1 coming soon I hope! Maybe available in a daily build?

Good work!

All mentioned fixes mentioned so far does not repeat does not work for me. This is a Sony PATA DVD-RW/RAM drive that is brand new with a SATA Seagate 8200.11 320GB hard drive on a Gigabyte GA-MA74GM-S2H MOBO

I applied the new udev package from the backports repo and eject is working perfectly now! Nice work!

I can confirm that with udev 124-8 from Intrepid I see the cdrom closing problem on eject; with udev 124-9 from intrepid-proposed I no longer see the problem. eject, eject -t, and eject -T work as expected, as well as ejecting other block devices.

@Glenn Sullivan: when you say that all fixes do not work for you, does that include the udev package in intrepid-proposed?

Updated udev from intrepid-proposed fixes the problem for me.

I confirm the problem (Ubuntu Intrebid Ibex 8.10 with SATA DVD/RW)

I can confirm the fix from intrepid-proposed. Thanks!

I wish to confirm bug.

It happens only when cd was mounted in cd drive and ejected afterwards.
Proposed fix solved problem.
For now I don't see any side effects of changing "/etc/udev/rules.d/60-persistent-storage.rules"

Thanks!

This bug was fixed in the package udev - 124-10

---------------
udev (124-10) jaunty; urgency=low

  * Cherry-pick from Debian 0.125-6:
    - Move in the udeb /lib/debian-installer-startup.d/S02udev to
      /lib/debian-installer/start-udev because udev will now be started
      before the busybox init. Patch by Jérémy Bobbio. (Closes: #493865)

udev (124-9) intrepid-proposed; urgency=low

  * Add debian/patches/01-cdrom-vol_id-probing.patch: Do not run vol_id on
    optical drives if there is no medium in the drive. Doing so open()'s the
    drive without O_NONBLOCK which closes the tray. Patch backported from
    upstream GIT (released in version 126). (LP: #283316)

 -- Colin Watson <email address hidden> Tue, 04 Nov 2008 23:43:32 +0000

Confirming udev 129-9 to work, thanks very much!

Confirming that udev 129-9 worked for me too. Thanks for the quick fix....

Just to confirm that udev 124-9 from intrepid-proposed fixed the bug.

Confirmed that udev 129-9 also worked for me. Thanks.

None of the fixes work for me.

How do I get udev 124-10. I have 124-8 on my computer, SynapticPM shows no upgrade available. This is an important upgrade if you ask me. As said in Brainstorm, this should not happen in a 2008 OS.

Thanks!

Umang

> How do I get udev 124-10. I have 124-8 on my computer, SynapticPM shows
> no upgrade available. This is an important upgrade if you ask me.
You mean 124-9 ? Enable proposed, as explained in a previous comment:
https://wiki.ubuntu.com/Testing/EnableProposed

124-10 is for the development release only ("future" ubuntu 9.04
jaunty jackalope) :)

rfurman24 - For you comment to be taken into consider you need to let us know some more information. Which specific fix you tried, hopefully installing udev version 124-9 from Intrepid proposed, what steps you took to test the fix and what exactly happened.

I have tried two of the fixes mentioned above. I changed the 60-persistent-storage.rules file using udev 124-8. This did nothing to solve the problem. Next I upgraded to udev 124-9 from Intrepid proposed. This did not work for me with either the original 60-persistent-storage.rules file or the modified one. The only way I can get the tray to eject without immediately closing is to first unmount the volume and eject it with the button on the drive. You have to depress this button once to begin the eject and a second time during the ejection process to keep the tray open. An eject -v appears to work correctly, but the drive closes immediately. With the same drive this problem does not occur on Ubuntu 8.04 "Hardy Heron". Is there addition information I could provide to help solve this critical problem?

OS: Intrepid Ibex 8.10 64bit

rootl@homesystem:~$ eject -v 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 mounted at `/media/cdrom0'
eject: unmounting device `/dev/scd0' from `/media/cdrom0'
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

 *-cdrom
       description: DVD-RAM writer
       product: CDDVDW SH-S203B
       vendor: TSSTcorp
       physical id: 0.0.0
       bus info: scsi@5: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
       logical name: /media/cdrom0
       version: SB01
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,utf8 state=mounted status=ready
     *-medium
          physical id: 0
          logical name: /dev/cdrom
          logical name: /media/cdrom0
          configuration: mount.fstype=iso9660 mount.options=ro,nosuid,nodev,utf8 state=mounted

Brian, the last fix I tried was the udev 124-9. I have tried changing the /etc/udev/rules.d/60-persistent-storage.rules with everything read hear and on the ubuntu forums. For the most part the udev upgrade did the same thing. I have two ide dvdrw drives. I does not appear to me that they get mounted the same. If I go to / there is a cdrom folder which links to the drive that is working. If I go into /media there is a cdrom, cdrom0, and cdrom1. The cdrom and cdrom0 point to the working drive the cdrom1 does nothing. In place of the cdrom folder in /media is a folder labeled with the audio disc name for the non-working drive. I also have Hardy on another disc and everything works with it.

Many many people are affected by this bug. Each one of them should not be expected to find this bug, turn on backports and download the new udev. It should just be released as recommended update in everyone's update manager, IMHO.

My problem sounds identical to rimmel's only I am running 32bit. It works if I unmount first then eject.

I confirm that updating the version of the udev package from 128-8 to 128-9 from intripid proposed worked for me immediately (!). Thanks a lot, what happy day!
The results of "lshw -C disk" (after update) see in attachment.

The second drive will eject dvds and plain audio discs fine unless the working drive is open or opening. It will not operate properly no matter what if the disc has music and pics or video. I included my lshw -C disk output.

 *-cdrom:0
       description: DVD writer
       product: DVD_RW ND-3540A
       vendor: _NEC
       physical id: 0.0.0
       bus info: scsi@0:0.0.0
       logical name: /dev/cdrom1
       logical name: /dev/cdrw1
       logical name: /dev/dvd1
       logical name: /dev/dvdrw1
       logical name: /dev/scd0
       logical name: /dev/sr0
       version: 1.01
       serial: [_NEC DVD_RW ND-3540A 1.0105031600
       capabilities: removable audio cd-r cd-rw dvd dvd-r
       configuration: ansiversion=5 status=nodisc
  *-cdrom:1
       description: DVD-RAM writer
       product: DVDRW LH-20A1P
       vendor: LITE-ON
       physical id: 0.1.0
       bus info: scsi@0:0.1.0
       logical name: /dev/cdrom
       logical name: /dev/cdrw
       logical name: /dev/dvd
       logical name: /dev/dvdrw
       logical name: /dev/scd1
       logical name: /dev/sr1
       logical name: /media/MOUTH_CALLING
       version: KL0N
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 mount.fstype=udf mount.options=ro,nosuid,nodev,uid=1000,utf8 state=mounted status=ready
     *-medium
          physical id: 0
          logical name: /dev/cdrom
          logical name: /media/MOUTH_CALLING
          configuration: mount.fstype=udf mount.options=ro,nosuid,nodev,uid=1000,utf8 state=mounted

Copied to intrepid-updates.

Not sure what "Copied to intrepid-updates" means but the problem is not fixed. It may have fixed the problem for those who only have one drive but does not appear to have fixed the concern for those who have two drives. After the nightmare of using Gutsy and now this I am strongly considering staying with Mint. I do love the community and anything beats Windows but I think the 6mo release cycle is a little fast.

His post was saying that the fix was released to general Intrepid users (as
opposed to only those with backports enabled?). Have you downloaded the
most recent updates, which includes an update to udev? I've got 2 optical
drives also (a CD-RW and a DVD-RW) and this update fixed the issues for me.

I've now applied this fix to three machines. All work fine. My own machine has a SATA DVD+RW and an IDE CD/DVD. They both work fine!

I do hope they apply this to the Live CD at some point, like a 8.10.1!

I am using udev 124-9 and it is still broken.

rfurman24: I note that Erick Brunzell's case where it worked had one SATA drive and one IDE drive; are both your drives the same? (e.g. both IDE?) Also out of curiosity, have you tried rebooting your system since the upgrade to udev 124-9?

rfurman24: Have you ever thourght that maybe it's a different bug with
a similar problem?

I just ran Update Manager which installed the udev updates. Before doing so I have removed the /etc/udev/rules.d/60-persistent-storage.rules changes and confirmed that the problem still exists.
After the update was complete I tried again and the tray stayed out, so I confirm the released udev fix worked for me.
Thank you.

After installing the updates containing the new versions of udev, I ran four tests and determined the problem has been solved. I checked against pressing the button twice, once on the new eject buttons in nautilus and once right clicking on the disk drive and hitting "eject". I would also like to point out I did not have to reboot my machine for this to take effect.

I would like to caution those who haven't installed the updates yet. Backup your /boot/grub/menu.lst file before doing so. For some reason when I installed updates on my laptop it was overwritten and didn't contain any entries. So when the machine came back up, it dropped straight into the grub command prompt.

Yes I did reboot although you should not need to. I have considered it may be a new bug. I opened a new bug report with no answer. Both drives are ide although not the same model/brand. As I stated above they are not getting mounted the same. The problem is when a disc contains pictures and ubuntu/gnome see the disc as a picture disc as well as audio. It works fine on dvds or plain audio discs unless I open the working drive while trying to operate the drive in question.

Yes working properly now...
thanks

rfurman24 wrote:
> Yes I did reboot although you should not need to. I have considered it
> may be a new bug. I opened a new bug report with no answer. Both drives
> are ide although not the same model/brand. As I stated above they are
> not getting mounted the same. The problem is when a disc contains
> pictures and ubuntu/gnome see the disc as a picture disc as well as
> audio. It works fine on dvds or plain audio discs unless I open the
> working drive while trying to operate the drive in question.
>
>

Yes I did reboot. No the problem was and is not fixed.

Updating udev has fixed this for me as well it seems.

I have not tried very extensively, but it's looking good now!

rfurman24: FYI, my computer has an IDE DVD+/-RW drive and to test to see if your problem is reproducible on my system, I added an IDE CD-ROM drive and they both work fine when testing them with two different Live CDs.

As per sudo lshw:

---
           *-cdrom:0
                description: DVD-RAM writer
                product: DVD-RAM GSA-H54N
                vendor: HL-DT-ST
                physical id: 1
                bus info: scsi@3: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: 1.00
                serial: [HL-DT-STDVD-RAM GSA-H54N1.0007/04/10
                capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
                configuration: ansiversion=5 status=open
           *-cdrom:1
                description: SCSI CD-ROM
                physical id: 0.1.0
                bus info: scsi@3:0.1.0
                logical name: /dev/cdrom1
                logical name: /dev/scd1
                logical name: /dev/sr1
                capabilities: audio
                configuration: status=open
---

I don't think that this is this bug.

minor correction: "when testing them with two different Live CDs" physically in the two drives but booting from the HD.

Thanks for putting udev 124-9 on intrepid-updates. I had used backports to get it earilier, now it's on upgrades. Thanks again. It has fixed the problem for me. Unsubscribing from this bug.

I don't know if it's the same bug, but the same thing just happened to me on Hardy.

I'm using Kubuntu on KDE 3.5.10 with both gnome and KDE4 installed as well. All the updates and backports are installed, minus the proposed ones.

After burning a DVD+R with K3B, the DVD tray (second burner, SATA) was ejected and promptly closed again. However, the DVD wasn't mounted and, as a matter of fact, K3B no longer sees that drive. Pressing the eject button opens the tray, but it closes again after a fraction of a second.

I can't really test the fix, as that file in Hardy doesn't have the mentioned section at all.

cya
Raziel-chan

If it happened to you on Hardy, then it is not the same bug.

124-9 also is not working for me. The bug is still there in full force.

*-cdrom:1
                description: SCSI CD-ROM
                physical id: 0.1.0
                bus info: scsi@0:0.1.0
                logical name: /dev/cdrom1
                logical name: /dev/scd1
                logical name: /dev/sr1
                capabilities: audio
                configuration: status=ready

 *-cdrom:0
                description: DVD reader
                product: DVD+RW SOHW-822S
                vendor: LITE-ON
                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/scd0
                logical name: /dev/sr0
                logical name: /media/cdrom0
                version: VPPA
                capabilities: removable audio cd-r cd-rw dvd
                configuration: ansiversion=5 mount.fstype=udf mount.options=ro,n

Hello to all.

I a newbie in ubuntu. I got the same problem about my cd tray.

$ 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://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
hal:
  Installed: 0.5.11-4ubuntu4
  Candidate: 0.5.11-4ubuntu4
  Version table:
 *** 0.5.11-4ubuntu4 0
        500 http://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
$ 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
$ sudo lshw -C disk
  *-cdrom
       description: DVD-RAM writer
       product: CDDVDW SH-S223F
       vendor: TSSTcorp
       physical id: 0
       bus info: scsi@2: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: SB00
       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
  *-disk
       description: ATA Disk
       product: WDC WD800BD-00MR
       vendor: Western Digital
       physical id: 1
       bus info: scsi@3:0.0.0
       logical name: /dev/sda
       version: 10.0
       serial: WD-WMAM9PU32548
       size: 74GiB (80GB)
       capabilities: partitioned partitioned:dos
       configuration: ansiversion=5 signature=000a2217

Here was my Edited 60-persistent-storage.rules
# do not edit this file, it will be overwritten on update

# persistent storage links: /dev/disk/{by-id,by-uuid,by-label,by-path}
# scheme based on "Linux persistent device names", 2004, Hannes Reinecke <email address hidden>

# forward scsi device event to corresponding block device
ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change"

ACTION!="add|change", GOTO="persistent_storage_end"
SUBSYSTEM!="block", GOTO="persistent_storage_end"

# skip rules for inappropriate block devices
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-*|md*", GOTO="persistent_storage_end"

# never access non-cdrom removable ide devices, the drivers are causing event loops on open()
KERNEL=="hd*[!0-9]", ATTR{removable}=="1", DRIVERS=="ide-cs|ide-floppy", GOTO="persistent_storage_end"
KERNEL=="hd*[0-9]", ATTRS{removable}=="1", GOTO="persistent_storage_end"

# ignore partitions that span the entire disk
TEST=="whole_disk", GOTO="persistent_storage_end"

# /sys/class/block will export this
ENV{DEVTYPE}!="?*", ATTR{range}=="?*", ENV{DEVTYPE}="disk"
ENV{DEVTYPE}!="?*", ATTR{start}=="?*", ENV{DEVTYPE}="partition"

# for partitions import parent information
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"

# by-id (hardware serial number)
KERNEL=="hd*[!0-9]", IMPORT{program}="at...

One of the latest updates has fixed this for me, thanks!

Thats a great news, thank you Brion.. I already have the latest udev package i think it was 124.10. Just a while ago I check the udev update from Synaptic Update, no new update yet. I am thinking, would that be because I have a SATA drive?

I'm actually getting this bug every time I open my tray now. What's this I hear about a 124.10 version? I don't see it in proposed....

This bug is REALLY making things difficult for me.

I have also attempted the persistent storage file patch, but it does not work for me.

We'll wait some time for the gurus to check out our problem. Chauncellor, if you check above, Launchpad Janitor talk this on post. Latest package of udev i know was 124.10

my problem still not solve at this moment...im keep trying to look for solution on the internet.

Can some programmer please incorporate a fix as in the following (so we don't have to find and execute these 2 lines at the terminal every time we install Ubuntu) article/link ?

Thanks.

http://mobilevs.blogspot.com/2008/11/ubuntu-intrepid-bugfix-cd-rom-tray.html

wpshooter, udev (124-9) is in intrepid-updates, you shouldn't need to use those two lines.
Just update your PC normally you'll receive it if you have internet.

If not, here's the package:
http://packages.ubuntu.com/intrepid-updates/udev
http://fr.archive.ubuntu.com/ubuntu/pool/main/u/udev/udev_124-9_amd64.deb
http://fr.archive.ubuntu.com/ubuntu/pool/main/u/udev/udev_124-9_i386.deb

Sawas:

Thanks for your reply.

BUT, I still had the problem AFTER applying EVERY update that was available from the Intrepid-updates that are found under software sources.

When I applied the 2 lines shown in the post above the problem was fixed immediately.

Let me also say that I did not have to apply those 2 lines under my old setup when I had a Plextor CD-RW drive in my machine. BUT when I changed the CD-RW drive to a Sony Drive, and after doing a fresh install of Intrepid, I had this problem EVEN AFTER applying all of the updates. I did NOT have this problem when I applied ALL of the updates when I was using the Plextor drive. There appears to me, to still be some little quirky thing here that someone has missed.

Thanks.

> BUT, I still had the problem AFTER applying EVERY update that was
> available from the Intrepid-updates that are found under software
> sources.

Weird, maybe you should provide more information:
- CD/DVD drive brand and model number
- SATA or (P)ATA?

Can you post the current output of this command in terminal:
apt-cache policy udev

Also, can you post the contents of the file
/etc/udev/rules.d/60-persistent-storage.rules in these events:
- After the install of Ubuntu 8.10 Intrepid Ibex, WITHOUT updating anything.
- After the install of ALL intrepid updates (and after the reboots it requires).
- After you apply the changes with the two lines of command you use.

This could shed some light on where the problem actually is.

Dear Savvas:

I solved my problem by issuing 2 commands at the terminal which I found on a thread on the Ubuntu forums.

The problem as described in a blog on the web, says that this is being caused by a "coding error" in some of the Ubuntu programming.

I also posted that fact and I think the link to that thread on another report of this bug on another bug report about this same problem.

Thanks.

I was referring to your initial request:
> Can some programmer please incorporate a fix as in the following (so we
> don't have to find and execute these 2 lines at the terminal every time
> we install Ubuntu) article/link ?

Coding error or not, if you want it confirmed that is not working and
solved, and of course integrated in ubuntu updates, you need to
provide more info. :)

Savvas:

Please let me know what might be needed and how to get it and I will be happy to provide it.

Thanks.

Hi,

As I look for solution on the web, I am looking at this sites:
http://www.avsforum.com/avs-vb/showthread.php?t=1079492
https://bugs.launchpad.net/ubuntu/+source/eject/+bug/280931

Something got in my mind, does it matter if you are a 32bit and 64bit in term of udev update. Or maybe the, the solutions for 32-bit is not applicable for 64-bit.

wpshooter if you read the previous messages with Savvas it says,
"Can you post the current output of this command in terminal:
apt-cache policy udev"

Then this one
Also, can you post the contents of the file
/etc/udev/rules.d/60-persistent-storage.rules in these events:
- After the install of Ubuntu 8.10 Intrepid Ibex, WITHOUT updating anything.
- After the install of ALL intrepid updates (and after the reboots it requires).
- After you apply the changes with the two lines of command you use.

We would be happy to see the result. Maybe we could get some clue their for my cd-tray was still not fixed.

> We would be happy to see the result. Maybe we could get some clue their
> for my cd-tray was still not fixed.

Exactly my point, we could see the difference between each step of the
way, and take a look at the problematic areas of udev that didn't get
fixed (and compare them with the fix that was provided).

Dear jt:

Here is the result of running that command in terminal:

udev:
  Installed: 124-9
  Candidate: 124-9
  Version table:
 *** 124-9 0
        500 http://archive.linux.duke.edu intrepid-updates/main Packages
        100 /var/lib/dpkg/status
     124-8 0
        500 http://archive.linux.duke.edu intrepid/main Packages

However, I don't exactly understand that second part of your request. Are you saying that the contents of the storage-rules file as it stands right now will give you a trail of ALL of the events that you want to see or are you wanting me to capture the contents of that file after each of the 3 stages that you list, which if I am understanding this correct would require me to do a complete reinstallation of Intrepid from scratch. If that is the case, then I might be willing to take my CD drive out of the machine that I have the installation on now and move it to another very similar machine that I have yet to get installed and try it on that one. I don't want to risk messing up the configuration I have on this machine (I have worked too long to get it working just like I want it). Let me go on to say that I think this problem with the CD ejection not working correctly is dependent on the brand/type of drive that is being used in the machine. I say that because when I first did the installation on the machine that I am typing this on now (my main machine) that I had another brand of CD-RW drive in the machine and when I did the Ubuntu install with that brand drive in the machine I did not have the problem once I had applied all of the Ubuntu updates. But then after doing that installation, I decided to change some of the hardware in this machine and one of those was to take that brand CD-RW out of the machine and replace it with another which I consider to be a more desirable drive. And when I did that, when I reinstalled the O/S with this other brand of CD-RW in the machine that I had the problem that was not resolve by just installing all of the updates but I had to indeed run the 2 commands that I found in a post on the Ubuntu forums.

Let me know if you want me to reconfigure the other machine and I will give it a try when I get a chance but IT MAY BE A WHILE.

Thanks.

I would like to remind you all that even with the latest updates, my problem still persisted. I've been away from my machine since Dec. 7, so I haven't had a chance to look into that link that was posted a few posts up. Otherwise, things were rolling just the way they were with the latest udev updates (back in, of course!)

hello wpshooter thanks for posting the resutl. i am a also a newbie in ubuntu, lets wait what savvas could help for he ask this one. and i am sorry you are right of what you think. anyway just stay put i knew help will be on the way.

like chauncellor, problem still persist on me :) hope we'll got a good new year start once this will be solved

wpshooter, I'm not an official member of Ubuntu or representing any Ubuntu-group opinion.

Those three steps will show what changes will be made without the updates, with the updates and with the two commands you used from that website. My opinion is that this can greatly help and give the developers/maintainers at least a clue to where the problem actually is.

As you said, doing those two commands fixed your problem, so something extra was changed with that command (as sed had the "g" option which means to repeatedly replace that piece of text), something that the current command didn't catch.

As a suggestion, you could install Ubuntu on another hard drive (and disconnect all other hard drives) on the same machine, which wouldn't change anything on your original hard disk and you don't have to mess up your settings.

Anyone still facing the problem should attempt to provide the same information:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/283316/comments/107

Every step of the way you should check if your CD/DVD works and does not retract (loads back in) when you press the eject button.

Try with and without a CD/DVD media in the drive.

hi to all,

I try to edit /etc/udev/rules.d/60-persistent-storage.rules and change the line
FROM
# 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"
ENV{DEVTYPE}=="disk", KERNEL=="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

TO
# 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"
ENV{DEVTYPE}=="disk", KERNEL=="sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"

It worked for some people but not for me. wpshooter mention on his post, does the brand and type of device I think matters. Unfortunately I dont have spare device here to test my doubts..to who ever had a spare drive and have same problem with us, can you change your drive and see if the problem will be solved. change the drive to other brand :)

Thank you in advance! :)

Can you (wpshooter and jtraifalgar) mention the brand and model of your drive?
I think that you never actually replied to that question

I had this problem with my IDE drive, a GSA-4167B by LG, when I first installed Intrepid. It went away after one of the updates, but not the same updates others reported at the time. I have since replaced this with an ASUS SATA drive. When I did this, the problem returned more consistently. It was much more of a problem because this drive's tray moves more quickly! One of the updates about 1-2 weeks ago seems to have fixed this for now.

So I have used two different brands of drive with two different interfaces. Hope this has helped by adding to anecdotal evidence.

I've still got a the problem with proposed enables (and upgraded). It did solve the closing when no disk was present, but when a disk was mounted it got closed right after opening. The fix thtat workes was to add

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

in line 55 of /etc/udev/rules.d/60-persistent-storage.rules. Now it looks like this:

 53 # skip unpartitioned removable media devices from drivers which do not send "change" events
 54 ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
 55 ENV{DEVTYPE}=="disk", KERNEL=="sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
 56 # skip optical drives without media
 57 ENV{DEVTYPE}=="disk", KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}!="?*", GOTO="persistent_storage_end"

My drive is a (P)ATA drive from Samsung:
product: DVD-ROM SH-D162D
vendor: TSSTcorp

I'm on Intrepid 32bit with udev 124-9.

In the end I collapsed all three lines to

ENV{DEVTYPE}=="disk", ATTR{removable}=="1", GOTO="persistent_storage_end"

which seems to solve the problem too. (Proposed by Livid https://bugs.launchpad.net/ubuntu/+source/udev/+bug/283316/comments/49)

HTH,
Michael

Sorry, I missed the request for drive brands/types.

Both of my drives are CD-RWs - IDE. And both are 52x32x52x. I updated the firmware on both of these drives fairly recently.

The one that is problematic as far as ejection with Intrepid is a Sony model CRX230ED. However, if my memory serves me correctly, I believe that this drive was probably actually manufactured by Lite-on.

The one that is NOT problematic as far as ejection with Intrepid is a Plextor model PX-W5224TA.

I also have a Lite-on CD-RW drive in another older computer, also 52x32x52x and I have noticed that that one also exhibits the CD ejection problems with the Ubuntu O/Ss.

I think I may be seeing a pattern here. And this really does not surprise me, because it seems that most every time that I have some problem related to a CD drive that it is a model that has been manufactured by Lite-on !!!

hello savvas,

I mentioned my drive on my earlier post but for your convenience, it was samsung SH-S223 Serial SATA DVD Writer 22x Super Write Master.

To who ever got the problem solved may be it was good to let us know what are the drives and brands that fix the problem after the persistent storage file was edited. That way we could generalized some things.

ooppsss sorry i forgot.. i had 64-bit ubuntu 8.10. maybe this also matters..

wpshooter and chancellor, does your ubuntu system was a 32bit one or 64 bit?

Re-opening the bug - 4 people still facing cd retraction (Intrepid amd64 and i386).

currently i just rebooted after i tried what mihi posted but no good, still got the problem..

I'm 32 bit with the generic kernel.

I don't remember exactly what my drives are, but I can tell you that they are both IDEs - One is a DVD writer, one's just a run-of-the-mill CD reader. Both are stocks from an HP Pavilion a730n (literally the only things I haven't replaced in that computer yet!). The DVD writer is in fact a Lite-on. Perhaps this is only affecting that type?

I installed Wubi on the Windows machine I'm using now using a livecd installer from when Intrepid first came out and the problem was there. I installed udev 124-9 and the problem immediately disappeared. One drive was a TDK DVD writer and the other an HP DVD writer.

I'll be back at my box on Tuesday, ready to assist further if need be.

All of my machines are 32 bit. I am using Intrepid.

My ASUS SATA drive model is DRW-20B1LT, using 32-bit Intrepid.

Well, I'm back at my computer, and I haven't had the problem yet anymore. I had all the updates applied first thing when I booted it up. New kernel fix, maybe....?

I didn't even think about this bug until a few hours later!

Any info you want me to give?

Okay, I lied. It's still there.... for some reason it hadn't done it for a long time (even with CDs being in there previously), but I've been installing a two-disc program under Virtual Box and it's been retracting every single time.

I get a lot of this when I eject (all of these did not retract):

$ sudo eject -v cdrom1
eject: device name is `cdrom1'
eject: expanded name is `/dev/cdrom1'
eject: `/dev/cdrom1' is a link to `/dev/scd1'
eject: `/dev/scd1' is mounted at `/media/cdrom1'
eject: unmounting device `/dev/scd1' from `/media/cdrom1'
eject: `/dev/scd1' is not a multipartition device
eject: trying to eject `/dev/scd1' using CD-ROM eject command
eject: CD-ROM eject command failed
eject: trying to eject `/dev/scd1' using SCSI commands
eject: SCSI eject succeeded

I attached my current /etc/udev/rules.d/60-persistent-storage.rules file.

Anything I can do?

All of you affected, please set your "this bug affects me" to "Yes":
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/283316/+affectsmetoo

Hello everyone,

I vote "Yes" to the link Radevic had given. Thanks. Hope this will be fixed soon.

Ever since I got back the bug has only happened during that wine install. I've been constantly putting my hand out to catch the CD tray, but it doesn't retract any more. All I've done is apply the slew of updates that I had when I came back.

But it did it non-stop with that program.

well, for me as i remember I got this problem even after ubuntu 8.10 fresh installation :). would it be a symptom of another problem. mayb the problem was somewhere else, not just the "persistent" file. I always keep tracking and updating but as of now its still there, catching the cd tray.

I still have this problem after applying all the Intrepid recommended updates, including udev-124-9

ii udev 124-9 rule-based device node and kernel event mana

This is the drive I am using:

           *-cdrom
                description: DVD writer
                product: DVDRW SHW-1635S
                vendor: LITE-ON
                physical id: 0.1.0
                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: YS0N
                capabilities: removable audio cd-r cd-rw dvd dvd-r
                configuration: ansiversion=5 status=ready
              *-medium
                   physical id: 0
                   logical name: /dev/cdrom

If the drive is empty when I eject it will then stay open, if the drive has a disc in when I eject, it will immediately close. Problem occurs no matter how I eject (using the button, right clicking on the desktop icon, or typing eject with any of the device names shown above).

However, making this change followed by sudo kill -HUP $(pidof udevd) seems to do the trick:

--- backups/60-persistent-storage.rules 2009-01-25 19:14:33.000000000 +0000
+++ /etc/udev/rules.d/60-persistent-storage.rules 2009-01-25 19:14:45.000000000 +0000
@@ -51,7 +51,7 @@
 ENV{DEVTYPE}=="partition", ENV{ID_PATH}=="?*", SYMLINK+="disk/by-path/$env{ID_PATH}-part%n"

 # 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"
+ENV{DEVTYPE}=="disk", KERNEL=="sd*|sr*", ATTR{removable}=="1", GOTO="persistent_storage_end"
 # skip optical drives without media
 ENV{DEVTYPE}=="disk", KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}!="?*", GOTO="persistent_storage_end"

Correction: the problem has not been resolved by editing the udev rules, as I said in the preceding comment.

Initially it appeared to work, however after another 3 or 4 ejects it started to immediately close the drive tray after ejecting. (I'm in the process of ripping my entire CD collection).

This bug has a lot of subscribers, and it is fixed for most of them. So let's not spam all those with the remaining corner cases.

If you still experience it, please open a new one, subscribe "pitti" to it, and do the following things:

 * Open a terminal and run "sudo udevadm monitor --udev 2>&1 | tee /tmp/udev.log". Then reproduce the problem by inserting/ejecting CDs. Attach /tmp/udev.log to that new bug afterwards.

 * Do "sudo /etc/init.d/hal stop" and check whether you still can reproduce the problem. Do "sudo /etc/init.d/hal start" to bring system into normal state again after the test.

hello,

Got busy to check back here.. Did someone subscribe or create a new one? Do we have link to it?

Thank you to all

Martin Pitt,
I ran the commands to stop and start HAL. With HAL stopped my tray will stay out when ejected, with HAL running my tray goes out and right back in when ejected.

I have an LG GH22NS30 SATA DVD burner. The drive firmware is a the current version. I have applied all the udev fixes mentioned with no success. I also cannot burn DVD's successfully but I can play DVD's and read and burn CD's.

I came across a thread on Ubuntu Forums from 06/12/08 which suggested adding "all_generic_ide" to the end of the kernel line in /boot/grub/menu.lst to resolve a SATA drivers issue. This fixed my tray issue and allowed me the burn DVD's but my drive transfer rates dropped.

Hi, Martin

I reviewed this forum again and check what had you suggested with "sudo /etc/init.d/hal start" and "sudo /etc/init.d/hal stop" the automatic close of my cd tray upon openning was solved. Its just that I should have do this all the time hehehehe to close open my cd tray. Thanks a lot!

navsnipe,

I am interested with the solution how you fixed it. Could you point where that thread was? I paste the "all_generic_ide" at the last kerner line at the /boot/grub/menu.lst then reboot. Then I tried the cdtray closes after I opened it. Martin's solution was good but you have to type the command at the console always. Like to see how the menu.lst was modified. Thank you very much in advance

Well, I later found out that the CD tray is a defect. And I brought it to
the repairman and fixed it. It was a hardware problem. Sorry about the late
reply because from my busy school.

On Fri, Mar 6, 2009 at 5:48 PM, jtraifalgar <email address hidden> wrote:

> navsnipe,
>
> I am interested with the solution how you fixed it. Could you point
> where that thread was? I paste the "all_generic_ide" at the last kerner
> line at the /boot/grub/menu.lst then reboot. Then I tried the cdtray
> closes after I opened it. Martin's solution was good but you have to
> type the command at the console always. Like to see how the menu.lst was
> modified. Thank you very much in advance
>
> --
> CD-ROM tray closes automatically after eject
> https://bugs.launchpad.net/bugs/283316
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Invalid
> Status in Ubuntu Release Notes: Fix Released
> Status in “linux” source package in Ubuntu: Invalid
> Status in “udev” source package in Ubuntu: Fix Released
> Status in linux in Ubuntu Intrepid: Invalid
> Status in udev in Ubuntu Intrepid: Fix Released
> Status in “udev” source package in Fedora: In Progress
> Status in Gentoo Linux: Fix Released
>
> Bug description:
> Binary package hint: hal
>
> Ubuntu intrepid ibex beta (updated)
>
> Problem:
> When I try to eject a cd/dvd, Ubuntu intrepid inserts the cdrom right back
> in the cd/dvd drive
>
> Steps to reproduce:
> 1) Either by pressing eject button on the device or using the "eject"
> command or using the eject icon in nautilus sidebar
> 2) The dvd is ejected successfully
> 3) The dvd is loaded back in right after being ejected. This happens after
> the message "eject: CD-ROM eject command succeeded" of "eject -v" command.
>
> Note 1: The cd/dvd-rw drive is a SATA device
> Note 2: This happens while in tty and ubuntu gnome desktop manager
>
> $ 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://archive.ubuntu.com intrepid/main Packages
> 100 /var/lib/dpkg/status
> hal:
> Installed: 0.5.11-4ubuntu2
> Candidate: 0.5.11-4ubuntu2
> Version table:
> *** 0.5.11-4ubuntu2 0
> 500 http://archive.ubuntu.com intrepid/main Packages
> 100 /var/lib/dpkg/status
>
> $ 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 mounted at `/media/cdrom0'
> eject: unmounting device `/dev/scd0' from `/media/cdrom0'
> 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
>
> $ sudo lshw -C disk
> [...]
> *-cdrom
> description: DVD-RAM writer
> product: DVD-RW DVR-212
> vendor: PIONEER
> physical id: 0.0.0
> bus info: scsi@2: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
> logical name...

This bug seems to affect my fully up to date Jaunty (9.04) 64-bit system using Grip - the CD will not eject so Grip stays in a loop continually ripping the same CD. Never experienced it on my previous 8.04 setup.

I, too, have had this bug affect me on my Jaunty system. I haven't had updates (no internet, and this isn't my computer) for about two-three weeks, but with my fully up-to-date system a few weeks ago, my top drive worked just fine, but my bottom drive continually retracted back in after ejecting. Both are dumpy little OEM drives.

Using generic Jaunty 32-bit

I will also comment that I was using RipperX to rip some CDs, and that it was a fresh install, not an upgrade (For ext4)

My bottom drive is still affected by this bug - if I eject when a CD was present, it will retract. I never use the drive, but it's still there.

The drive is an ASUS CD-S480/AH. A crummy little stock drive.

I chanced across a drive that someone else was throwing away.

I'm going to throw the ASUS out as the bug seems to not affect anyone else. My new drive is not affected. Perhaps it was a hardware issue.

Before you throw the drive away, have you verified that the ASUS drive has the latest and greatest FIRMWARE (not to be confused with drivers) installed on it ?

I didn't check because there was only one update on Asus' site for the firmware, and it was released in 1999. The drive came from a computer that is from 2004, so I'd assume that it has the latest.

This bug is alive and well in Karmic

dvd tray does not stay open

Karmic alternative cd cut 12th Oct 2009. Completely new install on all new hardware. CD drive as follows:

*-cdrom
       description: DVD-RAM writer
       product: CDDVDW SH-S223B
       vendor: TSSTcorp
       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
       logical name: /media/cdrom0
       version: SB01
       capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
       configuration: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted status=ready
     *-medium
          physical id: 0
          logical name: /dev/cdrom
          logical name: /media/cdrom0
          configuration: mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted

The last time I had this problem was with Intrepid. I have a similar AMD64 Karmic rig running updated from Jaunty and the problem (with the same disk - a similar Samsung - and new at the time) does NOT occur.

So is it the new install and something to do with the Ubuntu.iso file or is something to do with new Samsung dvd drives? .iso files would be my guess. Any .iso files the same in Intrepid as they now are in Karmic?

 I believe that these problems involving CD drive ejection are drive
brand specific. Is the FIRMWARE (not to be confused with driver) on
your CD device on the latest version available ?

 I just installed the latest daily build 10-12-2009 (alternate) of
Karmic on an older machine of mine and the CD ejection functions fine.

On Mon, 2009-10-12 at 17:24 +0000, bwallum wrote:
> This bug is alive and well in Karmic
>
> dvd tray does not stay open
>
> Karmic alternative cd cut 12th Oct 2009. Completely new install on all
> new hardware. CD drive as follows:
>
> *-cdrom
> description: DVD-RAM writer
> product: CDDVDW SH-S223B
> vendor: TSSTcorp
> 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
> logical name: /media/cdrom0
> version: SB01
> capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
> configuration: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted status=ready
> *-medium
> physical id: 0
> logical name: /dev/cdrom
> logical name: /media/cdrom0
> configuration: mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,utf8 state=mounted
>
> The last time I had this problem was with Intrepid. I have a similar
> AMD64 Karmic rig running updated from Jaunty and the problem (with the
> same disk - a similar Samsung - and new at the time) does NOT occur.
>
> So is it the new install and something to do with the Ubuntu.iso file or
> is something to do with new Samsung dvd drives? .iso files would be my
> guess. Any .iso files the same in Intrepid as they now are in Karmic?
>

I have a SATA Pioneer DVR-216 that was working correctly under a Jaunty based mythbuntu.
The mythbuntu Karmic beta has this bug with this drive.

Firmware is 1.06 (current), patched to RPC1 as described at
http://forum.linuxmce.org/index.php?topic=4090.msg42569#msg42569

I had another IDE Samsung drive in an external USB enclosure (both died this year) that had this problem when Intrepid was first released but became good after an ubuntu update. That drive was also patched to RPC1.

I have the same issue with Karmic. It was ok with Jaunty.

SONY DVD RW DW-U21A

Power G5

Probably the bug should be reopen?

I don't have the problem with my new drives, but three people having the problem (to me) means that the bug should be reopened to further inspection

Hi,

just want to report that I have this issue also now in Karmic. Was fine in Jaunty.

Best regards,
schaze

Hi,

I just played around with it a bit and found temporary workaround:

I installed setcd and with this tool one can set the auto open/close flag (no idea why such a thing even exists)

Appearantly Karmic sets the Auto close tray flag (for me after each reboot)
$ setcd -is
/dev/cdrom:
  Auto close tray: set
  Auto open tray: cleared
  Use O_NONBLOCK flag: set
  Lock tray: set
  Check CD type: cleared
  Drive is not ready

If I execute the following to clear the flags:
$ setcd -e 0
/dev/cdrom:
  Auto close tray: cleared
  Auto open tray: cleared

The problem is solved until the next reboot.
So one needs to check where and why this flag is set - if this is the general problem and not only valid for me of course.

/schaze

sudo sysctl -a | grep cdrom

You should be able to set up a permanent override using sysctl.

The workaround with sysctl works perfectly!

sudo sysctl -w dev.cdrom.autoclose=0

Hi Guys,

I tried the sysctl command but it also gets reset after a reboot.
I think maybe this is done by something else.
Is there a way to track down changes to these properties in sysctl?

I am running a mythbuntu installation -- maybe mythtv is setting this, I remember an old bug from a year ago that caused automatic closure (not sure if this was due to the autoclose or due any kind of polling though)

Do you think we should open a new bug for Karmic for this issue? This one is so old and long that I don't think it will get any attention?

/schaze

sudo cat > /etc/sysctl.d/60-cdrom-autoclose.conf
# do not autoclose cdrom
dev.cdrom.autoclose = 0

But this is really workaround, that must be fixed somewhere in proper place

Hi Sergey,

thanks for the tip! But that also still doesn't fix it for me... which makes no sense.
I really think this could be related to mythtv somehow. I will open up a new bug for mythbuntu and have that traced there.

Can somebody else who has also reported this issue please also check and confirm if it is working for them? (and also please state which distribution you are running)

Many thanks,
schaze

Comment #160 fixed the problem for me in Ubuntu 9.10 with a Samsung DVD-RW drive. Why would anybody want their drive to auto-close??

Gee, why do the Ubuntu packagers break these things all the time?

Kubuntu 9.10 AMD64, recent upgrades, KDE 4.4, I have the same problem.

THIS IS NOT FIXED in Karmic!

sudo sysctl -w dev.cdrom.autoclose=0 works and solves this for me.

DVD writer is a NEC DVD_RW ND-4550A.

Apparently this was fixed in Karmic with upgrades of the last two days. I have to take back my previous statement, sorry.

I still have this bug. The 'systcl' command doesn't work for me.
Drive: TSSTcorp CDDVD SH-S203N
Distro: 9.10

The sysctl command worked, but I _want_ my drive to auto close the way it used too. Is there a way I can trace who(what application) is messing with my drive?

I've stopped udev, I stopped hal, I stopped nautilus. Still the drive closes, this indicates that some applications is opening the device?

I'm concerned about extra IO interfering with disk burns.

I have also experienced CDs reloading immediately after ejecting on my 10.04 beta setup.

This doesn't happen all of the time, in fact it seems to work correctly for a period after a reboot and then gets stuck in this mode.

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.