Zypper dup kernel ug to 6.17.4-1 from 6.17.3-1 broke wayland cursor

English Install/Boot/Login
1

After zypper dup last night kernel was updated to 6.17.4-1 and my mouse cursor arrow on the login screen dissipated, became undefined (could call it a blob, mist of dots or a spot of random pixels, etx) during the start of the wayland session. Tried system/kde setting mouse (enable disable), display resolution adjustments, tec. but nothing changed. Some new updates (in discovcer) appeared so I did another zypper dup but there was no change or, rather, the pointer blob got worse.

I had the following read-only snapshots:

  1. *openSUSE Tumbleweed (6.17.4-1.2025-10-24T04:36.post.zypp(zypper))
  2. *openSUSE Tumbleweed (6.17.4-1.2025-10-24T04:32.pre.zypp(zypper))
  3. *openSUSE Tumbleweed (6.17.4-1.2025-10-24T04:22.post.zypp(zypper))
  4. openSUSE Tumbleweed (6.17.4-1.2025-10-24T02:07.pre.zypp(zypper))
  5. openSUSE Tumbleweed (6.17.3-1.2025-10-24T01:03.pre.zypp(packagekitd))
  6. *openSUSE Tumbleweed (6.17.3-1.2025-10-23T15:03.post.yast sw_single)
    … (and a few more)

Rebooting with no. 5 read-only restored the wayland session’s cursor and all earlier snapshots (i.e. 6, …) had normal mouse cursors. Snapshots 1 to 4 all changed to the blob-like thing after login during the plasma session start. Otherwise everithing worked, though, it took some trial error to hit targets with clicks. Only the pointer image seemed to have been affected.

I run ‘sudo snapper rollback’ with snapshot no. 5 loaded, restarted and the rolled back sytem info is:

Operating System: openSUSE Tumbleweed 20251021
KDE Plasma Version: 6.4.5
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.3-1-default (64-bit)
Graphics Platform: Wayland
Processors: 24 × Intel® Xeon® CPU X5670 @ 2.93GHz
Memory: 64 GiB of RAM (62.8 GiB usable)
Graphics Processor: llvmpipe
Manufacturer: Apple Inc.
Product Name: MacPro5,1
System Version: 0.0

I saw the announcement of a new snapshot: Tumbleweed 20251022 today which is likely caused my problem. I assume that if this was a widespread issue I should be seeing lots of messages about it. Maybe I don’t know something.

If I am ignorant and there is a way to restore the cursor’s picture of a wayland session without rollback, or waiting to another update that might fix it, please, let me know how to do it. BTW, I installed openSUSE Tumbleweed on this machine in 2022 and this is the first time since then I had to do a roll back to restore usability.

2

Maybe related to this:

3

I believe that I am experiencing this also.

g6:~> kinfo
Operating System: openSUSE Tumbleweed 20251023
KDE Plasma Version: 6.5.0
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.5-2.g00da826-default (64-bit)
Graphics Platform: Wayland
Processors: 2 × AMD A6-4400M APU with Radeon(tm) HD Graphics
Memory: 8 GiB of RAM (7.2 GiB usable)
Graphics Processor: llvmpipe
HP-Pavilion-g6:~>

It is resolved in 6.5.1 supposedly. There is a way to see when 6.5.1 is released for openSUSE maybe OBS or something?

4

Thanks, you’re probably right it’s related as the picture attachment at your URL looks the same as my cursor with the updates and I got the original Apple ATI Radeon HD 5070 card in My ancient Mac Prop 5,1.

5

Kernel Version: 6.17.5-2.g00da826-default (64-bit)

You've got a newer version of the kernel than mine was before the rollback so its unlikely the problem. I looked through the update list, and it still offers the same update to KDE Plasma 6.5.0 not the fixed version. I'll wait with the re-update until 6.5.1 shows up.

BTW, the default kernel update offered to me is still just 6.17.4-1.1 not 6.17.5-2 like your installation. We both seem to have openSUSE Tumbleweed. Any idea why?
6

Using kernel standard stable on the machine here :< stable branch - openSUSE Kernel

7

I rebuild kwin6 in OBS with the patch and that fixes the issue. If you trust my repo you can download it from that repo. The package will disappear when it has been fixed upstream and pushed into the official repos.
I branched kwin6 in OBS, applied the patch, changed the spec file and put that also in the change file.

