GNOME Bugzilla – Bug 623485
Disc could not be ejected
Last modified: 2013-08-05 21:08:24 UTC
Created attachment 165189 [details] Log After a successful burn on Fedora 13 (using brasero 2.30.1) I get this: ---- Please eject the disc from "TSSTcorp CD/DVDW SH-S183A" manually. The disc could not be ejected though it needs to be removed for the current operation to continue. [Cancel] --- Happens on two systems with very different hardware, so I guess we can rule out a hardware fault.
The problem seems to be caused by the fact that nautilus (?) tries to mount the just-burned disc while brasero tries to eject it.
Thanks for the report. I did indeed see this from time to time. It happened after we moved from HAL (deprecated now) to GIO. The problem here is that there is no longer any possibility to lock a drive and tell other apps not to tamper with it. I am looking at the possibility of moving to gnome-disk-utility maybe it will provide the possibility we are looking for.
Created attachment 167070 [details] error screenshot
Comment on attachment 167070 [details] error screenshot I have the same error on Linux Mint 9.
Excuse me, I did not undestand how to group all my feedback on a same topic. Forgot to tel that the Brasero version I use is 2.30.2
This probably depends on #623485. Let's wait for the resolution of the said bug and see if it helps.
I experience the same bug on Brasero 2.31.2, running on 64-bit Ubuntu, kernel 2.6.34-020634 on a Dell Studio 1558. Indeed Nautilus appears to be wrestling for the drive with Brasero, since after the burn is done and Brasero fails to eject and comes up with an error message, often (not always) a Nautilus window showing the new CD appears. Error messages after running brasero with the -g option: BraseroBurn: (at burn-task.c:190) stopped BraseroChecksumImage BraseroBurn: (at burn-task.c:448) got out of loop BraseroBurn: (at brasero-burn.c:392) Ejecting drive/medium BraseroBurn: (at brasero-burn.c:443) Retrying ejection BraseroBurn: (at brasero-burn.c:448) Ejection error: DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given drive was not found BraseroBurn: (at brasero-burn.c:443) Retrying ejection BraseroBurn: (at brasero-burn.c:448) Ejection error: DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given drive was not found BraseroBurn: (at brasero-burn.c:443) Retrying ejection BraseroBurn: (at brasero-burn.c:448) Ejection error: DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given drive was not found BraseroBurn: (at brasero-burn.c:443) Retrying ejection BraseroBurn: (at brasero-burn.c:448) Ejection error: DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given drive was not found BraseroBurn: (at brasero-burn.c:443) Retrying ejection BraseroBurn: (at brasero-burn.c:448) Ejection error: DBus error org.gtk.Private.RemoteVolumeMonitor.NotFound: The given drive was not found BraseroBurn: (at brasero-burn.c:434) Max attempts reached at ejecting Fortunately, "eject cdrom" from the command line works, although interestingly, the eject key on the computer doesn't (this is a slot-load cd drive). Philippe, any idea of the time needed before this is fixed? It's a minor pain in the neck. Thanks!
Still an issue in 2.32 using Ubuntu 10.10. I have found many reports of this on launchpad and debian bug trackers and have linked the master bug to this upstream bug. To see this issue reported on launchpad see: https://bugs.launchpad.net/bugs/519935 To see this issue reported on the debian bug tracking system see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503915 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551679 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583821
(In reply to comment #6) > This probably depends on #623485. Let's wait for the resolution of the said bug > and see if it helps. What bug are you talking about ? #623485 is this bug :) Confirmed on gentoo with 2.32* series.
I think he meant it depends on #627116
By the way this bug is a duplicate of 620151
Still exists in Brasero 3.2.0
It sounds like a simple conflict of different packages. I think a good solution would be to include the "typical" commands that should be used to manually eject the disk. I know the command is quite literally "eject" or "eject -T" but I still had to look that up and I'm not sure if that is correct. Some suggested commends would be very helpful when this this happens.
I experience the same issue in Brasero 3.2.0. It has so far happened with 3/3 disc burns.
This problem has been fixed with migration over to udisks2 monitor backend in gvfs.