OpenMandriva Lx release 6.0 (Vanadium) Rock for x86_64
Desktop environment (KDE, LXQT…):
KDE Plasma
Description of the issue (screenshots if relevant):
I saw this a month or two ago too & never really saw a resolution for it so I thought I’d post it (see image below). A system update appears with other updates. I allow the update to run but then it freezes & just says Updates (fetching…).
This isn’t a network issue on my side since other updates run and I have a high-speed fiber connection but for some reason this update looks as if it never downloads or installs properly. At one point it even queries for password so it can install.
Is this a known issue?
Is it actually completing but just not displaying properly?
Thanks for any help.
I have a script that contains the WARNING that i run each day: sudo dnf clean all ; dnf clean all ; dnf repolist  sudo dnf distro-sync --refresh --allowerasing
But, some packages do not update that way so I run the other update system, which is the one that hangs. Start it by clicking the following icon
Here’s what I get when I run the script:
repo idrepo name
brave-browser Brave Browser
rock-updates-x86_64 OpenMandriva Rock - x86_64 - Updates
rock-updates-x86_64-extra OpenMandriva Rock - Extra - x86_64 - Updates
rock-updates-x86_64-non-free OpenMandriva Rock - Non-free - x86_64 - Updates
rock-x86_64 OpenMandriva Rock - x86_64
rock-x86_64-extra OpenMandriva Rock - Extra - x86_64
rock-x86_64-non-free OpenMandriva Rock - Non-free - x86_64
I did see some old files be removed:
22 files removed
So after I ran that script, I went and clicked the “update” icon again and I see the following again:
The version of Discover that is in the Rock repo uses packagekit, which is not a very good package manager. It can do flatpaks pretty well, but I wouldn’t trust it with distro packages. If you have any flatpaks installed they can be updated from the terminal with flatpak update .
I don’t trust Discover with distro package updates or flatpak updates. Best to follow @LeeTalbert’s advice when updating flatpaks. For distro packages, I use System Update.
The only thing I use Discover for is updating any Plasma themes, icons, widgets and so on that I am currently using. For instance, I use the Weather Underground widget to keep track of the weather conditions, a requirement during tornado season (right now). This useful widget not installed by default.
Sometimes, Discover fails with Plasma themes, icons, widgets and so on. Then the only option is to uninstall the components that quit working, do a fresh download, and install them again.
Bottom line, Discover is very unreliable on a good day. I am on Rome. Taking a wild guess, the results should be close to the same on Rock.
I’ve stopped running Discover (didn’t even know what that program was before) and I’ve created a script that I run daily that takes care of everything.
sudo dnf clean all ; dnf clean all ; dnf repolist
sudo dnf distro-sync --refresh --allowerasing
flatpak update
It works great.
There are two confusing parts to this:
Discover is located right there on the main menu by default (see image 1 below)
Discover is the only app that shows that strange package update (see image 2 below)
I’m not sure why that “System upgrade” item shows up there & nowhere else. Very odd. and, apparently that system upgrade isn’t even actually available.
Thanks to everyone who replied. It all helped me get to my daily script (above).
Discover is a KDE Plasma program. They would like to see it do all everyone needs, but in reality it fails. Most of us would like to see it removed, but it is the only way I know of to install and update Plasma add ons like widgets and effects. It also works pretty good to find flatpaks and install them, so we leave it in.
I do find that it will allow me to see that there is a new update my bios for most motherboards. That is what I usually find in the System section. I still tend to go to the manufacturer and download the new bios and manually install it.
FWIW discover should be fixed in Cooker – I nuked the PackageKit backend and replaced it with a proper native DNF backend that should do the right thing. Needs more testing though, if someone is brave.
