Bug 453095

Summary: Cd tray is closed automatically after ejecting
Product: [Fedora] Fedora Reporter: Lester <lester.dev>
Component: udevAssignee: udev-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 14CC: andre.ocosta, b.bellec, bdm, bloch, bryan.christ, bugzilla-redhat, cepreu.mail, chkr, cia.watson, covex, cpanceac, cqbkaju, davej, daw-redhatbugzilla, db, dennett, dennisml, dougmencken, dstolte, fedora-bugzilla-odin, fedoration, fenlason, fred_wells, hugh, jik, john5342, john, jonstanley, jsacco, kdudka, keith, kvikende, leamas.alec, legionnaire24, lex.lists, lfelipebm, matt.proud, michael.monreal+bugs, morgoth6, neil_stelzer, oliver.henshaw, panub80, pascal.schott, peter.feerick, peter, phil.ingram, projects.rg, redhat.cm, robatino, robertobech, rtguille, rvokal, s.adam, s.a.hartsuiker, skarllot, stephent98, steve.rotolo, the.masch, thieme.reis, tomek, tomg68, tparker, udovdh, webmaster, wierdlmate, zenczykowski
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: udev-145-21.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 18:21:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
patch for /etc/udev/rules.d/60-persistent-storage.rules (workaround)
none
udevmonitor output
none
udev debug messages from /var/log/messages when pressing eject button none

Description Lester 2008-06-27 04:46:36 EDT
Description of problem:
When a cd-disk is mounted, any attempt to eject the media leads to the immediate
tray closing.

Version-Release number of selected component (if applicable):
0.5.11

How reproducible:
Allways

Steps to Reproduce:
1. Insert a media, wait it to be mounted
2. Click eject in the context menu, shown on a media icon
3. Use a button on dvd-drive
  
Actual results:
A tray is closed immediately without waiting a user to take a media

Expected results:
A tray stays opened 

Additional info:
My lspci, just in case:
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
03:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1)
Comment 1 Marcin Kurek 2008-06-29 15:56:58 EDT
I can observe same problem here on two machines (64bit install, F9) It never
happend if the tray was empty, but almost always if there was a CD/DVD mounted
before eject.

If you need any more specyfic info just ask.
Comment 2 Torsten Rausche 2008-07-02 11:59:39 EDT
I can confirm this bug. It is reproducible with the eject command too.

$ eject /dev/dvd1

With an unloaded drive the tray opens and stays open.
With a loaded drive the tray opens and closes immediately.

$ rpm -q hal
hal-0.5.11-2.fc9.x86_64

This is with an up to date F9 x86_64 installation and two optical drives
connected to the following controller:

00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2)
Comment 3 Torsten Rausche 2008-07-02 13:23:05 EDT
Looks like this is the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=451320
Comment 4 pobbz 2008-07-06 11:57:14 EDT
I can confirm this bug also. However, while in the login screen, before logging
in to GNOME, I can eject the disc by pressing the eject button on the drive, or
logging in to console and doing "eject".Thus it seems that this has something to
do with how GNOME handles ejecting of mounted discs. Also note that, when logged
in to GNOME, if I summon up a console and unmount the disc with the command
"umount", I can then eject the disc (by pressing the eject button on the drive,
or by calling "eject" in console window).
Comment 5 Torsten Rausche 2008-07-07 05:47:37 EDT
(In reply to comment #4)

I just tried the eject command in runlevel 3 (no X) and the tray got closed
immediately again too. So I think this is not related to GNOME.
Comment 6 pobbz 2008-07-07 06:00:56 EDT
(In reply to comment #5)
> (In reply to comment #4)
> 
> I just tried the eject command in runlevel 3 (no X) and the tray got closed
> immediately again too. So I think this is not related to GNOME.

Yes, you are right, I was hasty in my conclusions. It has to do with whether the
disc in the drive is mounted or not. Regardless of whether one ejects the disc
from GNOME, text console or by pressing the button on the drive. Also, I think
this is not specific to the nVidia's IDE controller the two other guys seem to
have as mine in one of VIA's:

IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC
Bus Master IDE (rev 06)
Comment 7 Torsten Rausche 2008-07-07 06:18:16 EDT
(In reply to comment #6)

> Also, I think
> this is not specific to the nVidia's IDE controller the two other guys seem to
> have as mine in one of VIA's:
> 
> IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC
> Bus Master IDE (rev 06)

That's good to know. It's one more evidence for seeing the culprit in the
Hardware Abstraction Layer. Does anybody know if GNOME/nautilus and the eject
command both depend on HAL for ejecting a medium?
Comment 8 pobbz 2008-07-07 06:33:11 EDT
This is very strange: I inserted a DVD in the drive. GNOME mounted it
automatically. Then went to text console (Ctrl+Alt+F1), logged in as root, and
issued the command: "umount /dev/sr0" followed by the command "eject". To my
surprise, the tray popped open and then closed immediately!

And now follows the strange part. "ls -la" in my home directory shows the
following line:

d?????????  ? ?      ?          ?                ? .gvfs

Notice the question marks, right? Now I can't cd into the directory .gvfs, nor
can I remove it! 

Also, "mount" shows the line:

gvfs-fuse-daemon on /home/pobbz/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,user=pobbz)

I earlier said that the disc can be ejected if it's unmounted first. This
assertion was based on the experiment where I unmounted the disc by using the
mount point as the argument to "umount" (the mount point was a directory under
/home/pobbz/.gvfs/). However, now it seems that if the disc is unmounted by it's
device name, it really confuses GNOME's automounting system...

I'm very confused here.
Comment 9 Torsten Rausche 2008-07-07 06:41:15 EDT
I looked at the RPM dependencies. It seems that nautilus uses eject and eject
only depends on libc. But HAL's drive polling interferes in the process. I
disabled the polling for my DVD drive using the hal-disable-polling command and
now the tray stays open. The downside of this workaround is that a disk won't
get mounted automatically.
Comment 10 Zdenek Prikryl 2008-07-08 03:51:31 EDT
*** Bug 454147 has been marked as a duplicate of this bug. ***
Comment 11 Tomáš Bžatek 2008-07-14 06:52:50 EDT
*** Bug 455110 has been marked as a duplicate of this bug. ***
Comment 12 Tomáš Bžatek 2008-07-14 06:59:06 EDT
Answer to Comment #8:

~/.gvfs/ directory is mountpoint of gvfs-fuse-daemon which has nothing to do
with mounting. It simply makes the active gvfs mounts (remote filesystems)
available to other applications. For security reasons, you shouldn't see
contents and cannot stat the mount under different user, that's the way it's
designed. Question marks in ls output are fine.
Comment 13 Christian Krause 2008-07-14 16:10:57 EDT
this bug is related to bug 451320:

it looks like that the problem is caused by the update of udev (from udev-120 to
udev-124) - the problem does not happen if udev-120 (F9 udev release version) is
used... I'll associate both bugs...
Comment 14 Bryan Christ 2008-07-17 11:46:05 EDT
I too have this problem.  I have several times almost damaged my DVD media and
my drive trying to quickly grab it out of the tray.
Comment 15 Bryan Christ 2008-07-17 11:47:14 EDT
Changed severity to high because of the risk of damaging hardware or media.
Comment 16 Fabrício Godoy 2008-07-18 08:58:31 EDT
An easy (temporary) workaround is eject media and when the drive is closing
press eject button, on this way the drive eject again and not close automatic,
maybe because the media is not mounted after second eject.
I tested this on my LG and SONY drives.
Comment 17 Lester 2008-07-18 15:03:56 EDT
(In reply to comment #16)
> An easy (temporary) workaround is eject media and when the drive is closing
> press eject button, on this way the drive eject again and not close automatic,
> maybe because the media is not mounted after second eject.
> I tested this on my LG and SONY drives.

Thanks, works fine for me. Why didn't I come to this solution by myself before?
Comment 18 Don Seiler 2008-07-18 23:35:38 EDT
Thank GOD I found this bug.  I was going crazy.  And thanks Fabricio for the
suggested workaround.

I didn't want to try my ninja like reflexes at trying to snatch the discs out of
the tray.  I figured I'd end up putting my fist through the tray and snapping it
off completely.

Looking forward to a fix.
Comment 19 Adam Pribyl 2008-07-21 13:21:20 EDT
Pretty annoying. I thought that just my DVD driver is somehow strange, but I see
the problem is not in the drive.
Comment 20 Andre Costa 2008-07-21 19:57:10 EDT
Yes, *very* annoying. I hope this gets fixed soon, my cd-rom drive is pretty
useless on Linux as it is.
Comment 21 D. Wagner 2008-07-24 18:39:48 EDT
I can confirm that I too have this bug (i386, F9, fully updated).  Let me know
if you'd like any detailed information to help track this down.
Comment 22 Roberto Bechtlufft 2008-07-25 14:30:46 EDT
Press eject to open the tray. It will close. Press eject again and it will stay
open, and there willl be no need to be a ninja :-)
Comment 23 Andre Costa 2008-07-25 15:47:22 EDT
(In reply to comment #22)
> Press eject to open the tray. It will close. Press eject again and it will stay
> open, and there willl be no need to be a ninja :-)

Surely it's a workaround -- but be aware that you're doubling the chances of
screwing the eject button by using it twice for the same operation ;-)
Comment 24 Adam 2008-07-25 22:32:04 EDT
Confirmed on pressing of eject button for both DVD drives. Only occurs when
media is in tray. When empty it will stay open.
In reply to above: Drive tray will re-close no matter how many times eject
button is pushed.

udev: udev-124-1.fc9.2.i386 
drive: Sony DVD±RW DW-D22A
drive: Samsung DVD-ROM SD-616E
kernel: 2.6.25.10-86.fc9.i686
os: Fedora 9
Comment 25 Lester 2008-07-26 01:37:09 EDT
> Press eject to open the tray. It will close. Press eject again and it will stay
> open, and there willl be no need to be a ninja :-)

Thanks for the workaroung, but this is damn annoying anyway. C'mon guys, can
anybody look at the .diff between two releases and find out what have been broken?
Comment 26 Christian Krause 2008-07-27 15:30:37 EDT
Created attachment 312742 [details]
patch for /etc/udev/rules.d/60-persistent-storage.rules (workaround)

Hi,

I've found the problem:

A change in udev (between release 120 and 121) causes the execution of the
utility vol_id on each change of any block device (before cd drives were not
affected). So when a CD is ejected, an udev change event happens, which causes
the execution of vol_id, which causes an open(2) call to the device which
causes the cd drive to close its tray. ;-)

