CD-ROM tray closes automatically after eject

Bug #283316 reported by Savvas Radevic on 2008-10-14
686
This bug affects 114 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Medium
Release Notes for Ubuntu
Undecided
Colin Watson
Gentoo Linux
Fix Released
Medium
linux (Ubuntu)
Undecided
Unassigned
Nominated for Lucid by Paul Sinnett
Intrepid
Undecided
Unassigned
udev (Fedora)
Won't Fix
High
udev (Ubuntu)
High
Unassigned
Nominated for Lucid by Paul Sinnett
Intrepid
High
Martin Pitt

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: /media/cdrom0
       version: 1.21
       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

description: updated

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

Savvas Radevic (medigeek) wrote :

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

Changed in hal:
assignee: nobody → desktop-bugs
status: New → Confirmed
Graham Hawkins (grahamhawkins) wrote :

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

VladimirCZ (vlabla) wrote :

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.

blaked27 (brwindow) wrote :

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

Martin Pitt (pitti) wrote :

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.

Changed in hal:
assignee: desktop-bugs → pitti
importance: Undecided → High
milestone: none → ubuntu-8.10
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

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.

Martin Pitt (pitti) wrote :

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.

Changed in hal:
assignee: pitti → nobody
status: In Progress → Triaged

CDROM_DISC_STATUS does the same.

Changed in linux:
status: Unknown → Confirmed

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,

Matthias Urlichs (smurf) wrote :

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.

Changed in linux:
status: Confirmed → In Progress
Matt Zimmerman (mdz) wrote :

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.

Matt Zimmerman (mdz) wrote :

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?

Matthias Urlichs (smurf) wrote :

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.

Martin Pitt (pitti) wrote :

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.

Pete Graner (pgraner) wrote :

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.

Matt Zimmerman (mdz) on 2008-10-23
Changed in linux:
milestone: ubuntu-8.10 → intrepid-updates
Martin Pitt (pitti) wrote :

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()

markor (markoresko) wrote :

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

Michael B. Trausch (mtrausch) wrote :

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.

Steven Rose (steveydoteu) wrote :

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.

arvidgibas (arvidgibas) wrote :

I can confirm problem.

OS: Intrepid Ibex 8.10 64bit

warptoy (warptoy) wrote :

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...

Ugnichenko Dmitriy (fukazzz) wrote :

Confirm the same problem.

OS: Intrepid Ibex 8.10 64bit

Raymond (raymond-m) wrote :

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

Ozan Çağlayan (ozan-pardus) wrote :

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.

Changed in ubuntu-release-notes:
assignee: nobody → kamion
status: New → Fix Released
thebigbluecan (thebigbluecan) wrote :

Same here on the RC and on the Final.

gray (info-graydesigns) wrote :

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.

Savvas Radevic (medigeek) wrote :

> 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

Changed in udev:
status: Unknown → Fix Released
Martin Pitt (pitti) on 2008-11-03
Changed in linux:
milestone: intrepid-updates → none
Martin Pitt (pitti) on 2008-11-03
Changed in udev:
assignee: nobody → pitti
status: Triaged → In Progress
Martin Pitt (pitti) on 2008-11-03
Changed in udev:
milestone: intrepid-updates → none
status: In Progress → Fix Committed
Martin Pitt (pitti) on 2008-11-04
Changed in linux:
status: New → Invalid
status: New → Invalid
Changed in linux:
status: In Progress → Invalid
Changed in udev:
status: Triaged → Fix Released
Martin Pitt (pitti) on 2008-11-10
Changed in udev:
status: Fix Committed → Fix Released
Changed in udev:
status: Fix Released → In Progress
Changed in udev:
status: Fix Released → Confirmed
Martin Pitt (pitti) on 2009-01-27
Changed in udev:
status: Confirmed → Fix Released
126 comments hidden view all 206 comments
David Clayton (dcstar) wrote :

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).

Mark Fraser (launchpad-mfraz) wrote :

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.

Umang Varma (umang) wrote :

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

Paul Sinnett (paul-sinnett) wrote :

Also getting this on Lucid

Paul Sinnett (paul-sinnett) wrote :

sudo sysctl -w dev.cdrom.autoclose=0

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

Leonardo (diazleonardo) wrote :

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

TGP1994 (tgp1994) wrote :

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

Mark Fraser (launchpad-mfraz) wrote :

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.

TGP1994 (tgp1994) wrote :

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.

Robbie Williamson (robbiew) wrote :

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.

Robbie Williamson (robbiew) wrote :

@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

TGP1994 (tgp1994) wrote :

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

Anyhow, I'll subscribe you to my issue.

Alan (avhennessy) wrote :

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

Changed in gentoo:
importance: Unknown → Medium
Changed in linux:
importance: Unknown → Medium
Mike Mestnik (cheako) wrote :

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.

tags: added: iso-testing
Erick Brunzell (lbsolost) wrote :

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?

Erick Brunzell (lbsolost) wrote :

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

Erick Brunzell (lbsolost) wrote :

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 ;^)

Erick Brunzell (lbsolost) wrote :

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 ;^)

Erick Brunzell (lbsolost) wrote :

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

How ticked off would you be?

Brian Murray (brian-murray) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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!

Jeremy Bicha (jbicha) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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 :^(

Erick Brunzell (lbsolost) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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.

Erick Brunzell (lbsolost) wrote :

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

sojourner (itsmealso2) wrote :

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 .

Erick Brunzell (lbsolost) wrote :

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

Argyle (kruegejj) wrote :

Problem still exists in Ubuntu 11.10.

Alan (avhennessy) wrote :

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?

Oliver R. (oliverr) wrote :

Problem exists in Kubuntu 12.04.

Same problem in Kubuntu 12.04

Pilot6 (hanipouspilot) wrote :

Same bug in Ubuntu 12.04

Shock (mmiron) wrote :

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?

Jussi (jussi-lahtinen-gmail) wrote :

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

Changed in udev (Fedora):
importance: Unknown → High
status: In Progress → Won't Fix
Displaying first 40 and last 40 comments. View all 206 comments or add a comment.