I am having problems with updates hanging and failing to update however long I wait. In another post running “dnf remove plasma-discover-snap” was suggested and this worked but the problem is plasma-discover-snap keeps coming back.
There are two interim solutions until the underlying snap issue is corrected by the KDE folks.
- Update everything from the command line
sudo dnf update --refresh && sudo snap refresh & sudo flatpak update - Keep removing the snap addin for discover.
I wouldn’t be aware that there was an ongoing issue with snaps in Discover, as I never use it for updates. I can’t recall the last time I used it to install anything to be honest; have we got to the root cause of the snap update issue?
Could also throw in an exclusion and hopefully stop the problem package coming back:
sudo dnf update --refresh --exclude=plasma-discover-snap && sudo snap refresh && sudo flatpak update
(Take out the sudo snap refresh part if you don’t actually use snap.)
To see what brought it back, run
sudo dnf history list --contains-pkgs plasma-discover-snap
sudo dnf4 history list plasma-discover-snap
It seems that the only way that the snap support gets install if if the user installs snap. Did you install snap?
To make sure plasma-discover-snap remains uninstalled, add the following line to /etc/dnf/dnf.conf
excludepkgs=plasma-discover-snap
Create the file if it doesn’t exists already.
For some reason, installing snapd pulls in plasma-discover-snap as a weak dependency, but I can’t find where that is declared in any of the rpm packages.
No I did not install snap and its only after the last couple of KDE Plasma updates that this problem came up
all it shows is dnf remove plasma-discover-snap 2026-07-22 09:22:33
How about sudo dnf4 history list plasma-discover-snap ? Could be that the package originally got installed via dnf4.
The claim by fedora kde packagers is that snap rpms aren’t install by default.
But we have reports of people seeing that discover snap package being installed.
What does rpm -qa | grep -i snap report?
phil@fedora:\~$ sudo dnf4 history list plasma-discover-snap
\[sudo\] password for phil:
ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------------------------------------------------------------------
225 | | 2026-07-21 10:49 | I, U | 113 <
223 | | 2026-07-19 13:08 | I, U | 507 ><
197 | | 2026-05-21 10:59 | I, U | 140 ><
172 | | 2026-04-20 18:32 | Install | 7 >
phil@fedora:\~$
phil@fedora:\~$ rpm -qa | grep -i snap
**snap**py-1.2.2-2.fc43.x86_64
**snap**d-selinux-2.76-0.fc43.noarch
**snap**-confine-2.76-0.fc43.x86_64
**snap**d-2.76-0.fc43.x86_64
**snap**d-glib-1.72-1.fc43.x86_64
**snap**d-qt-1.72-1.fc43.x86_64
phil@fedora:\~$
This package pulls in the discover snap package as a weak dep.
So you did install snap.
How can I remove snap?
run
sudo dnf4 history info 225
sudo dnf4 history info 223
sudo dnf4 history info 197
sudo dnf4 history info 172
Use sudo dnf remove <package> for each snap package you found installed.
phil@fedora:\~$ rpm -qa | grep -i snap
**snap**py-1.2.2-2.fc43.x86_64
phil@fedora:\~$ sudo dnf remove snappy-1.2.2-2.fc43.x86_64
Failed to resolve the transaction:
Problem: installed package kpipewire-6.7.3-2.fc43.x86_64 requires libavcodec.so.61()(64bit), but none of the providers can be installed
* installed package kpipewire-6.7.3-2.fc43.x86_64 requires libavcodec.so.61(LIBAVCODEC_61)(64bit), but none of the providers can be installed
* installed package libavcodec-free-7.1.5-1.fc43.x86_64 requires libsnappy.so.1()(64bit), but none of the providers can be installed
* installed package plasma-desktop-6.7.3-2.fc43.x86_64 requires kpipewire(x86-64), but none of the providers can be installed
* conflicting requests
* problem with installed package
All snap* deleleted o/k but but failed with snappy
Snapper is not part of the snap stuff, so you have cleanup sucessfully.
You can see what snappy does with rpm -qi snappy which says:
Description :
Snappy is a compression/decompression library. It does not aim for maximum
compression, or compatibility with any other compression library; instead, it
aims for very high speeds and reasonable compression. For instance, compared to
the fastest mode of zlib, Snappy is an order of magnitude faster for most
inputs, but the resulting compressed files are anywhere from 20% to 100%
bigger.