update conflict

[einar.hjortdal]

Updated today after 2 weeks I’ve been away and got the following after a dnf upgrade --assumeyes

 Problem 1: cannot install both glib-tools-2:2.88.1-1mamba.x86_64 from rolling and glib-tools-2:2.88.0-1mamba.x86_64 from @System
  - package libglib-2:2.88.0-1mamba.i586 from @System requires glib-tools = 2:2.88.0-1mamba, but none of the providers can be installed
  - cannot install the best update candidate for package glib-tools-2:2.88.0-1mamba.x86_64
  - problem with installed package libglib-2:2.88.0-1mamba.i586
 Problem 2: cannot install both mesa-common-1:26.1.1-1mamba.x86_64 from rolling and mesa-common-1:26.0.5-1mamba.x86_64 from @System
  - package libmesa-1:26.0.5-1mamba.i586 from @System requires mesa-common = 1:26.0.5-1mamba, but none of the providers can be installed
  - cannot install the best update candidate for package mesa-common-1:26.0.5-1mamba.x86_64
  - problem with installed package libmesa-1:26.0.5-1mamba.i586
 Problem 3: cannot install both glib-tools-2:2.88.1-1mamba.x86_64 from rolling and glib-tools-2:2.88.0-1mamba.x86_64 from @System
  - package libglib-2:2.88.0-1mamba.i586 from @System requires glib-tools = 2:2.88.0-1mamba, but none of the providers can be installed
  - package libglib-2:2.88.1-1mamba.x86_64 from rolling requires glib-tools = 2:2.88.1-1mamba, but none of the providers can be installed
  - package libverto-0.3.2-2mamba.i586 from @System requires libglib-2.0.so.0, but none of the providers can be installed
  - cannot install the best update candidate for package libglib-2:2.88.0-1mamba.x86_64
  - problem with installed package libverto-0.3.2-2mamba.i586
 Problem 4: cannot install both glib-tools-2:2.88.1-1mamba.x86_64 from rolling and glib-tools-2:2.88.0-1mamba.x86_64 from @System
  - package libglib-2:2.88.0-1mamba.i586 from @System requires glib-tools = 2:2.88.0-1mamba, but none of the providers can be installed
  - package libglib-2:2.88.1-1mamba.x86_64 from rolling requires glib-tools = 2:2.88.1-1mamba, but none of the providers can be installed
  - package libverto-0.3.2-2mamba.i586 from @System requires libglib-2.0.so.0, but none of the providers can be installed
  - package libglib-devel-2:2.88.1-1mamba.x86_64 from rolling requires libglib = 2:2.88.1-1mamba, but none of the providers can be installed
  - package libkrb5-1.22.2-1mamba.i586 from @System requires libverto.so.1, but none of the providers can be installed
  - cannot install the best update candidate for package libglib-devel-2:2.88.0-1mamba.x86_64
  - problem with installed package libkrb5-1.22.2-1mamba.i586

Are you aware of this issue?

[Silvan]

Hi,
you may want to check that the rolling repository for i586 is enabled:

$ grep "enabled" /etc/yum.repos.d/openmamba-rolling-i586.repo 
enabled = 0

Since the release of wine 11.0 package, legacy x86 packages are no longer required, so i586 repository becomes disabled by default and you may also choose to remove i586 packages causing conflicts, for example:
sudo dnf remove libmesa.i586 libverto.i586 libkrb5.i586

Check that only i586 packages are removed as desired before confirming.

[einar.hjortdal]

Got it, that was correct. I removed all i586 packages and the update proceded correctly. The repo was indeed disabled

[einar.hjortdal]

Although, after the update, plasma and kwallet kept crashing. I was not sure if I caused this mess so I have re-installed openmamba using the livecd image.

I noticed that plasma cannot open the menu widget in the livecd image and Calamares crashes at the end with a “installation failed” message. Despite that, after rebooting openmamba appears to have been installed correctly. The menu widget still does not open.

After dnf upgrade, I am still getting the same crashes. Therefore I do not believe I caused these issues myself.

