OM doesn't boot after latest update

Hello,

  • OpenMandriva Lx version: 25.03 Rome, rolling

  • Desktop environment (KDE, LXQT…): KDE

  • Description of the issue (screenshots if relevant): last system update was for about 950 files. Installed without error. When I reset to finish the install, the system never returned. OM keeps going blank after the choose OM mode boot screen.

  • Relevant informations (hardware involved, software version, logs or output…):
    I’m sure there are logs I can get from recovery mode up someone will have to direct me on that like I’m 5 years old. [Edit: from advanced options with kernel 6.14.0 and 6.13.7 the only one that will work is 6.13.7 console mode.]

I am posting this from a Live boot flash drive.

I am not savy enough to know exactly if this is related the post I just opened that seems to be a similar problem. But I am not using a VM.
If it is not related then this comment can be ignored, but my problem does seem to be on Kernel 6.14.0, which does not boot after the latest update.

I’m tempted to try the work around post here but I’m not in the mood to make anything more broken than it already is.

If you have/keep a working previous kernel you should not be going to break the system.
Try the following instead:

There is a newer kernel 6.14.0-3 version in Cooker

assuming you have ROME x86_64, waiting for the fixing kernel to land to the other branches:

sudo dnf --refresh --enablerepo=cooker-x86_64 update kernel-desktop 2>&1 | tee kernel-update.log

Double check that will install vers. 6.14.0-3
Just in case the console returns anything strange/unexpected abort the transaction and post the log here.

PS> To be overly cautious I’m used to remove the oldest kernel if already have 3 of them. See the workaround screenshots here above.

1 Like

I haven’t tried removing a kernel yet along with your current suggestion, BUT ouf of boredom I did try a regular cache clean that goes with a distro sync and got a strange return. lacking a means to copy i wrote it all out by hand and here I will reproduce:

Traceback (most recent call last):
     File "/usr/bin/dnf", line 56, in <module.
          from dnf.cli import main
     File "/usr/lib/python3.11/site-packages/dnf/__init__.py", line 30, in <module>
          from import dnf.base
     File "/usr/lib/python3.11/site-packages/dnf/base.py", line 29, in <module>
          from import libdnf.trasaction
     File "/usr/lib64/python3.11/site-packages/libdnf/__init__.py", line 14, in <module>
          from . import conf
     File "/usr/lib64/python3.11/site-packages/libdnf/conf.py", line 10, in <module>
          from . import _conf
Import Error: /lib64/libicuuc.so.76: undefined symbol: icudt76_dat

So when i tried a distro-sync to see what would happen i also got this. So I don’t know if I can even upgrade the kernel without doing some other fix first?

We must read the whole transaction log, including the commands.

The command was

sudo dnf clean all; dnf clean all; dnf repolist

Then the return was exactly as posted save that it was repeated 3 or 4 iterations.

Then I did the command

sudo dng distro-sync --refresh --allowerasing 2>&1| tee dsyc-log.txt

And the return was exactly the same as with the first command.

I’m using a OM live Boot drive right now to access to forum so it’s a bit difficult to copy logs unless there is a way to do this from the live boot.

Moved the most recent comments here.

1 Like

So I log into the the 6.13.7-1 console and there is also an error

asusmin login: marcos
password
Last login: Thu Mar 27 02:57:42 on ttyl
Flatpak: symbol lookup error: /lib64/libicuuc.so.76:undefined symbol: icudt76_dat
[marcos@asusmini ~]$:

Then I tried the command adding cooker you suggested
noboot.txt (820 Bytes)

I belive there are no mistakes in the hand copying of what is returned, but I could not find a .log file in the root drive so I guess it doesn’t even get tto the point of making one.

Ok, thanks.
Looks like something is now not working as expected then.
My best advice is to boot to older kernel for now and wait for fix in rolling branch.

Considering that dnf is prevented from running at all, waiting for a fix is going to be impossible. Kernel 6.13.7 console boot is my only working option, no regular boot with 6.13, so is it more than a kernel bug?

I checked the web for clues and the “libicuuc.so.76” error from the output I posted seems to have broken other distros in the same way it has broken dnf.

Although my OM is not saying the file is missing but instead "undefined symbol: icdt76_dat

This may be a clue but I would still need help on trying to fix it.

If libicuuc.so.76 is corrupted, now do I find a replacement and swap it without using dnf?

You seem to have ended up with an incomplete update somehow.
libicuuc.so.76 has been replaced with libicuuc.so.77, and should simply not exist at all - yet you seem to have some things linking to it left over that don’t exist in a fully updated system.

Try grabbing the last version of icu 76.x before it was updated to 77:
https://abf.openmandriva.org/build_lists/507115

Then install it using

rm -f /usr/lib64/libicu*.so.76
rpm -ivh --force --oldpackage lib64icu*76*

Then try updating with

dnf --refresh distro-sync

to get the proper packages rebuilt against .77 that you somehow missed before. Unfortunately I can’t tell how your box ended up in that state.

2 Likes

Bero’s answer gave the solution. Thank you so much.

For posterity, there was a couple additional things I had to do which I will explain:

The lib64icu* package required an icu-data file to work so I grabbed every package from the Bero’s link then ran (From live boot i downloaded then copied to hard drive with broken upgrade on it.

$ rm -f /usr/lib64/libicu*.so.76

Then

$ rpm -ivh --force --oldpackage icu-data*76*

then

$ rpm -ivh --force --oldpackage lib64icu*76*

Then I had to add --allowerasing to the distro-sync becasue I undoubtedly installed unneeded files, which were giving me an error…

sudo dnf distro-sync --refresh --allowerasing 2>&1| tee dsync-log.txt

After that everything is up and running.

I also don’t know what caused the problem, but i don’t use command line often so i’ll take it as unscheduled practice in that department.

1 Like

What method of updating did you use when the 950 files installed?

Good question.

Recently I had been using Drake tray to tell me when updates were available. And this update was first shown to me through Drake tray. I saw that it was very big, more than 950 packages, so I put it off for a day or two. Then when I decided to do it, I couldn’t find the update through dnfdrake or draketray. I had stopped using Discover but am still not completely confident using the drake programs because for some reason the icons are not all easy to read.

So I just said screw it and did the update through Discover.

Could that have been the problem? or maybe it was bad timing with the rolling sync?

That is why I asked. Discover is a no go when updating the system. There are 4 ways to do it listed here.

I use the system update tool found in the application menu, which is even easier than using discover.

1 Like

Yes, never use discover to update system. Never.
Never.
Never :grin:

2 Likes

Discover bad.

1 Like

What i find weird is that draketray notifies me when there is an update, but if I ignore it and later try to open draketray, nothing comes up? Even right now if I open draketray it doesn’t come up.

Then if I go to dnfdrake to find the updates, it will not give the anything about updates, and i could never find a way to “search for updates” The option to distro-sync is there, but I thought that was different then just having new packages to update.

That’s what forced me into using Discover. But i didn’t realize the System Update was there as well. I need to add that to the task bar. Maybe that should be default underneath Discover in the applications dropdown menu?

1 Like

Discover is a KDE Plasma program. There is no way the KDE folks can know what we need for updating OM. They try, but they just can’t do it.

The easiest way to update your system is at the command line, although many hate to hear that. I recommend this command each and every time.

sudo dnf clean all ; dnf clean all ; sudo dnf distro-sync --refresh --allowerasing 2>&1| tee dsync2-log.txt

That command also creates ~/dsync2-log.txt that can easily help us diagnose the problem if something went wrong.

If you have flatpaks, don’t forget that they need to be updated too.

flatpak update