After installing packages updates OpenMandriva no longer boots correctly. When attempting to use the latest kernel it stops displaying anything at all when GRUB passes control to Linux. That however might be my fault as I installed a custom Plymouth theme. HOWEVER when running a slightly older kernel SDDM doesn’t start.
After some tinkering I have managed to reach a console and found that running “dnf upgrade” results in:
Hello, another user reported a similar issue with upgrading in this thread, I have linked the solution, but best give the thread a read over to ensure it is the same issue:
I am not one to scream RTFM, but @RyanMcCoskrie , you have been here since Jan 6. In all that time, you have not read anything about how to manage your system. OpenMandriva is a unique Distro. It is not like any other AND it is a rolling distro.
I’m not even going to ask if you have a good backup of your home folder.
I advise against using the KDE Discover app, or whatever Gnome uses, or the Mint app store, or whatever you have.
In the OM-Welcome app you will find a system upgrade program. Use that if you don’t want to use the terminal. Otherwise, open a terminal and run sudo dnf clean all;dnf clean all;sudo dnf distro-sync --refresh --allowerasing
Make sure you read the thread underneath the solution post in the other thread as there is an extra step needed which I explained there.
Although I downloaded all the files in the link Bero gave, I think the only ones really needed are
icu-data-76.1-2-omv2590.x86_64.rpm and lib64icuuc-76.1-2-omv2590.x86_64.rpm
But if it asks for others, you can find them at the same link.
You’ll need to boot into a live flash drive session which should be able to access the hard drive OM is installed on. Then place the files somewhere in the home drive for easy navigation to from console boot.
After replacing the files it’s likely that other programs still won’t work, but DNF should be working at that point and you can distro-sync to complete the upgrade properly.
When I was using Arch, it had the same warning - “Don’t use Discover to update your distribution.” I didn’t, at the time, un derstand why. After trashing my system, I totally got it. Then I swtiched to OM. And again, the same warning from various people. So that then begs the question, why does the KDE team spend any time on this app if it doesn’t work? Also, does the OM package maintainer for the KDE discover package (DNF) configure Discover to update OM because I see the default source in discover as OM, with a few items checked. In Arch the distro packages are nowhere to be found in Discover, which is good, I would assume.
It’s also interesting that there is a firmware section that also has two boxes checked by default. Do I keep them checked or uncheck them? I have yet to find any information on this section and how good or bad it would be to uncheck or keep checked those two items.
For Flatpaks, the Discover tools seems to work just fine, so that’s all I use it for. But I still don’t understand underlying issues of using it to update my firmware and/or a distribution.
I’m not sure what to do about these two. It appears Flatpaks are already integrated into Discover, so why is it saying that it’s missing the backend for them. Very confusing. This bug report seems to have been fixed, yet here it is in OM. Not fixed or rebroken?
I think OM is great, but the lack of some information can be frustrating for newbies and those who have been seduced by the dark side for a long time but have been recently healed.
lvfs - Linux Vendor Firmware Service is the one that gives you bios updates. I have that one checked and Flathub checked. That’s it. Ignore the ones below. The only safe way to modify those is in the Software Repository Selector.
When you update Flatpaks and you see things that you know you didn’t install those Flatpaks, you can bet they came from vendor-directory - Vendor (Automatic) I don’t have that one checked, but it won’t hurt.
I think I found a bug in something. I mistakenly unchecked everything in Discovery except flatpaks. I also made flatpaks the default. I then could not update my system and I couldn’t remember what I had unchecked. So I proceeded to the Software Repo Selector and selected the ones I had previously selected using this tool. Oddly enough, the Update Channel was now set to Release and not Rolling like it was the first time I went into it. So I selected Rolling, let things finished, then went to DnfDrake to update. All I got were errors about invalid URLs. I had to manually edit the /etc yum rolling repo file manually to fix the URLs.
This is the third time it’s happened, but only on the last time did I figure out the issue and the fix.
I’ll recreate the problem, take screen shots, and fill out a bug report. It’s easy to recreate, btw.
“Do not use discover ” warning which you can read everywhere here is not enough?
Unfortunately no. It would really be nice to know the “why” behind these warnings everyone issues. No one ever says why, just what. And I don’t mean the result, but the root issue/cause. It’s a software dev thing.
This topic has been discussed to death on every rolling release forum, but here goes.
KDE wrote Discover to update systems. It was a mistake. The KDE devs do not hang out here. They have no way to know what command we use to do a dsync. So, they use a command that might work on some system somewhere, but not here. If they can’t use the correct command, they will not get the correct result.
This is not an OpenMandriva thing. Go to Arch and you can read the same discussions. Go to openSUSE and you can read the same discussions. And every place the argument goes on, someone is going to say, well I still want to use Discover, because I refuse to heed the warnings. I have actually seen a user say this.
The only way to fix this is to remove Discover and bury it in the back yard. Oh, yeah. Drive a stake in its heart too.
Probably half of the latest support request topics are due to system upgrade done the wrong way happily ignoring the warnings.
(guess the other half are about nvidia )
)