[einar.hjortdal]

Even kate crashes when opening the openmamba-report file. Performance is abysmal, bluetooth crashes too. Something for sure is happening. Surprisingly, nvidia_470 is working fine this time

• This reply was modified 1 week, 4 days ago by einar.hjortdal.

Attachments:

You must be logged in to view attached files.

[einar.hjortdal]

Could it be libQt6Core? dmesg -T is full of drkonqi-coredum[17665]: segfault at 0 ip 00007f4db46345c3 sp 00007ffe25cce738 error 4 in libQt6Core.so.6.11.1[2345c3,7f4db44c2000+457000]

[einar.hjortdal]

It probably isn’t libQt6Core, after a reboot crashes keep happening but libQt6Core errors aren’t present in dmesg yet

[Silvan]

The segfault inside libQt6Core.so.6.11.1 is a useful clue — a null pointer dereference in Qt6Core would explain crashes across all Qt-based applications (plasma, kwallet, kate, bluetooth stack). Since others are not reporting this, the issue is most likely specific to your installation.

A few things worth checking:

Verify the integrity of the Qt6Core package (detects file corruption or partial upgrades):

rpm -V libQt6Core

Check that all Qt6 packages are on the same version:

rpm -qa | grep -E "^libQt6|^qt6" | sort

If any package is on a different version, a full upgrade or selective reinstall may fix it:

sudo dnf reinstall libQt6Core

The “abysmal performance” combined with widespread crashes could also point to a hardware memory issue. If the above checks come back clean, it would be worth running a memtest pass.

[einar.hjortdal]

Hi thank you for the reply. I also discovered this one

$ LD_PRELOAD=/usr/lib64/libthread_db.so.1 kate -n
kate: symbol lookup error: /usr/lib64/libthread_db.so.1: undefined symbol: ps_pdwrite

rpm -V libQt6Core returned nothing. rpm -qa | grep -E "^libQt6|^qt6" | sort showed all 6.11.1-1mamba

sudo dnf reinstall libQt6Core and rebooting didn’t change the situation

I can get kate to crash consistently when any scrolling (horizontal/vertical) happens, I am testing with that

I could let memtest run overnight but I am more suspicious of some library over the hardware being faulty

[einar.hjortdal]

The reason I suspect some shared library is that non-openmamba software (edge, vscode…) are not crashing despite having bad performance. These come with a bunch of statically linked libraries.

Another solid test would be to have an older version of openmamba at hand to install, but I don’t have that. I do have windows installed too, and that one is working fine (fine by microsoft standards).

[Silvan]

Can you try if the following command helps?

sudo dnf install plasma5support

[einar.hjortdal]

unfortunately it did not help

[einar.hjortdal]

Got this using strace -f -o kate_crash.log kate -n (compressed with zstd)

• This reply was modified 1 week, 4 days ago by einar.hjortdal.
• This reply was modified 1 week, 4 days ago by einar.hjortdal.
• This reply was modified 1 week, 4 days ago by einar.hjortdal.

[einar.hjortdal]

I don’t know if any of the uploads was successful because I am told I am not allowed to upload those file types.
Here is a link to the file: https://drive.google.com/file/d/14VsPIhZSNWxI7qJdWfWDzNXw0LWiNvzp/view?usp=drive_link

[Silvan]

After a closer look, the ICU library conflict we found (multiple versions of libicuuc loaded via the hfstospell → libxml++ chain) is a packaging issue we will fix, but it is probably not the cause of your crashes — otherwise other users with the same packages would also be affected.

What is unique to your system is the NVIDIA GTX 780 with the legacy nvidia_470 driver. This is a very old driver (Kepler architecture, 2014) and Qt6 6.11 is a very recent release. The crashes happen consistently during rendering (scrolling), and the segfault is inside libQt6Core during X11 rendering operations. This is consistent with a Qt6 6.11 / nvidia_470 driver incompatibility, where Qt uses a GLX code path that the old driver does not handle correctly.

This would also explain why Edge and VSCode work fine (they have their own graphics stack) and why other users do not see this issue.

