Bugzilla – Bug 659153
Ejecting Optical Drives Causes Immediate Re-Close of Tray and KNotify Crash
Last modified: 2015-11-09 16:31:14 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.12) Gecko/20101026 SUSE/3.6.12-0.7.1 Firefox/3.6.12 If a mounted volume on optical disc is in the tray, clicking the "eject" icon in Dolphin will cause the optical drive tray to open. However, it will immediately close again and attempt to re-mount the disc, at which point KNotify will crash. It may be in some way related to bug 659139 here: https://bugzilla.novell.com/show_bug.cgi?id=659139 Reproducible: Always Steps to Reproduce: 1. Insert optical disc and wait for mount 2. After disc has been mounted, attempt to eject using the "eject" icon from within Dolphin. 3. The drive will open and immediately close again. Actual Results: Attempting to eject the disc will result in an immediate close of the drive tray and another attempt to re-mount the disc, at which point KNofity will crash. Expected Results: The disc should be ejected and the drive tray should remain open until closed by the user.
Problem no longer appears to be present in 11.4 M5. Closing as fixed.
This bug has re-appeared in Milestone 6, however Knotify no longer crashes (most likely due to HAL being removed).
This bug is still present in 11.4 RC1. It is currently IMPOSSIBLE to properly eject optical disks from tray-based drives. (changed during the 2011-02-20 Open-Bugs-Day about bugs for obsolete versions of openSUSE)
https://bugzilla.novell.com/show_bug.cgi?id=659139 is unrelated and was as you correctly noticed due to the dual use of udev and hal backends in solid. This bug seems to be either in the udisks-daemon or solid, I tried finding other bugreports but it's not much =/ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577578 hints at udisks-daemon https://bugs.kde.org/show_bug.cgi?id=264487 hints at solid http://lists-archives.org/kde/12270-dvd-tray-remain-not-open.html are the same symptoms as you have I'll assign to Kay in the hope he knows something out of this head and has a good pointer for further search, if not just reassign to kde. And Malvern please file this at the kde bugtracker to see if they have any ideas.
Sorry, I don't have any way to reproduce, because I have no devices with a tray left -- only laptop-like optical drives which need a manual close. I don't know of any recent changes or recent problems in the lower layers like the kernel or udev. Would be nice, if you can try without a running KDE session, if the same thing happens.
finally installed on a machine that can eject -t eject button works (when CD is unmounted) "eject" on command-line works fine eject with nautilus works fine but dolphin's eject causes tray to close again It even causes tray-close, if dolphin only views the CD and I do eject with one of the other working methods. This all points at problems with the upper layers (dophin/solid)
Christian Boltz is claiming that there are problems with unmounting *all* removable devices in this bug report: https://bugzilla.novell.com/show_bug.cgi?id=668039 I don't see how we can ship with this.
I have confirmed that this bug is still present in 11.4 final for machines with 5 1/4" full tray optical drives. As Bernhard pointed out, pressing the eject button on the drive itself causes no problems, but using Dolphin to eject any inserted disc causes a tray re-close. I hope this problem is able to be solved, as 11.4 is otherwise a relatively solid release.
Updated the bug status below to reflect its presence in final. Using the Device Notifier to eject the disc also causes a tray re-close.
I have confirmed the presence of this bug in 12.1M3, except it is now worse. After the first re-close, it is no longer possible to eject the optical disc, either through Dolphin, KDE's Device Notifier or by pressing the eject button on the drive itself. Being able to eject optical discs is basic functionality, and should not have been broken in 11.4 final, let alone 12.1M3. Note that "Platform" does not allow me to select openSUSE 12.1, so I have left it as openSUSE 11.4 for the time being.
I was also not able to set the version that this problem is in the Milestone 3 as this has not been added to Bugzilla yet, nevertheless, this bug was tested against Milestone 3.
I've done some further testing. The problem appears to be related to Dolphin in some way, but the behaviour is inconsistent. Trying to eject a disk using either device notifier or Dolphin causes a tray reclose. Trying to eject the disk using the eject button on the drive fails to open the tray. I was however, also able to get the machine into a state where the output of the command "mount" still showed the optical disk as mounted, and neither Dolphin, Device Notifier or the Eject Button on the drive itself were able to persuade the tray to open at all.
Running the command "eject" from the command line produced the message that it "could not find or open device for: /dev/cdrom", however, the command "eject /dev/sr0" finally opened the tray.
This bug is still present in 12.1 Milestone 5. Surely SuSE cannot ship yet another release with this bug...
happen very often, included in my *home desktop dvd recorder* (not a PC) so I dont nkow is we can do something, I suspect a faulty hardware driver
Excuse me, but are you kidding? I can reproduce this issue on every machine I install openSuSE 12.1 Milestone 5, and openSuSE 11.4 Final on. This is not simply a case of "faulty hardware".
no, but I can reproduce it on nearly any hardware I have here, being a PC or not (two desktop dvd readers included), so I don't know if there is anything that can be fixed (would be nice to have) - I'm still holding the device by hand.
As expected, this problem persists in 12.1 Beta1. Surely this deserves a fix prior to release?!
Confirming with latest Factory ~ 12.1 rc1
Workaround for now is, sudo sysctl dev.cdrom.autoclose=0
Thanks Ismail. Is there any reason this setting should not be the default? As in, does it result in any other kind of unexpected behaviour?
Fix is simple but we are blocked by bug #725412 atm :(
Thanks for your prompt response and hard work! Looking forward to seeing the matter fixed before release.
Bug is still present in RC1, though I understand it cannot be fixed until #725412 is sorted.
(In reply to comment #25) Why?
(In reply to comment #26) > (In reply to comment #25) > > Why? Because the fix is https://build.opensuse.org/request/show/89545 which won't work until we fix bug #725412
This is an autogenerated message for OBS integration: This bug (659153) was mentioned in https://build.opensuse.org/request/show/89958 Factory / procps
Just to provide a necessary update, this bug is still present in 12.1 RC2. Hoping to get a fix by final.
Just updating this bug for 12.1 Final. It is of course still present, however for some reason, using Dolphin still causes a "reclose", but using the device manager in the system tray simply refuses to eject the disc.
So now that the bug this problem depended on is fixed, can we get a fix for this? For reference: https://bugzilla.novell.com/show_bug.cgi?id=725412
This bug is also present in openSuSE 12.2 Milestone 2. Hoping for a fix for that prior to release, and to have that fix backported to 12.1
Fixed platform setting to 12.2
(In reply to comment #32) > This bug is also present in openSuSE 12.2 Milestone 2. Hoping for a fix for > that prior to release, and to have that fix backported to 12.1 What does the following command say: > sysctl dev.cdrom.autoclose
on my 12.1 # sysctl dev.cdrom.autoclose dev.cdrom.autoclose = 1
Well the bug is only fixed for 12.2 :)
Ismail, the bug is NOT fixed for 12.2 and is still present in 12.2M3. The result of > sysctl dev.cdrom.autoclose is "dev.cdrom.autoclose=1". Could this please be fixed for the next milestone?
This issue appears to be resolved in 12.2 Beta 2. Closing as fixed.
Whoops, forgot to close on the last comment.
Where are all these reversions coming from?! This bug is back in 12.2 final!
This bug does not appear to be present in 12.3 Beta 1. Can somebody please confirm?
Not present in 12.3 RC1. Does this need to be closed as WONTFIX?
Bug is back again in 12.3 Final. Unbelievable! Can somebody PLEASE fix this?!
Bug does not appear present in 13.1 M2. Can anyone else confirm?
I cannot reproduce in 13.1 M4. I'll leave this open for 12.3.
12.3 is out of maintenance, so closing as fixed.
Not present in 42.1 as far as I can tell. I concur.