KDE session lags hard after logging in

Bazzite
1

After latest updates after I log in from SDDM the plasma shell works awfully slow. I can move the cursor, but the taskbar is unresponsive to the point I just have to do a hard shutdown and then choose different build in grub and then maybe it starts just fine. I didn’t customized anything in terms of system files, plasma is mostly at default settings (only a clock widget added + fractional scaling) and I only install flatpaks/appimages

Do I need to just wait for the right update or maybe there is some mistake on my side that I don’t know of?

2

What is your hardware?

3

lenovo ideapad 3 16/512
i3 12th gen

State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:193f431d6b16926eeed85acf33c0e5b6434522805b11789394dc41b74f078636
Version: 40.20241020 (2024-10-21T05:04:01Z)

ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:023e98d12a3f68596c7d99a059a86977d873ac17c7bd105dc770d0cc598545c9
Version: 40.20241014 (2024-10-15T08:59:50Z)
##############################################################################

file 2 of 3: 62

##############################################################################
=== fpaste 0.5.0.0 System Information ===

  • OS Release (lsb_release -ds):
    “Bazzite 40 (FROM Fedora Kinoite)”

  • CPU Model (grep ‘model name’ /proc/cpuinfo | awk -F: ‘{print $2}’ | uniq -c |
    sed -re ‘s/^ +//’ ):
    8 12th Gen Intel(R) Core™ i3-1215U

  • 64-bit Support (grep -q ’ lm ’ /proc/cpuinfo && echo Yes || echo No):
    Yes

  • Hardware Virtualization Support (grep -Eq ‘(vmx|svm)’ /proc/cpuinfo && echo Yes || echo No):
    Yes

  • Kernel (uname -r):
    6.9.12-210.fsync.fc40.x86_64

  • Kernel cmdline (cat /proc/cmdline):
    BOOT_IMAGE=(hd0,gpt2)/ostree/default-49ddc1d72b86b1adf0b42b1363d444ecd9ee04f462c3577ad9a545667f3240c9/vmlinuz-6.9.12-210.fsync.fc40.x86_64 rhgb quiet root=UUID=c723bffd-5ba3-45d4-b0bc-5804484fa949 rootflags=subvol=root rw ostree=/ostree/boot.0/default/49ddc1d72b86b1adf0b42b1363d444ecd9ee04f462c3577ad9a545667f3240c9/0 gpu_sched.sched_policy=0 bluetooth.disable_ertm=1 preempt=full

  • Desktop(s) Running (without results: "ps -eo comm= | grep -E ‘(gnome-session|startkde|startactive|xfce.?-session|fluxbox|blackbox|hackedbox|ratpoison|enlightenment|icewm-session|od-session|wmaker|wmx|openbox-lxde|openbox-gnome-session|openbox-kde-session|mwm|e16|fvwm|xmonad|sugar-session|mate-session|lxqt-session|cinnamon|lxdm-session|awesome|phosh|sway|Hyperland)’ "):
    N/A

  • Desktop(s) Installed (ls -m /usr/share/{xsessions,wayland-sessions}/ | sed ‘s/.desktop//g’ ):
    /usr/share/wayland-sessions/:
    plasma

    /usr/share/xsessions/:

  • Session Type (env | grep ‘XDG_SESSION_TYPE’ | sed ‘s/.*=//’ ):
    wayland

  • SELinux Status (sestatus):
    SELinux status: enabled
    SELinuxfs mount: /sys/fs/selinux
    SELinux root directory: /etc/selinux
    Loaded policy name: targeted
    Current mode: enforcing
    Mode from config file: enforcing
    Policy MLS status: enabled
    Policy deny_unknown status: allowed
    Memory protection checking: actual (secure)
    Max kernel policy version: 33

  • SELinux Errors (without results: “selinuxenabled && journalctl --no-hostname --since yesterday |grep avc: | grep -Eo comm=”[^ ]+" | sort |uniq -c |sort -rn"):
    N/A

4

After latest updates

To confirm this, can you rollback to 40.20241014?

Also, you can see if this still happens in the :testing or :unstable channel (unstable is running Fedora 41 so use that at your own risk!) and see if there are still issues?

Use bazzite-rollback-helper in the terminal to rollback and change the update channel.

5

I checked after the rollback and Plasma seems much more responsive. Can you explain what will happen after changing update channel to testing?

State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:023e98d12a3f68596c7d99a059a86977d873ac17c7bd105dc770d0cc598545c9
Version: 40.20241014 (2024-10-15T08:59:50Z)

ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
Digest: sha256:193f431d6b16926eeed85acf33c0e5b6434522805b11789394dc41b74f078636
Version: 40.20241020 (2024-10-21T05:04:01Z)
##############################################################################

file 2 of 3: 62

##############################################################################
=== fpaste 0.5.0.0 System Information ===

  • OS Release (lsb_release -ds):
    “Bazzite 40 (FROM Fedora Kinoite)”

  • CPU Model (grep ‘model name’ /proc/cpuinfo | awk -F: ‘{print $2}’ | uniq -c |
    sed -re ‘s/^ +//’ ):
    8 12th Gen Intel(R) Core™ i3-1215U

  • 64-bit Support (grep -q ’ lm ’ /proc/cpuinfo && echo Yes || echo No):
    Yes

  • Hardware Virtualization Support (grep -Eq ‘(vmx|svm)’ /proc/cpuinfo && echo Yes || echo No):
    Yes

  • Kernel (uname -r):
    6.9.12-210.fsync.fc40.x86_64

6

You will be on our testing branch, but there’s not that much of a difference. I don’t want to recommend to use the :unstable branch but that has a lot more changes in the next update if you want to see.

More information can be found here:

7

well I just wanted to troubleshoot my system due to that update. If it’s going to be fixed in the next one I don’t really want to switch branches. I can just wait. But I’m going to notify you if it was fixed in the next one that is on 27th.

Thank you so much for the help🤓