Unfortunately there is no easy fix on our side for a proprietary legacy driver issue. A few things worth trying:

1. Force software rendering for Qt6 to see if that makes the crashes disappear:
QT_XCB_GL_INTEGRATION=none kate -n

2. If that helps, you can make it permanent for all Qt6 apps:
echo “export QT_XCB_GL_INTEGRATION=none” >> ~/.profile

3. Alternatively, try with the nouveau open-source driver if that is an option for you.

[NOTE: AI generated reply]

[einar.hjortdal]

I believe the AI is misleading you: I have removed nvidia_470 and nothing changed, except for even worse performance, because of course now everything is cpu rendered

glxinfo | grep "OpenGL renderer"
OpenGL renderer string: llvmpipe (LLVM 22.1.5, 256 bits)

[einar.hjortdal]

I have managed to find an old livecd image from june 2025, and I have installed it. I have not installed nor updated any package yet. I could update each package until the problem occurs again, so that we would know which package causes it. Would this help? What packages should I upgrade and in what order? Do you have suspicions?

[Silvan]

Checks on the livecd ISO image revealed that due to a bug in the images creation scripts all the recently published iso images were indeed the same image creared two months ago. So the livecd ISO image has been fixed today and the other fixed ISO images will be released within the next two days. Please note that the fixed livecd image has the same name and date of the one released last night so make sure you have downloaded it after the date of this post comment or check the MD5 reported on the site.

Contextually it has been confirmed that the bug in the application menu was caused by the absence of the plasma5support package and this has been fixed for new ISO images.

No other general problems have been reproduced, including the calamares installer which completed installation tests without crashing.
For any problem that would persist it is required to report after trying the flow based on the fixed live ISO images.

Thank you for reporting.

• This reply was modified 1 week, 4 days ago by Silvan.
• This reply was modified 1 week, 4 days ago by Silvan.

[einar.hjortdal]

Thank you for looking into this issue.

I have now installed openmamba using the new livecd image.

The app menu does work correctly now in the live environment. At the end of the install process, calamares fails to unmount the partitions, but I don’t think this causes the issues I am experiencing. Here is the calamares log file: https://termbin.com/0bax

I am experiencing the same crashes right in the first boot. I have not updated nor installed any packages. I have not run dnf at all. Please advise what to do in order to debug the situation.

[Silvan]

Looking at the Calamares log, the installation kept the existing home directory, so all previous KDE/KWallet configuration files were preserved — including any corrupted settings. This is very likely the cause of the persistent crashes.

Please test with a new user account to confirm:

sudo useradd -m testuser && sudo passwd testuser

Log out and log in as testuser. If everything works there, the problem lies in the configuration files in your home directory.

[einar.hjortdal]

You were correct, the new user does not have these issues.

I did not suspect user settings because I did not change any. Because I did not change any, I don’t know which is causing the issues.

Are you aware of any setting being touched by the packages at update? I doubt they touch user settings though… Just what happened? 🤔 I could even wipe them all, if I knew which directories to wipe

[Silvan]

Package updates do not touch user settings directly, but a major KDE or Qt update can make existing configuration files incompatible with the new version — the application then reads an old config it no longer understands and crashes.

The relevant directories are:

~/.cache/ — safe to wipe entirely, it is always regenerated
~/.config/ — KDE and Qt configuration files
~/.local/share/ — KDE local data (including KWallet)

Start with ~/.cache/ alone, as it sometimes resolves issues without losing any settings. If crashes persist, move ~/.config/ and ~/.local/share/ aside (rename, do not delete) and KDE will recreate them from scratch on next login.

[einar.hjortdal]

Moving .config worked. Unfortunately I have to pick and restore some directories within it. But I guess this case is closed. Thank you for the support

[einar.hjortdal]

Actually, I just remembered that this morning, the older version of plasma was working fine with this home directory. And the first time these issues appeared was when the system updated to the latest plasma packages. Therefore, the new plasma version must not like whatever is contained in these user settings that are perfectly fine with older versions of plasma.

[Author]

Posts