OpenMandriva Lx version:
25.01 Rolling (Rome) upgrading to 25.02 Rolling (Rome)
Desktop environment (KDE, LXQT…):
KDE Plasma 6.2.5 upgrading to KDE Plasma 6.3.1
Description of the issue (screenshots if relevant):
When installing the updates upon restart, no indicator is given as to what is happening in the background. It took about 3-5 minutes on a Samsung 870 EVO SSD. Most would force restart after a minute if it seemed the system hung (I noticed the HDD light still working and instead hit the ‘Esc’ key to see the progress - it would be preferable to be dumped into console mode to view progress rather than stare at a desktop wallpaper with no indication as to what is happening).
After update finished installing and automatically restarted, I got dumped into emergency console mode. This was my “oh crap, I should have configured Timeshift before running the updates” moment. However, after hitting Ctrl+Alt+Del and attempting the boot again, OpenMandriva magically started working. My initial reaction was to wipe the partition because I really don’t feel like spending several days troubleshooting a failed update.
Perhaps install Timeshift by default and recommend people utilize it.
Relevant informations (hardware involved, software version, logs or output…):
No, this is not the case. This is a rolling release and although KDE tries to make Discover do all things, it fails. OpenMandriva is unique and has to be treated as such. Like any other rolling release, it has to be updated in a specific way. Any deviation will cause issues.
sudo dnf clean all ; dnf clean all ; dnf repolist ; sudo dnf distro-sync --refresh --allowerasing 2>&1| tee dsync2-log.txt
That’s going to cause a lot of new-user issues, because everyone’s first thought is “update means update” no matter where you see it. (I admit I have the habit of NOT using Discover for updates, because on Fedora it tends to stall halfway.)
I come from PCLinuxOS (another Mandrake descendant), which is rolling-only. It uses Synaptic as the package manager. Synaptic is ancient and ugly, but it works every time. In six years I have never had to visit the CL for an update. I am a bit at a loss as to why OM’s update function is still CL-only; doesn’t seem like it’s necessity for being rolling.
ETA because I hit the wrong key and it posted too soon:
It’s actually pretty rare for people to visit a forum or homesite before trying a distro. So awareness is not going to be there. Seems to me a reasonable workaround would be a script on the default desktop, obvious enough to get the new user’s attention. (I think all of us have stopped reading those “Welcome” cards, because most are not useful.)
Most distros have welcome cards. We have a Welcome app. OM-Welcome is the only safe place to add repos and we make it a matter of ticking boxes to do so. For many browsers, the repos are right there too. You can click the updater in the OM-Welcome app and never to it from the command line. You can set up DnfDrake to check for updates and alert you when they are ready. Nvidia drivers are a 1 click install from the app as well. Our devs put a lot of effort into that app.
I noticed the extra work Also that it installed the correct NVidia driver without troubling me about it, which was nice.
To be clear, as an old DOS-head I have no particular objection to the CL (in my Fedora setup, updates have been CL, up-arrow for five years now, given Discover tends to fail on large updates) but in the present day it’s rather surprising to see as the Official Way on a desktop distro.
Lee: I’ll look more closely at the Welcome app. Yeah, I’m not a fan of Discover. (Nor of Neon, which committed seppuku first time I updated it.)
Addendum… as noted above I had DNFdragora install a few things. Then found they were not added to the main menu (and not knowing which of numerous files is the right one, was unsure how to add).
This led to a full reinstall because now DNF seemed to think it was busted – when asked to install something via CLI, it ignored me.
(The new working install is now enshrined in Timeshift, on a separate HDD.)
I did install Krita via Discover and that worked normally.
(The new Wacom driver is sooooo nice.)
Update via the CLI seemed to go okay.
But I’m now a bit at a loss as to what is the better way to install stuff.
[I dislike Discover. I’m used to Synaptic, and DNFdragora is pretty similar. But only if it works right!]
I suggest using the terminal to install rather than any ‘app store’. I don’t understand what is happening behind the scenes with Discover, but it has caused problems for me in the past so now I avoid it.
Flatpaks can be done with flatpak search and flatpak install and flatpak remove
OM repositories can be done with dnf se to search, dnf in to install, and dnf rm to uninstall.
So, do I have to install Dnfdrake? Because I looked, and apparently I do not have it. At least if I type dnf into the main menu search thingee, it does not come up. Just DNFdragora, which failed to complete an install of various programs (and in the process apparently broke CL-DNF).
Side thought: I am somewhat alarmed that what for average users is perhaps the single most critical subsystem, software and update management, which should be singularly robust, is instead rather… fragile.
From what I was told yesterday or the day before, dnfdrake does install by default now, but flatdrake does not, yet, for some reason. I don’t understand all I know about these things. Anyhow, on an older installation, you do need to install dnfdrake. It is a one click install in OM-Welcome or
OM package management is very robust not fragile at all. The problem was with Discover and Discover has been problematic for a lot of distros. The historical problem with Discover (and dnfdragora) in OMLx was that it used the wrong command to do system upgrades for Cooker and ROME.
That said today I see do not any problems with installing and removing packages with Discover or dnfdragora. And I am one the tests these things. Also I believe @bero has fixed the problem with system upgrading in Discover so that it uses the correct command. I am just getting ready to upgrade some systems with Discover and I will see how that goes. Edit: To my knowledge dnfdragora still uses the wrong command for system upgrades for Cooker and ROME, There are people working on correcting this.
To clarify: if the unwitting user can break the install by doing what seems entirely normal and expected, that is fragile. I doubt most users come here first for the correct how-to; linux is now generally good enough that we expect everything to Just Work when we do the obvious. (I am used to PCLinuxOS and Fedora, or LMDE if I have to; I don’t know what breaks in other distros.)
But I am glad to know that the issues are under scrutiny. For now my OM is a test system, so if something breaks it’s just annoying, not the end of the world. I do hope OM can become a regular for me, as I’m really pleased with OM’s performance and how nicely KDE is now implemented.
IMO: No that is a mistake. The problem is not with OpenMandriva package management the problem is the stupidity of including as default package in installs of OMLx systems software that allows users to upgrade their system yet the software does not use the correct command. I have argued against that literally forever. Obviously my view did not carry the day on this. Thus I have been stuck trying to explain about this literally for years. And it does make OpenMandriva look bad. The idea that you include software as default software and then you are going to try to tell users not to use that software as they are used to using it shows a lack of awareness of human behavior, aka: this is stupid.
I will concede that I probably see this differently as someone that actually works with this stuff. And I am bitter because of that part about having to explain this a gazillion times.
I understand how you feel. Discover is a KDE program. It is not written by OpenMandriva. The KDE developers try to make it update different distros. For some, like Fedora, it works fine.
On the other hand, it does not work on rolling distros such as ROME, Tumbleweed, Arch, etc. There is no way they can know what is required to update ROME. They don’t hang out here. It is what it is. They have been breaking updates for years and I don’t see it coming to a halt anywhere but here.
Discover is fixed now. @bero ripped the heart out of it and made it work for us.
Perhaps part of my bitterness about this issue is users that approach this as an OM only problem. It is not and never has been as @WilsonPhillips just described. But I still believe we *&^%$# up by including this as default software. Obviously not everyone share my opinions on this.
Edit: I am in the process of testing system upgrades with Discover. I am not recommending users to do this at this time. I think I may see some things that need to be adjusted but need further testing to confirm.
Also that it installed the correct NVidia driver without troubling me about it, which was nice.