8

Your help is much appreciated. I took a leap of faith, re-updated my system. Predictably the cursor broke. Downloaded from your OBS repo the two files I had re-installed with the re-update and installed them using rpm:
…

rpm -iv --force kwin6-6.5.0-7.3.x86_64.rpm

…

rpm -iv --force libkwin6-6.5.0-7.3.x86_64.rpm

…
Logged out and back in and the cursor was back to normal. Great, thanks again. Finally, I got rid of the originals of the two files I installed from your repo using zypper:
…

zypper remove kwin6-6.5.0-1.1.x86_64

zypper remove libkwin6-6.5.0-1.1.x86_64

…

From previous experience, zypper will ask to upgrade the force-installed files once it gets them. I somimes wondered how to use the OpenSUSE Buld Service but never got around to figure it out. Obviously it comes very handy in such occasions. Thanks for demonstrating how useful it might be :slight_smile:

9

No, it won’t. By default it will not switch vendor.

10

Wrong, actually both ‘discover’ and ‘zypper dup’ already asked to 'upgrade" to the originals I have removed. The zypper dup output is below:
…
Refreshing service ‘openSUSE’.
Loading repository data…
Reading installed packages…
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See ‘man zypper’ for more information about this command.
Computing distribution upgrade…
2 Problems:
Problem: 1: problem with the installed kwin6-6.5.0-7.3.x86_64 [from swannema]
Problem: 2: problem with the installed libkwin6-6.5.0-7.3.x86_64 [from swannema]

Problem: 1: problem with the installed kwin6-6.5.0-7.3.x86_64
Solution 1: install kwin6-6.5.0-1.1.x86_64 from vendor openSUSE
replacing kwin6-6.5.0-7.3.x86_64 from vendor obs://build.opensuse.org/home:swannema
Solution 2: keep obsolete kwin6-6.5.0-7.3.x86_64

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 2

Problem: 2: problem with the installed libkwin6-6.5.0-7.3.x86_64
Solution 1: install libkwin6-6.5.0-1.1.x86_64 from vendor openSUSE
replacing libkwin6-6.5.0-7.3.x86_64
from vendor obs://build.opensuse.org/home:swannema
Solution 2: keep obsolete libkwin6-6.5.0-7.3.x86_64

Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c/d/?] (c): 2

Resolving dependencies…
Computing distribution upgrade…

The following 2 items are locked and will not be changed by any action:
Installed:
kwin6 libkwin6
Nothing to do.

Since I hate when the thing keeps nagging to muck up my system it mucked up before, I locked the ‘obsolete’ versions from swannema (i.e., soluions 2), which ar the actually working ones. Now it won’t nag again. When there are official updates to version 6.5.1 of the packages I shall unlock these zypper using:

zypper rl

and they will be updated from opensuse automatically again from then on.

11

You just installed RPM without adding the repository, right?

12

Yep, as I shown the RPM command above I thought it was obvious. This has been my standard approach forever if I needed to install odd rpms to correct hickups. This way I do not have to add the repo change, the priority or allow repo change that would be asked for by zypper. When I see package update that I want instead of the forced RPMs I simply zypper rl [package name], after which zypper update/dup will propose the updated files and all are back to ‘normal’ :slight_smile:

13

Yes, use ‘zypper -v dup’ or after zypper dup use option ‘v’ before ‘y’ or ‘c’. BTW, swannema’s rpms (ibkwin6-6.5.0-7.3.x86_64.rpm & kwin6-6.5.0-7.3.x86_64.rpm) work fine if you apply them after every update. It seems that one must allow reversion to the originals (libkwin6-6.5.0-1.1.x86_64) in order to do an update. There is an alternative solution until an official update to v.6.5.1 appears, if you want to try it:

I did an zypper dup, had to allow reversion, cursor broke. I was just about to try to force re-apply swannema’s rpms when I came across the following article:
‘SDB:KDE repositories’ at SDB:KDE repositories - openSUSE Wiki

Under the heading: KDE Frameworks 6, Plasma 6 and Applications, there is repo for KDE Frameworks: https://download.opensuse.org/repositories/KDE:/Frameworks/openSUSE_Tumbleweed/

