Upgrade has gone horribly wrong: Can not run DNF or anything graphical

  • OpenMandriva Lx version: 25.03 (ROME)

  • Desktop environment: KDE

  • Description of the issue:

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:

ImportError: /lib64/iccuc.so.76: undefined symbol: icudt76_dat

Running “startx” results in:

Symbol lookup error: /lib64/iccuc.so.76: undefined symbol: icudt76_datxinit

I’m guessing that resolving this problem will require manually downloading patched packages and upgrading by direct use of RPM.

1 Like

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:

2 Likes

OM doesn't boot after latest update - #12 by bero

Just to be sure, did you use dnf upgrade or dnf distro-sync?

I just used Discover rather than the command line.

There are 4 ways to update OpenMandriva listed here.

OpenMandriva wiki

How to update system

How to update your Rock or Rolling system

I use the system update in the application menu.

1 Like

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.

2 Likes

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

2 Likes

The only graphical app that can update the system without breaking it is Dnfdrake.

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.

image

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.

Also, way at the bottom is this section:

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.

1 Like

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? :grin:
nodisc

Please start a new topic.

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. :wink:

i think that this will ended with remove discover from repo omv

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.

1 Like

Before this thread is dead, someone else will start another one and the discussion never ends. It’s been this way for years.

2 Likes

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 :stuck_out_tongue_closed_eyes:)

2 Likes