Please see the patch for a workaround (only in the udev-rules files, no
compilation needed). 

I've sent a detailed mail to the upstream mailing list.

Please change the component of this bug to "udev" and please consider to apply
my patch or something similar to fix the problem. ;-)


Best regards,
Christian
Comment 27 Andre Costa 2008-07-27 17:18:23 EDT
Hi Christian,

this is awesome news! =) I just tested your patch, and indeed it works =) Very
nice work, thks for stepping up ;-)

Regards,

Andre
Comment 28 Lester 2008-07-27 17:24:52 EDT
Christian, you're my hero! Thanks for the patch, now it works like it should. 
Comment 29 Roberto Bechtlufft 2008-07-27 22:59:40 EDT
Thanks!
Comment 30 Peter Gordon 2008-07-28 01:28:55 EDT
With the included patch, the issue seems fixed on my machine too. Thanks,
Christian! =]
Comment 31 David Zeuthen 2008-08-01 18:40:02 EDT
Upstream decided on this patch.

 http://marc.info/?l=linux-hotplug&m=121749053301147&w=2

We should include this in all Fedora releases shipping udev > 120. Harald?
Comment 32 David Zeuthen 2008-08-01 18:41:29 EDT
Reassigning to Harald since this is an udev issue - Harald, please see comment
31. Thanks.
Comment 33 cornel panceac 2008-08-03 14:07:38 EDT
*** Bug 454133 has been marked as a duplicate of this bug. ***
Comment 34 john5342 2008-08-05 06:33:15 EDT
*** Bug 455365 has been marked as a duplicate of this bug. ***
Comment 35 Fedora Update System 2008-08-06 08:26:42 EDT
udev-124-2.fc9 has been submitted as an update for Fedora 9
Comment 36 Adam Huffman 2008-08-06 09:23:36 EDT
The new package solves the problem for me.
Comment 37 Fedora Update System 2008-08-07 19:57:33 EDT
udev-124-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7103
Comment 38 cornel panceac 2008-08-08 05:24:04 EDT
the udev-124-2.fc9.i386 seems to have fixed the bug for me. i have burned with k3b three cd's and all three ejects worked as they should. thank you.
Comment 39 Fedora Update System 2008-08-12 14:18:12 EDT
udev-124-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Bryan Christ 2008-08-12 14:25:41 EDT
The udev posted to updates-testing works for me.
Comment 41 Christian Krause 2008-09-08 17:39:32 EDT
udev-124-2.fc9 fixes the problem for me as well. Since the package was already pushed to F9 updates, I think the bug can be closed now.
Comment 42 Dennis Jacobfeuerborn 2008-12-25 20:53:31 EST
Did this fix get lost in the F10 release? I'm still seeing this on an up-to-date F10 installation.
Comment 43 Stewart Adam 2008-12-25 22:35:23 EST
Come to think of it, I am too... When I tried burning a few ISO images, the disc tray would open and close right away again before I could get the DVD out.
Comment 44 Tom 2008-12-29 15:49:39 EST
This is still occurring on updated F10 x86_64.  This is a major problem as my cd tray has already eaten one disc.
Comment 45 Jon Stanley 2008-12-29 16:20:42 EST
reopening per request, changing version to 10
Comment 46 Christian Krause 2008-12-30 10:31:52 EST
I've tested it on a fresh installation of F10 (32bit, fully updated) and the problem did not occur. I've checked /lib/udev/rules.d/60-persistent-storage-rules and it looks good. The rules have changed a little bit, but it it seems that if the device is a cdrom (KERNEL=sr*) and there is _no_ CD inserted, "vol_id" is still _not_ called (which caused the problem in F9).

