[Silvan]

thermald is confirmed disabled and inactive, and intel_pstate is in passive mode (expected on Haswell without HWP support). The userspace governor being set at every boot may be related to the kernel default governor configuration, which is something that may need to be addressed at the distribution level.

As a test that should also resolve the issue, you can add cpufreq.default_governor=schedutil to the kernel command line. Edit /etc/default/grub and add it to GRUB_CMDLINE_LINUX, then run:

sudo update-grub

After the next reboot the CPU governor should default to schedutil instead of userspace, and the frequency should behave normally without any manual intervention.

From the distribution side, a kernel update is being prepared that sets schedutil as the default governor at boot, which should resolve the issue for all users without requiring any manual configuration.

[Silvan]

The echo schedutil command at runtime restored normal frequency (3-4 GHz), which points to the userspace governor with 800 MHz as the cause. Since the governor still reverts to userspace after each reboot even with thermald disabled, it would be useful to check whether thermald is truly not running after the reboot:

systemctl status thermald

Also useful:

cat /sys/devices/system/cpu/intel_pstate/status

If thermald is stopped and disabled, the userspace governor being set at boot may be related to the intel_pstate driver mode. If the status is passive, the cpufreq framework is in use and something may be defaulting to userspace on this hardware.

[Silvan]

Interesting — RAPL is present, so thermald’s “NO RAPL sysfs present” message is unexpected. It may be a permissions issue accessing the files inside, or a bug in the installed version of thermald.

It would be useful to see more of thermald’s log:

journalctl -u thermald --no-pager | head -80

In the meantime, since thermald is clearly not managing thermals correctly and the i7-4790K has its own built-in thermal protection, disabling it is likely a safe option:

sudo systemctl disable --now thermald
echo "schedutil" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

If the CPU frequency is normal after this, that would confirm thermald was the cause.

[Silvan]

The thermald log suggests a likely cause: “NO RAPL sysfs present” means thermald cannot find the Intel RAPL (Running Average Power Limit) interface it uses to monitor power consumption. Without it, thermald falls back to polling mode and sets the CPU to minimum frequency as a conservative measure, without knowing when it is safe to raise it.

First, check whether the RAPL kernel module is available:

ls /sys/class/powercap/

If the directory is empty or missing, try loading it manually:

sudo modprobe intel_rapl_common

Then restart thermald and check whether the CPU frequency recovers:

sudo systemctl restart thermald

If RAPL is not available on your kernel build, an alternative is to disable thermald entirely — the i7-4790K has its own built-in thermal protection and will throttle itself if temperatures become critical:

sudo systemctl disable --now thermald
echo "schedutil" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Note that power-profiles-daemon is now available in the repository, but it would not resolve this issue on its own as long as thermald is overriding the governor.

[Silvan]

The data points to thermald as a likely cause: the governor is set to “userspace” with scaling_setspeed=800000, which is how thermald controls CPU frequency for thermal management. It typically sets the minimum at boot as a starting point and should then raise it — but in your case it may not be doing so until the sleep-wake cycle triggers a thermal re-evaluation.

It may be worth checking thermald’s logs to confirm:

journalctl -u thermald

In the meantime, switching the governor manually should help:

echo "schedutil" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Note that cpupower-gui is no longer installed by default and is no longer recommended. It has been replaced by thermald for Intel CPUs, which handles thermal management — keeping the CPU within safe temperature limits. Performance profile management (switching between power-saving, balanced and performance) is a separate concern, handled by power-profiles-daemon.

From the distribution side, power-profiles-daemon has just been packaged and is currently in the devel-makedist repository, where it will go through testing before being made available in the base repository and installed automatically as a dependency of powerdevil for all users.

[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.

[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.

[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, 3 days ago by Silvan.
• This reply was modified 1 week, 3 days ago by Silvan.

[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]

[Silvan]

Can you try if the following command helps?

sudo dnf install plasma5support

[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.

[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.

[Silvan]

You probably have the file /etc/rpm/macros.lang, from the “livedvd” ISO, delete it.
Then you should reinstall all the recently updated packages which provide an Arabic translation.
The following command may be a good start:
sudo dnf reinstall *plasma*

I’m removing this setting from the “livedvd” ISO to possibly resolve the problem for future installation.

• This reply was modified 1 month, 3 weeks ago by Silvan.
• This reply was modified 1 month, 3 weeks ago by Silvan.

[Silvan]

Hi,
thanks for the information provided. What is the output of:
rpm --eval %_install_langs?

if it is not “all” but limited to a short list of languages it may be the culprit. This variable might be set in a file in the /etc/rpm/ folder.

[Silvan]

Hi,
the current step of information gathering is what is the output of the two following console commands:

localectl
locale

If everything seems to be correctly set for ar_DZ.UTF-8 language (or any other ar_*.UTF-8 locale) the question is: you don’t see any translation in the console, admitted that you use it, or maybe just in the KDE Plasma desktop environment and most graphical applications? If the answer does not help then I will need to reproduce your installation and check for deeper problems since everything seems correctly set so far.

• This reply was modified 1 month, 3 weeks ago by Silvan.

[Author]

Posts