It did have Plasma6 version 6.5.1. According to the KDE bug swannema dug up it resolves the cursor problem (510930 – Corrupted cursor image with older AMD GPU). The unstable framework repo at the start of the article was up to version 6.5.8. It was intriguing but, finally, I went with v.6.5.1:

zypper ar -fp 75 https://download.opensuse.org/repositories/KDE:/Frameworks/openSUSE_Tumbleweed plasma6frameworkAdding repository ‘plasma6framework’ …[done]
New repository or package signing key received:
…
Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
Retrieving repository ‘plasma6framework’ metadata …[done]
Building repository ‘plasma6framework’ cache …[done]
All repositories have been refreshed.

zypper -v dup --allow-vendor-change
…
Computing distribution upgrade…
Force resolution: No
Computing upgrade…

The following 100 packages are going to be upgraded:
…
kwin6 6.5.0-1.1 → 6.5.1-kf.97.1
…
libkwin6 6.5.0-1.1 → 6.5.1-kf.97.1
…
100 packages to upgrade, 199 to downgrade, 1 new, 299 to change vendor.
…
Continue? [y/n/v/…? shows all options] (y): y

…

CommitResult (total 300, done 300, error 0, skipped 0, updateMessages 0)
…

Besides the broken cursor there were some other minor annoyances (e.g., with launching apps from GUI, etc.) in v6.5.0 that disappeared with v6.5.1. Clearly, I was wrong, the kernel had nothing to do with the broken cursor. I got updated to the same (non-developer) version you showed in your message before upgrading plasma and the cursor got re-broken :). Now it’s all GOOD:

:~> kinfo
Operating System: openSUSE Tumbleweed 20251027
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.5-1-default (64-bit)
Graphics Platform: Wayland
Processors: 24 × Intel® Xeon® CPU X5670 @ 2.93GHz
Memory: 64 GiB of RAM (62.8 GiB usable)
Graphics Processor: llvmpipe

You may remove the above repo and change back at any time. It certainly changes a whole lot more than what swannema compiled in his OBS repo.

14

@arvidjaar @swannema @sagal002 So one could disable vendor stickeness :< SDB:Vendor change update - openSUSE Wiki then add swannema’a repo from post #7 ? What do you think about this option? I have vendor stickiness disabled on this machine for a while now.

Post #13 added more good info thanks.

15

As I wrote above, I will delete that package once the fix has arrived in the official repos or actually when I see plasma 6.5.1 is being build for the next snapshot. If you have my repo enabled and the package is gone, during the next zypper dup you will be asked what to do with that package, usually keep the old package/switch to the version from openSUSE, therefore I think there is no need to disable vendor stickiness.

16

Thank you, I was not aware of the option to change the default vendor-change behavior in the zypper’s config file. In any case, even if otherwise the zypper config change you mentioned works, adding swannema’s OBS repo and changing the default vendor-change behavior in zypp.conf unlikely to have worked in this case due to the lower version numbers, at least by zypper. That OBS repo only had 5-6 files of which only 4 were relevant and only 2 were actually installed on my machine. Adding the repo, changing/locking vendor and possibly changing priority seemed overkill for trying out two packages :). And, as I said zypper saw the packages from the OBS repo as having lower version number than the originals. BTW, I tried ‘rpm -iv --replacepkgs ’ first that supposed to work with higher or at least same version number packages, it did not. The list of rpm complaints exceeded the capacity of my terminal’s display buffer. That’s why I used ‘rpm --force…’ and removed the originals only after I had no problems with the forced packages.

With my alternative, - it’s a shot in the dark -, with wendor stickiness disabled zypper should not have downgraded the 199 packages in addition to the 100 ones it upgraded. This is, if the disabling of vendor-stickiness only affects higher version numbered packages. Again I don’t know if it had caused any problems. In addition the article you linked to, only talks about updates (ie., ‘zypper up’ ) that is not really used with tumbleweed. Have you ever checked if it works with distribution upgrade (ie., ‘zypper dup’)?

Apologies for the weird formatting problems in some of my my posts. I haven’t quite figured out the markup used. Its really bad when I copy/paste :).

17

Plasma 6.5.1 is in the next snapshot, so my package will be deleted soon.