So unfortunately I don't know what causes the problems in F10.
Comment 47 Dennis Jacobfeuerborn 2008-12-30 17:24:41 EST
Created attachment 327980 [details]
udevmonitor output

I attached the udevmonitor output I get when selecting "eject volume" from the context menu.

These are the events I get up to the point where the tray get closed again (to be clear: I cut the ouput *after* the tray started closing but *before* it closed completely)

Unfortunately I'm not sure what this is supposed to look like under normal conditions. Are the duplicate scsi and block events with SDEV_MEDIA_CHANGE=1 supposed to happen like that?
Comment 48 Dennis Jacobfeuerborn 2008-12-30 17:46:34 EST
I just performed an experiment and killed nautilus with "nautilus -q". After that I can insert and remove a DVD normally without seeing the above behavior.
Next I started nautilus again but killed the process "gvfs-hal-volume-monitor". That seems to "fix" the problem too.

Could it be that the "SDEV_MEDIA_CHANGE=1" event emitted on eject gets picked up by "gvfs-hal-volume-monitor" and interpreted as "oh, someone put in a new disc, better try to get some information about it" which then triggers the closing of the tray?
Comment 49 Tom 2008-12-30 21:01:45 EST
I can say that Dennis's experiences don't match mine.  Killing "gvfs-hal-volume-monitor" merely caused nautilus not to automatically mount the cd, and actually when I pressed the eject button the effect was that the cd was then mounted? Gnome would not release the cd, the tray did the same as usual, open, close, etc.  It took 4 cli attempts with "eject /dev/sr0" in rapid succession to finally eject.  Has anybody attempted this under KDE 4.x?  I may install it and see whether this occurs with KDE as well, if it does it's a systemwide problem, if not maybe something else has cropped up in Gnome.
Comment 50 Peter Gordon 2009-02-12 12:04:43 EST
I do not know what caused it, nor do I know what fixed it; but for the past several days I have been burning backups to DVD-Rs and I have yet to see this issue anymore. Is anyone else still experiencing this?
Comment 51 Zdenek Prikryl 2009-06-29 04:43:24 EDT
*** Bug 507908 has been marked as a duplicate of this bug. ***
Comment 52 Zdenek Prikryl 2009-06-29 04:44:50 EDT
*** Bug 506985 has been marked as a duplicate of this bug. ***
Comment 53 udo 2009-06-29 09:06:40 EDT
#50: my DVD-writer is OK now too but CD-ROM still has the issue
Comment 54 Bryan Christ 2009-06-29 10:24:22 EDT
This seems fixed in F11 and later updates to F10.
Comment 55 udo 2009-06-29 10:27:10 EDT
BTW:  udevmonitor --env
does not show anything when I eject the CD...
So what *IS* the workaround for Fedora 11?
And why has this issue been lingering for so long?
Comment 56 udo 2009-06-29 10:27:47 EDT
#54: this is not fixed in F11. See my comments about CD/DVD differences.
Comment 57 Aram Agajanian 2009-06-29 11:59:45 EDT
Yes, my experience with this problem relates to ROM devices (in my case a DVD-ROM drive).  My RW drive works OK.
Comment 58 udo 2009-06-29 12:21:12 EDT
My DVD is a plextor writer.
My CD is a plextor writer.
Need any specifics about my x86_64 Fedora 11 system?
Comment 59 Paulo Roma Cavalcanti 2009-08-05 10:29:31 EDT
I am having this problem either in KDE or Gnome
on a F10 fully updated.

I have two LG DVD/RW (different models) on the same computer,
and both close the tray immediately after ejecting a CD/DVD.

Both drives are IDE. I think this problem does not happen
when using SATA drives, though. At least it is fine on a second computer
with a single LG SATA drive.

It is quite annoying ...
Comment 60 Jonathan Kamens 2009-08-09 22:49:52 EDT
There are over 30 people CC'd on this ticket, which should give you a pretty darn good idea of how broad the impact is.  It has been around since at least F10 and is still around in Rawhide.  It's very, very basic functionality, and it's astounding that it's still broken after all this time.  WTF?
Comment 61 Dave Allan 2009-08-14 10:55:59 EDT
I can confirm that this bug is still present on a fully updated F11 box, kernel 2.6.29.6-217.2.3.fc11.i686.PAE.  Interestingly, it only appeared after I replaced my EIDE CDRW with a SATA DVD writer, a TSSTcorp CDDVDW SH-S223F, SB03, so it appears to be hardware dependent.  

The timing of the appearance of the problem may be meaningful:

In the BIOS, pressing the eject button on the drive causes the door to open and stay open.
The boot disk of this machine is encrypted, at the LUKS prompt, pressing the eject button on the drive causes the door to open and stay open.
The door closes almost immediately after I enter the disk password, before udev starts, and subsequently, pressing the eject button opens the door, but it immediately closes again.

Ruling out hardware failure, I returned the drive the first time it happened, thinking it was defective, but a second identical drive exhibits the same behavior.

+1 to increasing the priority--it makes my shiny new DVD writer pretty useless.
Comment 62 Aram Agajanian 2009-08-14 11:07:16 EDT
When the drive starts to close, if I press the button right away, it opens and stays open.
Comment 63 Dave Allan 2009-08-14 11:13:52 EDT
Unfortunately, pressing the eject button again does not cause it to stay open for me; I've pressed it twice in quick succession, and also when the drive door is closing; neither works: the door opens again, and immediately closes.  The strange thing, as far as I'm concerned, is how early in the boot process the problem appears on my hardware.
Comment 64 Harald Hoyer 2009-08-14 11:19:51 EDT
ok, try this:

# udevadm control --log-priority=debug

open tray, let it close

# udevadm control --log-priority=err

