Bug 453095

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.

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)

Looks like this is the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=451320

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

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

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

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

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.

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.

*** Bug 454147 has been marked as a duplicate of this bug. ***

*** Bug 455110 has been marked as a duplicate of this bug. ***

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.

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

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.

Changed severity to high because of the risk of damaging hardware or media.

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.

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

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.

Pretty annoying. I thought that just my DVD driver is somehow strange, but I see
the problem is not in the drive.

Yes, *very* annoying. I hope this gets fixed soon, my cd-rom drive is pretty
useless on Linux as it is.

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.

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

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

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

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

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

Hi Christian,

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

Regards,

Andre

Christian, you're my hero! Thanks for the patch, now it works like it should. 

Thanks!

With the included patch, the issue seems fixed on my machine too. Thanks,
Christian! =]

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?

Reassigning to Harald since this is an udev issue - Harald, please see comment
31. Thanks.

*** Bug 454133 has been marked as a duplicate of this bug. ***

*** Bug 455365 has been marked as a duplicate of this bug. ***

udev-124-2.fc9 has been submitted as an update for Fedora 9

The new package solves the problem for me.

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

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.

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.

The udev posted to updates-testing works for me.

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.

Did this fix get lost in the F10 release? I'm still seeing this on an up-to-date F10 installation.

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.

This is still occurring on updated F10 x86_64.  This is a major problem as my cd tray has already eaten one disc.

reopening per request, changing version to 10

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.

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?

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?

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.

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?

*** Bug 507908 has been marked as a duplicate of this bug. ***

*** Bug 506985 has been marked as a duplicate of this bug. ***

#50: my DVD-writer is OK now too but CD-ROM still has the issue

This seems fixed in F11 and later updates to F10.

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?

#54: this is not fixed in F11. See my comments about CD/DVD differences.

Yes, my experience with this problem relates to ROM devices (in my case a DVD-ROM drive).  My RW drive works OK.

My DVD is a plextor writer.
My CD is a plextor writer.
Need any specifics about my x86_64 Fedora 11 system?

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

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?

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.

When the drive starts to close, if I press the button right away, it opens and stays open.

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.

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

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.

This is interesting--my logs are filled with kernel errors about resetting the drive...hang on.

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.

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

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.

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?

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?

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

When I open the problematic drive with the eject command (or by pressing the eject button) the drive closes automatically.

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?

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?

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

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.

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

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

Does it help if you do:

# mv /lib/udev/rules.d/70-anaconda.rules /lib/udev/rules.d/70-anaconda.rules.old

in other words:
rename /lib/udev/rules.d/70-anaconda.rules 
to /lib/udev/rules.d/70-anaconda.rules.old

ls -l /lib/udev/rules.d/70-anaconda.rules
ls: cannot access /lib/udev/rules.d/70-anaconda.rules: No such file or directory

oh, maybe in /etc
/etc/udev/rules.d/70-anaconda.rules

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

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.

(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

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?

for those, who experience this bug in F-12, you should subscribe to bug 527781

That bug is shown as being unavailable unless logged in via an account with appropriate permissions.

I seem not to have them....

No, cancel that, it suddenly works now!

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

I no longer see this issue in rawhide.  I think it may have even been fixed in F12.

It was *not* fixed in Fedra 12 for a Plextor DVD-player. Tested this afternoon.

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.

*** Bug 539928 has been marked as a duplicate of this bug. ***

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

well, just uninstall the anaconda package and see if it works.

see also bug #527781

I removed anaconda, and still see the problem.  I can keep the tray from closing by holding down the physical eject button.

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

I was having this issue with a fresh F12 install; removing Anaconda seems to have fixed the problem.

Me too, removing anaconda solved the issue.

For whatever reason, after removing anaconda it seems to work correctly for me as well...

# rpm -qa|grep -i anaconda
anaconda-yum-plugins-1.0-5.fc12.noarch

This is the one to remove?

It seems you don't have the main anaconda package installed, so you might as well remove the yum plugin!

# 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

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

*** Bug 554723 has been marked as a duplicate of this bug. ***

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

Having the same problem with F12 GNOME with a LG GSA-H50N drive.

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

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

Tue Jan 26 2010 Harald Hoyer <harald> 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?

* Wed Nov 11 2009 Bastien Nocera <bnocera> 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.

Yesterday, I have installed a fresh F12+updates on my main computer. There is also the same bug, but removing anaconda fix it.

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.

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.

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.

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 ?

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

gnome-mount is no longer being used on recent GNOMEs.

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

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

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

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

(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

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.

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!

(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

The sysctl fix works for me.  Can anyone ellucidate why this regression happened?

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

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.

(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

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.

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

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.

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.

*** Bug 527799 has been marked as a duplicate of this bug. ***

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.

udev-145-21.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/udev-145-21.fc12

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

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.

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

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

udev-145-21.fc12.i686  No fix for me too.

NEC ND-4571A

udev-145-21.fc12  No fix for me too.

NEC ND-4571A

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.

Not quite sure why this is being closed.  Problem sill persists with udev-145.21.fc12.

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!

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

reopening per comment #145 , comment #147 , comment #149 , comment #150 and comment #151

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.

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.

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

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.

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

Problem persists in both fedora 12 and ubuntu 10.04.

-Joseph

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.

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?

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

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... (?!)

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?

Thanks!
The sysctl tweak works. but if the intended way is to go without the tweak, what is the matter here?

I've got nuthin

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?

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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?

I haven't seen this bug on any F16 machines.

(In reply to comment #171)
Benjamin,
what versions of both kernel and udev do you run on your machines?

(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

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