Unounting flash drive works as expected e.g. notification tray icon goes empty and hide, but umounting iso image via eject buttons, does not hide entry even menu is still accessible but image is *really* umounting - /run/media/<mount-point> is empty. So i think is Solid related bug, please fix me if i'm wrong. It'll follow a screenshot by original reporter.
CD/DVD images aren't ejected properly when cdemu is being used. After they been ejected device notifier still lists them. Dolphin lists them too in the device section. Actually the folder in /run/media/user disappears after unmounting but the image (.iso, bin, etc) is still present in the device notifier and Dolphin. This happens only with CD/DVD images. With flash drives all works as intended. Here you are some screenshots: The image is mounted and is properly listed in Dolphin and device manager: https://s7.postimg.cc/apt0ux5l7/image.png https://s7.postimg.cc/6goastmx7/image.png The folder in /run/media/user is also there: https://s7.postimg.cc/jm3syhlt7/image.png When the image is being ejected from Dolphin or the device manager, the folder in /run/media/user disappears but Dolphin and the device manager continue to list it. If you close and open Dolphin, the image disappears from it's device list, but it is actually there and it exists in the device manager and the icon for pluged removable devices is still being shown in the panel. This icon can onle be removed if the DE or machine is restarted. Here are some screenshots: The image is unmounted either from Dolphin or from the device manager. It makes no difference, the result is all the same. The options for eject or release are gone: https://s7.postimg.cc/41wf8696j/image.png The folder in /run/media/user has diappeared: https://s7.postimg.cc/xtthn6o8b/image.png The icon in the panel is still here and the device manager still lists the image file with the three actions for this mime type which doesn't work for the image isn't there: https://s7.postimg.cc/kqxv3txzf/image.png https://s7.postimg.cc/ru5qjwdu3/Screenshot_20180517_002007.png If one of the three options are being chosen, the malformed url error appears because the image is gone: https://s7.postimg.cc/era40mvbv/image.png
Is the thread in the right place? Why ignoring it?
Hello, anybody???
The solid framework currently has no maintainer. It looks like you investigated a lot, maybe you could even propose a patch to fix this issue?
I wish to but I can't. I don't have the knowledge :(
From what I can tell when unmounting, the device loses its "FileSystem" interface at which point it will be ignored, hence it not showing up when restarting Dolphin. However, the device itself isn't actually removed, so the filtered list isn't updated. Not sure how to fix this. The "autoclear" flag (-o loop) has no effect.
Does it eject is pressed then solid umount and should fire Solid::DeviceNotifier::deviceRemoved then DeviceNotifier should became empty no?
I get the Antony's patch from here: https://phabricator.kde.org/D13869 I use it two weeks already and so far I haven't any problems at all. The patch works flawlessly for me. Kudos to anthonyfieroni for providing fix for this annoying problem.
Git commit 8e9fc89918c4a8817b624a61e0d2d32d349722cc by Stefan Brüns. Committed on 14/08/2018 at 13:03. Pushed by bruns into branch 'master'. Force reevaluation of Predicates if interfaces are removed Summary: If an application wants to show only specicific devices based on predicate matching, and one of the matching devices loses an interface which is critical for the Predicate to match, the application has to be notified. As there is no dedicated signal to notify the application about the fact a device no longer has e.g. a Solid::StorageAccess iface, signal the device has been removed, and immediately readd it, as the device may still be relevant. Remove the call to updateBackend(udi), as the device backend listens to the InterfacesRemoved signal itself and updates its property cache. Test Plan: 1. Image file mounting via loop-back - udisksctl loop-setup -f ~/fat.img -> Icon appears under "Devices" - unmount via context-menu in dolphin -> device icon stays in "Devices" - set "Auto-clear" flag on loop (e.g. losetup --detach-all) - remount - unmount -> device icon vanishes from "Devices" 2. CD-ROM/DVD - icon appear when a non-blank medium is inserted - vanishes on medium removal 3. USB stick - for each mountable filesystem, an icon appears under "Removable devices" - formatting a partition with a non-mountable filesystem/blank removes the entry - formatting with a mountable FS (re)adds the entry Reviewers: #frameworks, broulik, ngraham, apol Reviewed By: broulik Subscribers: apol, anthonyfieroni, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D14661 M +20 -3 src/solid/devices/backends/udisks2/udisksmanager.cpp https://commits.kde.org/solid/8e9fc89918c4a8817b624a61e0d2d32d349722cc
Hello, now in Solid 5.50 the problem is solved partially. When mount CD/DVD and then unmount it, the Dolphin icon in the side bar disappears but the device manager icon stays in the system tray and there's no way to remove it. The only way is to restart the system. After unmounting CD/DVD we get this with no option to exit from this notification. The icon is always there: https://s15.postimg.cc/886itqnmz/image.png With Anthony Fieroni's patch there isn't such problem. When unmounting CD/DVD both icons disappears immediately - the one in Dolphin's side bar and the one in the system tray. Please fix this annoying behaviour. Thank you.
I can confirm the problem described in comment 10 on Arch Linux + frameworks 5.50 when I mount the ISO image using cdemu. When I use Gnome disks ("disk image mounter" in dolphin context menu) to mount the ISO instead cdemu a new entry appears in the side bar of Dolphin under "Devices" instead under "Removable devices" and no related entry appears in device notifier applet.
(In reply to Nick Stefanov from comment #10) > Hello, > now in Solid 5.50 the problem is solved partially. When mount CD/DVD and > then unmount it, the Dolphin icon in the side bar disappears but the device > manager icon stays in the system tray and there's no way to remove it. Please be more specific. Physical CD/DVD drive or iso image? Please provide the output of "solid-hardware5 details" for the relevant UDI, both mounted and unmounted.
Umounting mounted disk image (e.g. .iso file), as the title says.
I don't know how to get udi solid-hardware5 details. Can you help with this?
Check solid-hardware5 list, it lists all your devices, most like one of those that start with /org/freedesktop/UDisks2
Thank you very much :) Here is the output without mounted image: https://pastebin.com/TQxwzUpD And with mounted ISO: https://pastebin.com/sUNYGNWB
You need to run "solid-hardware5 details <UDI>", e.g. "solid-hardware details /org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM" Run it after mounting and after unmounting, and, *please*, give your logs a speaking name. Also run "sudo losetup -a" after mounting and unmounting.
I see, sorry :) Here it is with no mounted image: https://pastebin.com/D6jfZaqm And with mounted image: https://pastebin.com/bnctGbM6 sudo losetup -a gives no output no matter if image is mounted or not. What do you mean with "speaking name"? English is not my native language and for me is difficult to understand, sorry.
The logs still do not provide the required information, as you used the wrong UDI. CDEmu seems to create new virtual drives when mounting images. Make sure you use the UDI matching the drive you are currently using. check "solid-hardware5 list | grep CDEmu" for possible UDIs. Speaking name - e.g. "solid-hardware5_details_after_mounting.txt"
The "solid-hardware5 list | grep CDEmu" command gives only two possible devices: udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM_1' udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM' I already gave you logs for udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM. Do you need the logs for udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM_1? Actually this problem is present everywhere. Can't you get the needed info from your system?
Created attachment 114883 [details] solid-hardware5_details_before_mounting
Created attachment 114884 [details] solid-hardware5_details_after_mounting
I rebooted and the "solid-hardware5 list | grep CDEmu" command now gives only one possible device: udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM' When I mount an image after the reboot, the command gives again two possible devices: udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM_1' udi = '/org/freedesktop/UDisks2/drives/CDEmu_Virt_2e_CD_2fDVD_ROM Now I'll attach logs after the reboot.
Created attachment 114885 [details] solid-hardware5_details_before_mounting_after reboot
Created attachment 114886 [details] solid-hardware5_details_after_mounting_after reboot_CDEmu_Virt_2e_CD_2fDVD_ROM
Created attachment 114887 [details] solid-hardware5_details_after_mounting_after reboot_CDEmu_Virt_2e_CD_2fDVD_ROM_1
The solid core is working as expected, but some of its signals are not handled in the solid dataengine, which the applet relies on.
(In reply to Stefan Brüns from comment #27) > The solid core is working as expected, but some of its signals are not > handled in the solid dataengine, which the applet relies on. The plasma engine explorer shows events (source added/removed) are generated by the hotplug data engine, and the solid dataengine shows the current values. Next step look into the applet itself why is does not react on the events (it is hooked to both hotplug and solid dataengine as sources).
You can look at Fieroni's patch. It works perfect for me and I'm using it for two months already and without a single problem :)
(In reply to Nick Stefanov from comment #29) > You can look at Fieroni's patch. It works perfect for me and I'm using it > for two months already and without a single problem :) That does not "fix" the problem, but just has the desired effect by chance. It breaks other use cases. It removes the whole device as soon as the filesystem is unmounted.
And why removing the whole device as soon as the filesystem is unmounted is a problem?
(In reply to Nick Stefanov from comment #31) > And why removing the whole device as soon as the filesystem is unmounted is > a problem? Because the partition is the same device. If you do not understand the difference, please educate yourself.
Git commit 61b2b173e8d68623a3681fd27c0ad0348bf41191 by Stefan Brüns. Committed on 24/09/2018 at 13:27. Pushed by bruns into branch 'master'. [Device Notifier] Avoid accessing attributes of stale UDIs Summary: When a Solid device is removed (e.g. a CD is ejected) the notifier tries to read the attributes although the Source for the UDI has just vanished. Fixes several QML error messages, i.e. "TypeError: Cannot read property '...' of undefined" and "Unable to assign [undefined] to QString". Apparently these errors also have the effect of items showing outdated state, i.e. optical media still being shown after ejecting it. Test Plan: 1. insert optical medium 2. eject Without the changes, the item was stuck Now, the item is removed as soon as the medium is ejected Also, no more errors are logged for the devicenotifier Reviewers: #frameworks, broulik Reviewed By: broulik Subscribers: ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D15687 M +6 -5 applets/devicenotifier/package/contents/ui/FullRepresentation.qml M +8 -0 applets/devicenotifier/package/contents/ui/devicenotifier.qml https://commits.kde.org/plasma-workspace/61b2b173e8d68623a3681fd27c0ad0348bf41191
Thank you :)
@ Nick Stefanov - please confirm and set to fixed eventually.
Hello Stefan Brüns, Unfortunately it doesn't work. I can't see any difference in the behaviour before and after.
(In reply to Nick Stefanov from comment #36) > Hello Stefan Brüns, > > Unfortunately it doesn't work. I can't see any difference in the behaviour > before and after. Are you sure you use a plasma version including the changes? There is no release yet where this is contained in. If yes, please install plasmaengineexplorer and plasmoidviewer from the plasma SDK. In the plasmaengineexplorer, select the hotplug engine. A '/org/freedesktop/UDisks2/block_devices/sr<N>' device/source should appear when the disk is inserted and vanish when the disk is ejected. There is also the possibility CDEmu is not working as you might expect. If it does not "eject" the disk image when it is removed, solid still sees a medium inside the drive, and thus shows the entries for the medium.
I use CDEmu with other desktop environments including KDE 4 and it works perfectly. This problem exists only in Plasma. For testing the changes I got the files FullRepresentation.qml and devicenotifier.qml from here: https://cgit.kde.org/plasma-workspace.git/tree/applets/devicenotifier/package/contents/ui and replaced them. I also restarted the machine.
(In reply to Nick Stefanov from comment #38) > I use CDEmu with other desktop environments including KDE 4 and it works > perfectly. This problem exists only in Plasma. Thats not what I asked ...
I'm regular user and these thigs are difficult for me. You asked me how I tested the changes and I answered.
Now I tested with plasmaengineexplorer. When I mount an image a /org/freedesktop/UDisks2/block_devices/sr3 appears: https://i.imgur.com/qIR9yt5.png When I unmount the image, the /org/freedesktop/UDisks2/block_devices/sr3 disappears but the icon in the system tray remains: https://i.imgur.com/LAh2b3k.png
Please try to run the notifier using plasmoidviewer and see if it works there: $> plasmoidviewer -a org.kde.plasma.devicenotifier
No, it doesn't work. When I moint an image it appears in the main window: https://i.imgur.com/Fz5yWSY.png When I unmount it, the item in the Dolphin's device section disappears but the icon in the system tray and in the plasmoidviewer remains: https://i.imgur.com/xywlun8.png
The "virtual disk" is still inside the virtual drive. You can copy it with k3b. If you want to have the image "ejected" whenever it is unmounted, talk to the CDEmu devs, there is nothing we can do here. Everything works exactly as designed. Not our bug.
K3B uses Solid as well, so the problem remains there, about me.
(In reply to Anthony Fieroni from comment #45) > K3B uses Solid as well, so the problem remains there, about me. Press the eject button! Solid is just telling the truth, you have a CD drive with a medium in it.
But he umounts image, there is noting to press, virtual image is gone.
(In reply to Anthony Fieroni from comment #47) > But he umounts image, there is noting to press, virtual image is gone. Unmounting means you can no longer access the file system. You can still access the drive and the inserted medium, e.g. with k3b. The entry will vanish as soon as there no longer is a medium in the drive. CDEmu emulates a CD/DVD drive. If the emulation is incomplete/broken, this is not solids fault.
The image IS ejected but there is icon with virt. CD/DVD ROM in the sys tray and there isn't eject icon. Why? Because the disk is ejected. CDEmu works just fine in Cinnamon, LXDE, Gnome and Xfce. Where is the problem then? In CDEmu? No it isn't.
Ok, if you click on it, when it's ejected or umount, will it mount and usable again? If yes that's good because you can use it again easily, if not that's a problem.
Antoni, no, tehere isn't a way to remount. Just an option to Copy it with K3b wich doesn't work for obvious reasons: https://i.imgur.com/okpVuQT.png CDEmu works ok in KDE 4 too. Stefan Brüns, do you wish to record a clip for you with KDE 4 where all works as expected? With the exactly the same version of CDEmu?
So looks like device has still have CD/DVD reads ability/ies https://phabricator.kde.org/source/k3b/browse/master/libk3bdevice/k3bdevicemanager.cpp$388-391 that's why K3b shows it?
(In reply to Anthony Fieroni from comment #52) > So looks like device has still have CD/DVD reads ability/ies > https://phabricator.kde.org/source/k3b/browse/master/libk3bdevice/ > k3bdevicemanager.cpp$388-391 > that's why K3b shows it? More or less, K3B tells the device notifier (via /usr/share/solid/actions/k3b_*.desktop) to show it.
In other words, the bug in Solid has been fixed, and if there is a remaining issue here, it's in k3b, right?
I'm not sure that bug is in k3b.
In fact I just removed K3b and now everything works as expected. It's strange however that in KDE 4 all works perfect without need of K3b uninstallation.
(In reply to Nick Stefanov from comment #56) > In fact I just removed K3b and now everything works as expected. It's > strange however that in KDE 4 all works perfect without need of K3b > uninstallation. Cinnamon, LXDE, Gnome and KDE4 do not integrate with K3B.
Seems like this fixed in Solid, so please file a new bug against K3B. Thanks!
Created attachment 115354 [details] After doing "Release" from Dolphin
Its not a bug in K3B, but in CDEmu. I have just verified "Releasing" (aka unmounting) a *real* CD from a real drive, and it stays in the device notifier, giving the option to remount, copy with k3b or open in various programs (implicitly remounting it). When I press eject (either in the device notifier, or from the dolphin context menu), it vanishes.
semi-relatedly: I bet we could get people to stop using cdemu if we had native ISO mounting support in Dolphin (Bug 175051).
Created attachment 119390 [details] Handle media change events for devices that are connected after initial introspection (In reply to Stefan Brüns from comment #60) > Its not a bug in K3B, but in CDEmu. I have just verified "Releasing" (aka > unmounting) a *real* CD from a real drive, and it stays in the device > notifier, giving the option to remount, copy with k3b or open in various > programs (implicitly remounting it). > > When I press eject (either in the device notifier, or from the dolphin > context menu), it vanishes. Hello, this bug report was linked in a bug report opened against CDEmu. However, as far as I can tell, this is an issue with Solid, because I can also reproduce it with my USB optical drive (ASUS BW-12D1S-U) - if I connect it to system after Plasma session has been started. More specifically, the issue is that in udisks2 backend, Manager::slotMediaChanged() is connected to udisks2' PropertiesChanged signal only for UDIs that are present during the initial Manager::allDevices() call (which probably happens at session startup). For devices that are connected later (such as a CDEmu virtual device, or an external USB drive), this connection is not established. Consequently, the medium change is not properly detected and available Content is not updated, and so its stale content triggers the K3b Device action due to content-based predicate still evaluating as true. I have attached a proof-of-concept patch that seems to fix the issue for me. It is based on assumption that addition of "org.freedesktop.UDisks2.Block" interface means that a new device has been added, and it that case checks if it is an optical device (in the same way as is done in Manager::introspect()).
Thanks for the patch! Can you submit it on https://phabricator.kde.org? using the `arc` command-line tool is the preferred method (see https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches) but seeing as you have a diff, you can also use the web interface (see https://community.kde.org/Infrastructure/Phabricator#Posting_a_Patch_using_the_website). Thanks again!
Patch submitted to Phabricator: https://phabricator.kde.org/D20508
Thank you! I'll keep an eye on that.
Will you inform us when the patch goes upstream?
I'm not a software developer, but I applied Rok's patch on Arch Linux and it fixes the problem when unmounting ISO images.
(In reply to Patrick Silva from comment #67) > I'm not a software developer, but I applied Rok's patch on Arch Linux and it > fixes the problem when unmounting ISO images. Thanks Patrick. Would you be able to leave that comment on the review page too? https://phabricator.kde.org/D20508
This bug persists. Operating System: Arch Linux KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0
Yes, it's still here.
Hello, The bug is still here but this time without k3b installed. It appeared some days ago. When you discover k3b is the problem I uninstalled it and everything was working fine till the day before yesterday or one dy before it. I check 3 times if I have k3b installed - it's not installed but the problem is here.
Hello, The bug is still persist Operating System: Manjaro KDE KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0
And I not have k3b installed on my system
I figured out something - the problem occurs if I try to unmount the image from the panel's Device Notifier or from the Dolphin entry in the sidebar. If I eject it from CDEmu manager it unmounts properly. But it's irritating every time to start CDEmu and unmount...
I experience the same behaviour with gcdemu. The problem is obviously in Plasma. Please, fix it for it's a very irritating problem.
Anybody?
Kai, didn't you investigate this recently?
I noticed something interesting - if I unmount the previously mounted disk via device notifier or Dolphin and I close Dolphin, the mounted image is gone from the side bar's devices section after I open Dolphin again. But the device isn't released and no image can be mounted until I unmount the previous image via CDEmu or restart.
(In reply to Nick Stefanov from comment #78) > I noticed something interesting - if I unmount the previously mounted disk > via device notifier or Dolphin and I close Dolphin, the mounted image is > gone from the side bar's devices section after I open Dolphin again. But the > device isn't released and no image can be mounted until I unmount the > previous image via CDEmu or restart. I have just reported an issue that seems related to your comment. See bug 412945.
Plasma 5.17 - the bug is still here in .
Plasma 5.17.1 - the bug is still here and it's still that annoying.
Plasma 5.17.2 - the bug is still here.
Sure, if someone fixes this bug, the status will change to FIXED. There is no need to state the obvious multiple times.
But it's needed to remind that KDE is the only one DE with such a ridiculous bug but nobody cares.
It is not.
Show me one? There isn't but KDE.
I said it is not neccessary to constantly remind developers about a minor inconvenience. Just by replying to this bug report alone I wasted several minutes I could have spent doing something productive. If the bug is fixed, the bug report will be marked as such and closed, otherwise it might potentially even still be in Plasma version 23478923423.
Just as I said - nobody cares about this ridiculous bug including you.
it's bacause things like this bug that open source software probably will never be a good alternative for desktop users. fortunately https://phabricator.kde.org/D20508 was accepted and probably this annoying bug will be fixed in frameworks 5.65.
rokmandeljc and Nate, thank you!
Git commit 4aa39aed1bd6c81dbf0d6dc9d312af5340f7caab by Nate Graham, on behalf of Rok Mandeljc. Committed on 12/11/2019 at 17:38. Pushed by ngraham into branch 'master'. [udisks2] fix media change detection for external optical drives Summary: If an external optical drive is connected after Solid does its initial introspection, the resulting UDI does not get a mediaChanged signal/slot connection, and thus fails to react to the media change. Consequently, disc content is not properly updated after the medium is ejected, causing bug #394348. This patch assumes that an addition of "org.freedesktop.UDisks2.Block" interface means that a new device has been added; in this case, it performs Device::mightBeOpticalDisc() check to add the slotMediaChanged() connection. FIXED-IN: 5.65 Test Plan: Test steps: 1. Start KDE Plasma session. Make sure K3b is installed. 2. Connect an external USB optical drive. 3. Insert the disc 4. Observe Device action notifications for the inserted disc. 5. Eject the disc. 6. Observe Device action notifications. Behavior before patch: after disc is ejected, a "Copy with K3b" action remains available for the drive See: https://bugs.kde.org/show_bug.cgi?id=394348 Behavior after patch: after disc is ejected, no actions remain available for the drive Reviewers: bruns, broulik, dfaure, #frameworks, ngraham Reviewed By: ngraham Subscribers: ngraham, bugseforuns, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D20508 M +12 -0 src/solid/devices/backends/udisks2/udisksmanager.cpp https://commits.kde.org/solid/4aa39aed1bd6c81dbf0d6dc9d312af5340f7caab
Nate, At the moment the bug is present with K3B uninstalled. Uninstalling K3B used to resolve this bug some time ago but no more. I hope this patch will address the new behaviour.
Today KDE Frameworks 5.65 came to Arch. I can confirm the problem is NOT fixed. There aren't any change in the behaviour at all... I tried uninstalling K3b to no avail.
Here's the video of the problem: https://youtu.be/G6WwSZWyTlA On every other DE the mounted disk disappears after it's being ejected either from the side the bar or system tray. On KDE it's still there and we can't mount another image till it's ejected with CDEmu. So unfortunately the newest patch does nothing.
Ah, almost forget - this is a brand new user profile.
(In reply to Nick Stefanov from comment #95) > Ah, almost forget - this is a brand new user profile. Can you try reproducing this with a minimal clean installation (preferably a VM that you can share if necessary)? The fix that landed in KDE Frameworks 5.65 (Comment #91) is for the situation when the disc is ejected from the device (CDEmu virtual device is empty) but the disc-related actions remain in Plasma "Device Notifier" menu. I tested with Plasma on today's installations of Fedora Rawhide and Arch Linux (both use 5.65), and this now seems to work as expected. However, the issue in your video appears to be a different one: you are trying to eject the disc from CDEmu device, but for some reason that does not work, and you are left with a loaded device. That is why the CDEmu shows that device is (still) loaded, and why you can re-mount the device without having to reload the disc. The problem is, I cannot reproduce this on Fedora Rawhide or on Arch Linux - in both cases, ejecting also seems to work as expected. One thing that strikes me as odd is that in your video, the actions in the Device Notifier menu are "Click to access this device from other applications", followed by "Click to safely remove this device". And in Dolphin, you have "Safely remove". On my installation, the actions are "Click to access this device from other applications", followed by "Click to eject this disc". Similarly, Dolphin has "Mount/Release" and "Eject" actions in my case.
I can confirm the behavior shown in the video from comment 94 on my Arch Linux. However everything works as expected on Neon unstable edition based on Ubuntu 18.04.
I'm on Arch too and this is the problem I described in my very first post in this thread - the disk is doesn't completely ejected and I have to eject it again with CDEmu. It's still there and it's shown on Dolphin side panel and on the Devices widget and I can't mount another disk until I egect the previous disk via CDEmu. I have a clean installation backup and the problem is there too. It used to work properly a long time ago but in last two years it's completely broken. And we are going to LTS - with scrambled icons on almost every restart and ISO ejecting problems. There isn't a single DE with such ridiculous problems. I'm a hardcore KDE fan but this really pisses me off...
I just tried it myself with the small slex-ipxe.iso [1] and cdemu 3.2.3 on Operating System: Manjaro Linux KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.0 Kernel Version: 5.4.7-1-MANJARO on the testing repository branch and I can not reproduce your issue Nick. I wonder if this an Arch Linux issue as Patrick says it worked on KDE Neon Unstable -- though Manjaro uses the Arch repository. [1] http://ftp.sh.cvut.cz/slax/Slax-9.x/slax-ipxe.iso (0.88 MB)
It's still here on my end :(
I have to correct my comment above: I wanted to do demonstrate it to you with a recording done with a second and clean user account but then I could indeed reproduce the bug. Sometimes it also happens that Dolphin just crashes when I try to unmount the iso. After restarting Dolphin, now I got the mount symbol twice in the places panel.
I started Dolphin via the Konsole and get the following output if I try to unmount the ISO, though nothing happens: ``` QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter ```
I tried your ISO with a clean profile and the problem is still there. It's obvious the problem is in solid code. It's not our installations fault.
I did some more testing: 1) I rebooted due to an update 2) Downloaded and compiled latest master of Dolphin (for gdb and debug build) and tested it there: -> Worked fine for both the self compiled Dolphin and packaged Dolphin 3) Umount the ISO. 4) Switched to another user and tested it again: The bug occurs. 5) Logged out and logged back in with the former user account: Bug now occurs now here too. The QObject::disconnect: Unexpected null parameter seem to be unrelated to this bug, though.
Thanks for investigating it. It's sad the devs don't care though...
@Postix, thank you for thorough description of the test procedure. I am now able to reproduce the issue on Fedora Rawhide using two separate user accounts, one after the other: 1. log in as user A 2. ensure that CDEmu daemon is autostarted and virtual device is created (e.g., by querying device status) 3. log out 4. log in as user B 5. auto-start CDEmu daemon by loading virtual device with ISO image -> instead of "Optical disc", Device Notifier shows "Storage Volume" and ejecting does not work What is happening is that when user A logs out from Plasma, their CDEmu daemon instance (which was auto-started via D-Bus autostart mechanism) is not shut down (contrary to, for example, what happens when logging out of a GNOME session). So the above test steps result in two instances of CDEmu daemon running, one for each user, and each owning one virtual device. This is not an issue per-se (it was designed to work this way), but I think what is causing the problems here is that both virtual devices end up with the same serial number (which is based on number of devices, but only within a daemon instance). For a quick test I patched CDEmu to use random serial numbers, and the issue went away. I will come up with a proper fix in the coming days (I would like to preserve stability of serial numbers and resulting /dev/disk/by-id symlinks, at least for single-user environments, so the serials should probably be based on global device counter, obtained from the vhba kernel module...) and push a new CDEmu release. @Nick and @Patrick, do you use a multi-user setup? Or rather, when you observe the issue, do you have multiple CDEmu daemon instances running - intentionally or unintentionally?
@ Rok Mandeljc Nope, I created the second profile just for testing the problem. I always use only one user profile but the problem is present on my end too :)
Can you still check if you have two instances running - what is the output of "ps aux | grep cdemu-daemon"? I checked the Arch linux package of cdemu-daemon, and it seems it also includes system service for running the daemon on system bus. Do you have this service (cdemu-daemon.service) enabled? If so, this is the source of second daemon instance, and what is triggering the issue in your case...
Thank you very much for your help :) The output is: https://pastebin.com/cMi4p7sE Yes, cdemu-daemon.service was enabled. I disabled but now I can't mount CD/DVD images via double click or application chooser. Even the service menu has disappeared. It's now possible only when I start CDEmu manually, open it's GUI and mount the image via browsing. It's very inconvenient. And yes, if mount an image that way, the bug is not present and I can unmount it via the Devices widged or from the Dolphin's side panel.
@Rok Mandeljc I have two user accounts on my system and cdemu-daemon.service is enabled here. Output of ps aux | grep cdemu-daemon: root 487 0.0 0.1 328440 10152 ? Ssl 20:54 0:00 cdemu-daemon --ctl-device=/dev/vhba_ctl --bus=system --num-devices=1 --audio-driver=null --logfile=/var/log/cdemu-daemon.log stalker 3041 0.0 0.0 6324 2332 pts/1 S+ 20:59 0:00 grep cdemu-daemon
(In reply to Nick Stefanov from comment #109) > Thank you very much for your help :) > > The output is: > > https://pastebin.com/cMi4p7sE > > Yes, cdemu-daemon.service was enabled. I disabled but now I can't mount > CD/DVD images via double click or application chooser. Even the service menu > has disappeared. It's now possible only when I start CDEmu manually, open > it's GUI and mount the image via browsing. It's very inconvenient. And yes, > if mount an image that way, the bug is not present and I can unmount it via > the Devices widged or from the Dolphin's side panel. This sounds like misconfiguration on your side - the system-bus daemon instance should not be required for regular desktop use (it is intended only for headless systems that do not have session bus available due to lack of DE session). The KDE CDEmu manager (kde_cdemu), which is what you are probably referring to as "the GUI" has hard-coded use of session-bus instance, while the official clients (cdemu-client, gcdemu) allow switching between system and session bus, but they default to session bus. The "Open with... CDEmu client" context menu action for ISO image uses cdemu-client; so if this stopped working, you might have manually configured the cdemu-client to use system bus at some point. Do you have one of the following config files on your system: /etc/cdemu-client.conf or ~/.cdemu-client? Can you check if running "cdemu status" from command-line (as regular user) works with cdemu-daemon.service disabled? At any rate, KDE/solid does not seem to be at fault here (aside from not handling colliding device serial numbers), so this bug should be closed. The device serials collision will be fixed in CDEmu, but you should also configure your systems to use only session-bus instance of CDEmu daemon (and perhaps the Arch packages should be adjusted to not provide the support for system-bus instance by default).
I have cdemu-client installed but when I stop cdemu-daemon.service and the "Open with... CDEmu client" context menu action disappears. I checked for /etc/cdemu-client.conf or ~/.cdemu-client but there aren't such files. Here's the output of "cdemu status" with cdemu-daemon.service disabled: [mozo@mozo ~]$ cdemu status Devices' status: DEV LOADED FILENAME 0 False "you might have manually configured the cdemu-client to use system bus at some point." I'm shure I didn't do that but how can I fix this?
(In reply to Nick Stefanov from comment #112) > I have cdemu-client installed but when I stop cdemu-daemon.service and the > "Open with... CDEmu client" context menu action disappears. I checked for > /etc/cdemu-client.conf or ~/.cdemu-client but there aren't such files. > > Here's the output of "cdemu status" with cdemu-daemon.service disabled: > [mozo@mozo ~]$ cdemu status > Devices' status: > DEV LOADED FILENAME > 0 False > > "you might have manually configured the cdemu-client to use system bus at > some point." > > I'm shure I didn't do that but how can I fix this? Hmm, I guess something else is going on then. The "Open with..." action shows up as expected with cdemu-daemon.service disabled on my test Arch setup. As it should, since it is controlled only by /usr/share/applications/cdemu-client.desktop file and is (or at least it should be) independent of the service. It does disappear from the "Open with..." if I make it a default application for the file type (by right clicking on file, selecting Properties, File Type Options, and then adjusting the order there). But in that case, the default action is on top of the context menu (above "Open With..."), and using either that or double-clicking on the image works. When you said that double-clicking does not work, did you mean that "Open with CDEmu client" default action is gone, or it does not load the image?
Hmm, my fault, I'm sorry. Now I realized that It desappears for the Linux Mint 19.3 ISO, but it's there for other images. There isn't a way to add it for Linux Mint ISO though, which is a different MIME problem I suppose. Now with cdemu-daemon.service stopped everything is working fine except some images that are not correctly recognized like Mint's ISO. Thank you very much :)
Hmm, yes, the Linux Mint ISO is recognized as "Apple Disk image" and therefore the problem.
(In reply to Nick Stefanov from comment #115) > Hmm, yes, the Linux Mint ISO is recognized as "Apple Disk image" and > therefore the problem. The image in question does indeed seem to contain Apple descriptors as well (it is probably a ISO/HFS hybrid). For now, you could try adding application/x-apple-diskimage to MimeType list in /usr/share/applications/cdemu-client.desktop file.
Thank you very much this workaround is working great! Thank you!
cdemu 3.2.4 solved this issue on my Arch Linux. \o/ Thank you all.
Confirmed fixed.