then post the udev entries from /var/log/messages from that timeframe
Comment 65 Dave Allan 2009-08-14 11:32:08 EDT
I should mention that I still have the old drive that didn't exhibit the
problem, so if it would be helpful, I can take 15 minutes and put it back in
the machine.
Comment 66 Dave Allan 2009-08-14 11:32:48 EDT
This is interesting--my logs are filled with kernel errors about resetting the drive...hang on.
Comment 67 Aram Agajanian 2009-08-14 12:10:45 EDT
Created attachment 357471 [details]
udev debug messages from /var/log/messages when pressing eject button

The drive is a TSSTcorp DVD-ROM TS-H353B D200.
Comment 68 Harald Hoyer 2009-08-14 12:19:38 EDT
can you figure out which of the tools is the culprit?

/lib/udev/cdrom_id
/lib/udev/scsi_id
/lib/udev/vol_id

just move them away temporarily...
Comment 69 Dave Allan 2009-08-14 16:45:57 EDT
There appear several causes of this behavior, at least some of which are purely hardware problems.  I think it's safe to say at this point that I am not hitting any bugs in the udev code.  What is happening on my system is that the SATA link is being reset once per second.  For reference, the messages are:

Aug 13 22:28:47 dain kernel: ata4.00: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6
Aug 13 22:28:47 dain kernel: ata4: hard resetting link
Aug 13 22:28:47 dain kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 13 22:28:47 dain kernel: ata4.00: configured for UDMA/100
Aug 13 22:28:47 dain kernel: ata4: EH complete

My theory at this point is that the SATA controller on my system does not properly support DVD writers, as I have tried two different models with the same result, as well as swapping the cables.  In any case, the problem has nothing to do with udev, and my guess is that my SATA controller is the root of it.
Comment 70 Aram Agajanian 2009-08-14 19:08:13 EDT
When any of the three files listed in Comment #68 are renamed, the drive no longer closes itself (i.e. the tray stays open).  When all three files have their correct names, then the drive closes itself.

I compared the messages when the drive closes itself and when it doesn't.  I found that the following message is printed immediately after the opening procedure is complete:

Aug 14 12:02:50 frogn udevd[182]: seq 1560 queued, 'change' 'scsi'

Is this a queued command to close the tray?
Comment 71 Fabrício Godoy 2009-08-17 10:39:57 EDT
My LG and SONY drives are actually ejecting without closing tray automatically.
But last days both drives are not ejecting by button when has some media inside. The workaround for me was tipying "eject /dev/sr0".

For some reason you tried "eject /dev/sr0" to test if tray is closed automatically after eject?
Comment 72 Dennis Jacobfeuerborn 2009-08-17 10:47:35 EDT
(In reply to comment #71)
> My LG and SONY drives are actually ejecting without closing tray automatically.
> But last days both drives are not ejecting by button when has some media
> inside. The workaround for me was tipying "eject /dev/sr0".
> 
> For some reason you tried "eject /dev/sr0" to test if tray is closed
> automatically after eject?  

Same here. After a fresh install of Fedora 11 I no longer have the closing problem but the eject button no longer works if a disc is in the drive. Right clicking the icon and selecting to eject the disc works.
Comment 73 Aram Agajanian 2009-08-17 10:51:46 EDT
When I open the problematic drive with the eject command (or by pressing the eject button) the drive closes automatically.
Comment 74 Dave Allan 2009-08-17 10:52:52 EDT
Re: comments #71 and #72, sorry if I'm saying something you already know, but
the door's probably not opening via the button because the drive door is locked
when the disk is mounted.  Check to see if unmounting it first allows the
button to work?
Comment 75 Dave Allan 2009-08-17 10:55:44 EDT
Re: comment #73, what's your motherboard/machine model?  I found with an older P4 ASUS board that the BIOS had problems with SATA DVD writers that caused the door to close immediately because the kernel was constantly issuing resets.  Do you see anything in /var/log/messages?
Comment 76 Dennis Jacobfeuerborn 2009-08-17 11:09:24 EDT
(In reply to comment #74)
> Re: comments #71 and #72, sorry if I'm saying something you already know, but
> the door's probably not opening via the button because the drive door is locked
> when the disk is mounted.  Check to see if unmounting it first allows the
> button to work?  

Indeed if I unmount the drive I can eject the disc using the button. So it seems either pressing the eject button never sends the event to unmount the disc or whatever process is responsible for mounting/unmounting ignores that signal.
Comment 77 Aram Agajanian 2009-08-17 11:31:06 EDT
The following is the output of the command "grep ata3 /var/log/messages"

Aug 17 10:45:59 frogn kernel: ata3: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 26
Aug 17 10:45:59 frogn kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 17 10:45:59 frogn kernel: ata3.00: ATAPI: TSSTcorpDVD-ROM TS-H353B, D200, max UDMA/33
Aug 17 10:45:59 frogn kernel: ata3.00: configured for UDMA/33

I believe that the cause of the closinsg of this drive's tray may have something to do with comment #68 and comment #70.
Comment 78 Harald Hoyer 2009-08-18 04:04:56 EDT
(In reply to comment #76)
> Indeed if I unmount the drive I can eject the disc using the button. So it
> seems either pressing the eject button never sends the event to unmount the
> disc or whatever process is responsible for mounting/unmounting ignores that
> signal.  

This is normal behaviour, isn't it? Door is locked, as long as it is mounted.
Comment 79 Dennis Jacobfeuerborn 2009-08-18 09:19:16 EDT
(In reply to comment #78)
> (In reply to comment #76)
> > Indeed if I unmount the drive I can eject the disc using the button. So it
> > seems either pressing the eject button never sends the event to unmount the
> > disc or whatever process is responsible for mounting/unmounting ignores that
> > signal.  
> 
> This is normal behaviour, isn't it? Door is locked, as long as it is mounted.  

No. Previously the disc got unmounted automatically when you pressed the eject button.
Comment 80 Harald Hoyer 2009-10-07 11:53:06 EDT
Does it help if you do:

# mv /lib/udev/rules.d/70-anaconda.rules /lib/udev/rules.d/70-anaconda.rules.old
Comment 81 Harald Hoyer 2009-10-07 11:54:08 EDT
in other words:
rename /lib/udev/rules.d/70-anaconda.rules 
to /lib/udev/rules.d/70-anaconda.rules.old
Comment 82 udo 2009-10-07 12:22:01 EDT
ls -l /lib/udev/rules.d/70-anaconda.rules
ls: cannot access /lib/udev/rules.d/70-anaconda.rules: No such file or directory
Comment 83 Harald Hoyer 2009-10-13 10:07:04 EDT
oh, maybe in /etc
/etc/udev/rules.d/70-anaconda.rules
Comment 84 udo 2009-10-13 10:45:32 EDT
$ cat /etc/udev/rules.d/70-anaconda.rules
cat: /etc/udev/rules.d/70-anaconda.rules: No such file or directory

$ find / -name '*anaconda*rules*' 2> /dev/null
$
Comment 85 Cia Watson 2009-10-25 17:25:28 EDT
I just wanted to report that I'm having the same problem (eject an audio CD, either from the cd player software or the drive icon) ejects the drive then it closes again right away -- on the Fedora 12 beta x64, live cd install, fully updated. (Except I think there was a yum error when a new kernel was downloaded yesterday, during the install... if it's important please advise what log I should refer to? yum log?)

I had to click the icon and select the unmount option, then I manually opened the drive door to remove the CD. (It's an LG DVD-rw drive).

If you need any more details, please let me know.
Comment 86 Harald Hoyer 2009-10-26 03:44:55 EDT
(In reply to comment #85)
> I just wanted to report that I'm having the same problem (eject an audio CD,
> either from the cd player software or the drive icon) ejects the drive then it
> closes again right away -- on the Fedora 12 beta x64, live cd install, fully
> updated. (Except I think there was a yum error when a new kernel was downloaded
> yesterday, during the install... if it's important please advise what log I
> should refer to? yum log?)
> 
> I had to click the icon and select the unmount option, then I manually opened
> the drive door to remove the CD. (It's an LG DVD-rw drive).
> 
> If you need any more details, please let me know.  

This is most likely bug 527781
Comment 87 Andrew Overholt 2009-11-04 13:47:47 EST
This works for me:

> # mv /lib/udev/rules.d/70-anaconda.rules{,.old}

I installed from a live CD of the F-12 beta.  Will this be fixed for those installing from F-12 final live images?
Comment 88 Harald Hoyer 2009-11-11 03:13:32 EST
for those, who experience this bug in F-12, you should subscribe to bug 527781
Comment 89 Brian Morrison 2009-11-11 04:34:04 EST
That bug is shown as being unavailable unless logged in via an account with appropriate permissions.

I seem not to have them....
Comment 90 Brian Morrison 2009-11-11 04:42:22 EST
No, cancel that, it suddenly works now!
Comment 91 Bug Zapper 2009-11-18 04:36:13 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 92 Jonathan Kamens 2009-11-22 07:13:13 EST
I no longer see this issue in rawhide.  I think it may have even been fixed in F12.
Comment 93 udo 2009-11-22 08:32:03 EST
It was *not* fixed in Fedra 12 for a Plextor DVD-player. Tested this afternoon.
Comment 94 udo 2009-11-22 08:40:14 EST
FWIW: the F12 box was upgraded from Fedora 11. Afterwards a `yum update` was issued. (why isn't the DVD filled a bit more?)
Then reboot.
Login.
Test.
Comment 95 Kamil Dudka 2009-11-22 15:49:21 EST
*** Bug 539928 has been marked as a duplicate of this bug. ***
Comment 96 Kamil Dudka 2009-11-22 18:35:42 EST
Harald, is the fix for Anaconda sufficient to heal already installed F-12 instances? Otherwise there should be released an update addressing the bug. Only for eject we have already 4 bugs closed as duplicates now...
Comment 97 Harald Hoyer 2009-11-23 03:58:52 EST
well, just uninstall the anaconda package and see if it works.

see also bug #527781
Comment 98 Mace Moneta 2009-11-30 01:18:15 EST
I removed anaconda, and still see the problem.  I can keep the tray from closing by holding down the physical eject button.
Comment 99 mangoo 2009-12-05 17:50:14 EST
Same problem on Fedora 12 32bit with gnome

my DVD drive is

LG DVD-RAM GH22NS30
HL-DT-ST
/dev/sr0
firmware 1.02
Internal
Yes (ejectable)
CD-ROM/CD-R/CD-RW/DVD-ROM/DVD+R/DVD+R DL/DVD+RW/DVD-R/DVD-RAM/DVD-RW
Comment 100 Andre Costa 2009-12-06 18:09:31 EST
I was having this issue with a fresh F12 install; removing Anaconda seems to have fixed the problem.
Comment 101 Benjamin Bellec 2009-12-11 15:56:21 EST
Me too, removing anaconda solved the issue.
Comment 102 Michael Monreal 2009-12-12 09:28:36 EST
For whatever reason, after removing anaconda it seems to work correctly for me as well...
Comment 103 udo 2009-12-12 13:51:19 EST
# rpm -qa|grep -i anaconda
anaconda-yum-plugins-1.0-5.fc12.noarch

This is the one to remove?
Comment 104 Brian Morrison 2009-12-12 14:02:53 EST
It seems you don't have the main anaconda package installed, so you might as well remove the yum plugin!
Comment 105 udo 2009-12-12 14:12:54 EST
# rpm -e anaconda-yum-plugins-1.0-5.fc12.noarch
error: Failed dependencies:
	anaconda-yum-plugins is needed by (installed) preupgrade-1.1.3-1.fc12.noarch
# rpm -e anaconda-yum-plugins-1.0-5.fc12.noarch preupgrade
error: Failed dependencies:
	preupgrade is needed by (installed) PackageKit-0.5.4-0.4.20091029git.fc12.x86_64
Comment 106 Alexandre Thieme Reis 2009-12-14 07:59:01 EST
I have the same problem in fedora core 12: CD-ROM tray closes automatically after eject

my 70-persistent-cd.rules:

# This file was automatically generated by the /lib/udev/write_cd_rules
# program, probably run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line
# and set the $GENERATED variable.

#  (pci-0000:00:1f.2-scsi-0:0:1:0)
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:1:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:1:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:1:0", SYMLINK+="dvd", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:1:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

lshw: (samsung dvd)

*-cdrom
                description: DVD-RAM writer
                product: CDDVDW SH-S223F
                vendor: TSSTcorp
                physical id: 0
                bus info: scsi@2: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: SB00
                capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
                configuration: ansiversion=5 status=nodisc
Comment 107 Kamil Dudka 2010-01-12 09:13:32 EST
*** Bug 554723 has been marked as a duplicate of this bug. ***
Comment 108 Fred Wells 2010-01-12 14:43:49 EST
Having the same problem with F12/KDE with LITE-ON DVDRW LH-20A1P.

Removing anaconda-yum-plugins not a viable option due to the number of depends (e.g. PackageKit, preupgrade, etc.).
Comment 109 Kvikende 2010-01-16 10:57:44 EST
Having the same problem with F12 GNOME with a LG GSA-H50N drive.
Comment 110 Kamil Dudka 2010-01-17 10:36:28 EST
What about releasing an F12 update of anaconda with the udev rules fixed?

Does it make sense to reopen bug 527781?

I am still closing duplicates...
Comment 111 Harald Hoyer 2010-01-26 10:22:25 EST
you might also try:

udev-145-15.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-15.fc12
Comment 112 udo 2010-01-26 10:41:31 EST
Tue Jan 26 2010 Harald Hoyer <harald@redhat.com> 145-15 
- removed one modem-modeswitch line (#541686) 
- added one modem-modeswitch line (#547759) 
- fixed dangling symlinks (#558235) 
- fixed initscript (#557771, #523976, 
- obsolete DeviceKit (#532961) 
- fixed copyright (#536843) 

Which of these has a relation to this bug?
Comment 113 Harald Hoyer 2010-01-26 10:48:34 EST
* Wed Nov 11 2009 Bastien Nocera <bnocera@redhat.com> 145-14
- Fix blu-ray and hd-dvd drives not getting detected properly
  when a medium is absent

if you have still an older version.
Comment 114 Benjamin Bellec 2010-01-30 05:14:20 EST
Yesterday, I have installed a fresh F12+updates on my main computer. There is also the same bug, but removing anaconda fix it.
Comment 115 Kamil Dudka 2010-01-30 05:44:23 EST
udev-145-14.fc12 apparently does not solve the problem.  I didn't get any positive nor negative answer per my comment #110, so that I've just reopened the bug 527781 for F-12.
Comment 116 Adam Huffman 2010-01-31 07:56:53 EST
Have tried with udev-145-15 and the bug is still there.

Possibly related is the weird behaviour when I press the eject button on the DVD writer - seemingly the disc is treated as if it's just been inserted and a new Nautilus window opens, showing the disc's contents.
Comment 117 Mario Chacon 2010-01-31 09:20:19 EST
I had the the issue on the latest updated of F12 testing that the CD tray is closed automatically after ejecting, so I remove the anaconda package and now I do not have the issue.
Comment 118 Odin Trisk 2010-02-05 13:13:04 EST
udev-145-14, hal-0.5.13-9 (on 64bit F12)

This happens to me.  I did use "cdrecord dev=/dev/scd0 -v -data -dao -eject foo.iso" before.

The CD was not mounted before, since it was blank and I burnt it.

The 'cdrecord' performs tghe eject.  Then something else (I guess) immediately performs a close of tray, the new ISO that was burnt was then mounted.

All the KDE controls like from Filemanager (Dolphin) to eject and also the removable device notifier to eject, so exactly the same thing from now on.  They do eject the CDROM then tray opens, but then it immediately closes (as in you can easily get your disk/fingers trapped trying to get the diskout in the short space of time).


What sub-systems are responsible for polling the CDROM status and performing auto-mounting ?
Comment 119 Harald Hoyer 2010-02-09 04:55:58 EST
(In reply to comment #118)

> What sub-systems are responsible for polling the CDROM status and performing
> auto-mounting ?    

for gnome it is gnome-mount, for KDE I don't know..
Comment 120 Michael Monreal 2010-02-09 05:04:51 EST
gnome-mount is no longer being used on recent GNOMEs.
Comment 121 Alec Leamas 2010-02-12 03:40:09 EST
As I understand it, nautilus is nowadays responsible for mounting removable media in gnome; there seem to be some code related to this in gnome-vfs-daemon .

Without looking into this code, I would be surprised if there is any polling involved. I just presume dbus is used, eventually driven by udev  events and rules.

No idea how this is handled in KDE, Xfce etc.

There is certainly people out there who knows this stuff better...
Comment 122 Harald Hoyer 2010-02-12 10:11:13 EST
ok, one thing to try:
comment out line 7 in /lib/udev/rules.d/60-persistent-storage.rules, which will look like this:

# forward scsi device event to corresponding block device
# ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change"
Comment 123 Alec Leamas 2010-02-15 07:46:33 EST
comment #122: Works For Me (tm). 

If I understand udev correct, the "official" way to do this is to copy /lib/udev/rules.d/60-persistent-storage.rules to /etc/udev/rules.d and thus avoid the fix to disappear at next update?!

Havn't  seen any side effects so far, but I guess there are...
Comment 124 Douglas Mencken 2010-02-21 11:02:38 EST
I can confirm that it is still present in F12.

How reproducible:
eject-2.1.5-15.fc12.ppc

Steps to Reproduce:
1. `eject /dev/hdc` or press "eject" button on keyboard or press eject button
on device

Actual results:
Tray opens, tray closes immediately

Expected results:
Tray opens

Additional Info:

$ wodim --scanbus
scsibus1000:
 1000,0,0 100000) *
 1000,1,0 100001) *
 1000,2,0 100002) 'TSSTcorp' 'CDDVDW SH-S202J ' 'SB02' Removable CD-ROM
 1000,3,0 100003) *
 1000,4,0 100004) *
 1000,5,0 100005) *
 1000,6,0 100006) *
 1000,7,0 100007) *
Comment 125 Douglas Mencken 2010-02-21 11:04:46 EST
yes, it is okay after "`echo "dev.cdrom.autoclose = 0" >> /etc/sysctl.conf`" or manually (after each boot: "`su -c 'sysctl -w dev.cdrom.autoclose=0'`"), but it's not default anyway; it may work on your side, but it is *definitely* a common problem
Comment 126 Alec Leamas 2010-02-22 16:04:51 EST
comment #122: This fix seems to have a side effect: blank disks are not recognized, system still presents the last mounted disk when it's replaced with a blank one. Makes burning hard, system does not find the media. Restoring the commented line makes it possible to burn.

All this on a 64-bit system.
Comment 127 Phil 2010-02-24 19:24:55 EST
(In reply to comment #125)
> yes, it is okay after "`echo "dev.cdrom.autoclose = 0" >> /etc/sysctl.conf`" or
> manually (after each boot: "`su -c 'sysctl -w dev.cdrom.autoclose=0'`"), but
> it's not default anyway; it may work on your side, but it is *definitely* a
> common problem    

to make this permanent across reboots you will need to do the following as root:

1. Modify sysctl.conf
# vi /etc/sysctl.conf

2. <i>nsert at the bottom of the file:

# Stop the cd tray auto closing, grrrrr
dev.cdrom.autoclose = 0

<esc>
:wq

3. Then run sysctl to reread its conf file
# sysctl -p
Comment 128 Adam Huffman 2010-02-27 10:45:37 EST
I have the same experience as https://bugzilla.redhat.com/show_bug.cgi?id=453095#c126 on my system.  Media detection seems to break if the udev line is commented out.
Comment 129 Máté Wierdl 2010-03-04 11:45:58 EST
This is a severe bug: none of the standard applications can be used to copy a DVD, for example. This bug makes k3b crash with a segfault. Brasero cannot make an iso image file---it works for 15 minutes, and then drops the incomplete ISO on the floor.  Ubuntu doesn't have this error!  

I wasted 8 dl dvd before I realized this was a bug in Fedora and not in my LG dvd burner.  

Please try to fix this!

Thx!
Comment 130 Kamil Dudka 2010-03-04 11:52:29 EST
(In reply to comment #129)
> This is a severe bug: none of the standard applications can be used to copy a
> DVD, for example. This bug makes k3b crash with a segfault. Brasero cannot make

The crash of k3b would be good to fill as a separate bug, if not already.  TIA
Comment 131 Matt T. Proud 2010-03-07 13:35:44 EST
The sysctl fix works for me.  Can anyone ellucidate why this regression happened?
Comment 132 Henrique Martins 2010-03-08 10:11:09 EST
Not sure about regression, but this has been happening to me for a couple of years now, thus three or more Fedora versions, but I always attributed to old hardware.  It still happens on my F12 and brand new dvd dual side writer, and that's when I found this bugzilla entry.  Will edit sysctl.cnf now
Comment 133 Benjamin Bellec 2010-03-08 10:34:50 EST
I discover that I have also this problem on my main computer (in fact I don't use really often my DVD player :p). Just removing anaconda fix this once again.
Comment 134 Steve Tyler 2010-03-10 15:20:08 EST
(In reply to comment #133)
> I discover that I have also this problem on my main computer (in fact I don't
> use really often my DVD player :p). Just removing anaconda fix this once again.    

Thanks, Benjamin! I was all set to apply Phil's work-around (Comment 127), when I saw yours. I had been blaming my new LiteOn iHAS424 DVD burner ...

Confirming that in F12 removing anaconda and its dependencies fixes the autoclose problem:

Mar 10 11:52:51 Erased: python-pyblock
Mar 10 11:52:52 Erased: makebootfat
Mar 10 11:52:53 Erased: iscsi-initiator-utils
Mar 10 11:52:54 Erased: python-nss
Mar 10 11:52:55 Erased: cracklib-python
Mar 10 11:52:55 Erased: anaconda
Mar 10 11:53:01 Erased: python-cryptsetup

yum erase python-pyblock-0.44-1.fc12.x86_64 python-cryptsetup-0.0.10-1.fc12.x86_64 makebootfat-1.4-9.fc12.x86_64 cracklib-python-2.8.13-6.x86_64 python-nss-0.8-1.fc12.x86_64 iscsi-initiator-utils-6.2.0.870-10.fc12.1.x86_64 anaconda-12.46-2.fc12.x86_64

However, autoclose is still set:
[stephent@walnut cdrom]$ cat /proc/sys/dev/cdrom/autoclose 
1
Comment 135 Dave Jones 2010-03-10 16:44:20 EST
Just a heads-up:

mv'ing /lib/udev/rules.d/70-anaconda.rules to /lib/udev/rules.d/70-anaconda.rules.old 

as occasionally suggested will cause a /dev/dm-0 initialization error if you create a custom fedora spin and try to install to hard disk with it.
See "Bug 531052 - [anaconda] Live: Error processing drive: /dev/dm-0"

Removing anaconda from a live spin will mean the installer will not work at all, right?

echo "dev.cdrom.autoclose = 0" >> /etc/sysctl.conf

in the %post section of your kickstart file seems to be a much better plan.
editing the file manually and calling "sysctl -p" works on a running live image

It does the trick and does not seem to break the live-cd installer.

Of course it may break something else that I have not discovered yet.
Comment 136 Steve Tyler 2010-03-10 17:14:18 EST
(In reply to comment #135)
...
> Removing anaconda from a live spin will mean the installer will not work at
> all, right?
> 
> echo "dev.cdrom.autoclose = 0" >> /etc/sysctl.conf
> 
> in the %post section of your kickstart file seems to be a much better plan.
> editing the file manually and calling "sysctl -p" works on a running live image
...

I was merely experimenting with anaconda on my F12 system, so removing it was not a problem.

The sysctl.conf edit sounds like a much better work-around overall.

Still, why is autoclose being set to 1?
Comment 137 Dave Jones 2010-03-10 17:28:13 EST
I would guess autoclose being set to 1 has something along the lines of CD/DVD burners finalizing a disc, ejecting it and then re-loading it to begin a md5sum check of the newly loaded disc but I am merely speculating.

Aside from that, I cannot think of any reason to spit a disc out and then suck it back in.
Comment 138 eagleton 2010-03-17 05:59:47 EDT
Not sure if it is interesting, but I didn't have this bug until I removed gnome-gvfs because of https://bugzilla.redhat.com/show_bug.cgi?id=493565

This is on Fedora 12, 64 bit.
Comment 139 Harald Hoyer 2010-04-13 12:21:52 EDT
*** Bug 527799 has been marked as a duplicate of this bug. ***
Comment 140 Harald Hoyer 2010-04-13 12:42:17 EDT
You might be interested in this update

  http://admin.fedoraproject.org/updates/udev-145-20.fc12


Although it might not solve the autoclose issue, it solves a lot of cdrom related issues.
Comment 141 Fedora Update System 2010-04-27 08:21:00 EDT
udev-145-21.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-21.fc12
Comment 142 Harald Hoyer 2010-04-27 08:22:00 EDT
This bugfix can prevent your cdrom from automatically closing, after you opened it. It might not work for your drive, but some are fixed.

 http://admin.fedoraproject.org/updates/udev-145-21.fc12
Comment 143 Aram Agajanian 2010-04-27 12:15:12 EDT
After updating to 145-21 and rebooting:

TSSTcorpDVD-ROM TS-H353B, D200

This drive persistently closes.  If I press on the eject button, nothing happens.  If I run a software eject, the drive closes immediately.  Pressing the eject button before the drive closes will cause the drive to open, but then it will immediately close again.  If I let the drive close, wait a couple of seconds, and press the drive button, then the drive door will open and stay opened.

Optiarc DVD+/-RW AD-7200S, 102A

This drive always takes two presses on the eject button to open.  It then will stay open.  If I press on the eject button only once, the disc will be unmounted and the mounted again.  The drive door never opens.
Comment 144 Fedora Update System 2010-04-27 21:18:47 EDT
udev-145-21.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-145-21.fc12
Comment 145 Fred Wells 2010-04-27 23:59:41 EDT
udev-145-21.fc12.i686  No fix for me.

LITE-ON  DVDRW LH-20A1P

Tested using 'eject' command, manual eject and KDE Device Notifier eject.

Added feedback to http://admin.fedoraproject.org/updates/udev-145-21.fc12
Comment 146 Benjamin Bellec 2010-05-24 08:47:11 EDT
udev-145-21.fc12.i686  No fix for me too.

NEC ND-4571A
Comment 147 Benjamin Bellec 2010-05-24 08:47:20 EDT
udev-145-21.fc12  No fix for me too.

NEC ND-4571A
Comment 148 Fedora Update System 2010-05-25 14:38:51 EDT
udev-145-21.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 149 Fred Wells 2010-05-25 21:48:56 EDT
Not quite sure why this is being closed.  Problem sill persists with udev-145.21.fc12.
Comment 150 peter.feerick 2010-05-28 05:14:38 EDT
This bug (or similar) is still present in Fedora r13, and is not isolated to Fedora... it is also present in Ubuntu (as of at least 9.04), and seems to be linked to the general usage of libata. It triggers on my ecs-661fx mainboard for a LG-H62N sata connected DVD-RW drive, and constantly hard-resets the ata interface. I used the 'eject /dev/sr1' command, which is the only way to eject the drive (as it does not respond to the eject button at all), which triggered it to eject and promptly close. 

I am now looking at a drive which is constantly flashing the activity light, moving the laser head and being as much use a bookend. Other than that, I really like r13!
Comment 151 Dieter Stolte 2010-06-05 08:13:50 EDT
I can confirm that the bug still triggers the tray closing after trying to eject the media. udev-145-21.fc12.x86_64 does NOT fix this bug! please reopen the bug report!

A detail may help to fix it: my new plextor burner supports "asynchronous notification" which seems to emit the media change event immediatly whenever you try to eject. My older lg burner does not show this behaviour. So the bug is valid for plextor (PX-880SA) but not for the lg (GH20NS10).
Comment 152 Kamil Dudka 2010-06-05 08:23:49 EDT
reopening per comment #145 , comment #147 , comment #149 , comment #150 and comment #151
Comment 153 Fred Wells 2010-06-06 00:46:13 EDT
Not sure how helpful this is, but the problem appears to have been fixed in Fedora 13.  So far, I've been unable to reproduce it there.
Comment 154 Martin Donald 2010-08-02 00:04:53 EDT
I have the same problem on one of two fc12 systems:

My wife's old Compaq. kernel 2.6.32.16-141.fc12.i686.PAE

Sony Model: DVD RW DRU-V202A      Works correctly
HK-DT-ST Model: CD-RW GCE-8400B   Works correctly

My one-year-old-self-build  kernel 2.6.32.16-141.fc12.x86_64

Optiarc Model: DVD RW AD-72405    reloads disc before I can get it out
Lite-On Model: DVDRW SHM-165P6S   reloads disc before I can get it out

All are PATA internal except the Optiarc is SATA internal

I have to shut the machine down and activate setup on startup to manually remove the discs.
Comment 155 Maciej Żenczykowski 2010-08-02 00:28:46 EDT
Are you sure of that?
I've often found that while pressing the eject button the first time will result in an eject, immediately followed by a load, pressing it again afterwards will result in a normal eject, with the tray staying out...

Maybe I was observing a different bug (and I haven't seen it in a while)...
Comment 156 Martin Donald 2010-08-02 12:30:20 EDT
Just after I posted my comment I found the work-around to hit the eject button again immediately after the reload and was able to extract the disc.
Comment 157 Bug Zapper 2010-11-04 07:52:07 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 158 Joseph Sacco 2010-11-04 10:08:00 EDT
Problem persists in both fedora 12 and ubuntu 10.04.

-Joseph
Comment 159 tparker 2010-11-12 15:23:42 EST
I still have this problem in Fedora 13 - both 64 and 32 bit, both of those as default install (gnome) and the KDE spin, and with Fedora 13 64 bit XFCE spin. I also had the same issue with older Ubuntu versions I had tried (H,I, and J).

I do not have any problems with the drive if I install Windows Vista or when I tried a current Gentoo build with -gnome and -gtk use flags. I'm not sure if any of that is useful to tracking this down. My current install is Fedora 13 32 bit, KDE spin. I will be happy to post anything helpful, but will need directions on what is needed and how to get it for you.
Comment 160 cornel panceac 2010-11-17 06:01:27 EST
i see this happening again in fedora 14. also, i see a similar behaviour with usb drives: "safely remove" removes the usb drive icon from desktop, and immediately reappears. could be related?
Comment 161 udo 2011-04-08 07:44:58 EDT
Plexwriter Premium 1.07. Fedora 14 x86_64.
type `eject cdrom` and the tray opens *and* closes again.
Same when we press the cdrom button to open the tray.

Had to link /dev/cdrom manually to /dev/hda....
Comment 162 udo 2011-04-08 07:45:56 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=694782
 for a bug for the links, perhaps it is related as the drive is not seen as a cdrom at all... (?!)
Comment 163 Dave Jones 2011-04-08 09:54:26 EDT
Have you tried the tweaks in comment #135 ?
I have began moving my builds to Scientific Linux / EL6 but the tweaks still worked in Fedora 14, IIRC.

Worth trying?
Comment 164 udo 2011-04-08 10:12:57 EDT
Thanks!
The sysctl tweak works. but if the intended way is to go without the tweak, what is the matter here?
Comment 165 Dave Jones 2011-04-08 14:35:06 EDT
I've got nuthin
Comment 166 Reartes Guillermo 2011-07-16 12:25:00 EDT
I also solve the issue here:

Bug 684160 - ejected dvd disk reinserts itself after ejection (dolphin, 'eject' command

with setting sysctl 'dev.cdrom.autoclose' to '0'

In my case (F15 X86_64 on an AMD Desktop and a DELL Laptop). The only program affectd is dolphin. (It started with F15) 

I also opened a kde bugreport: https://bugs.kde.org/show_bug.cgi?id=269146

Can anybody tell if the default to that sysctl setting is a kernel.org Kernel default or a Fedora Kernel default?
Comment 167 Fedora Admin XMLRPC Client 2011-10-20 12:10:17 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 168 Fedora Admin XMLRPC Client 2011-10-20 12:12:07 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 169 Fedora Admin XMLRPC Client 2011-10-20 12:14:55 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 170 Raphael Groner 2012-02-09 13:55:59 EST
I see this bug is open since fc14. As I encountered that problem in Arch, I would like to know if there's a fix for Fedora 16?
Comment 171 Benjamin Bellec 2012-02-09 14:05:36 EST
I haven't seen this bug on any F16 machines.
Comment 172 Raphael Groner 2012-02-09 14:09:57 EST
(In reply to comment #171)
Benjamin,
what versions of both kernel and udev do you run on your machines?
Comment 173 Benjamin Bellec 2012-02-09 14:47:13 EST
(In reply to comment #172)
> (In reply to comment #171)
> Benjamin,
> what versions of both kernel and udev do you run on your machines?

Currently, kernel 3.2.3-2.fc16.x86_64 and udev 173-3.fc16.x86_64
Comment 174 Fedora End Of Life 2012-08-16 18:22:02 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping