Catastrophic result after today's graphics driver update

I’m going to take the advice to lock the Mesa stuff from the command line, then try the update again. I want to point out that before I did the update that broke Mesa, the Mesa I had WAS from the official repositories. From what I can glean from the posts, it’s clear that ALL the Mesa updates since 24.0.9-1699.381.pm.1 are broken. So the only correct course is to lock those, then do the updates - including the latest update today which includes a broken new Mesa.

The question then is: how will we know a GOOD Mesa is available? We can’t leave Mesa locked forever.

1 Like

According to this bug report the last known good version seems to be 24.0.8 still available in the slowroll oss repo.
Just for reference, if somebody with the affected HW wants to try it.

1 Like

Actually last night I updated the packages I had from OSS to Packman 24.1.0-1699.382.pm.1. My system STILL WORKS WITH THOSE INSTALLED.

Now I go to Yast to change it back to OSS - and I find the only OSS available is 24…1.0-379.1. So now I can’t revert back to OSS because it will go back too far!

For now, I’m locking the ones that work and will try the update again.

So the problem might not be Mesa itself but incompatibility with some other package in the snapshot?

Nope.
The Mesa I had before the update that broke the system was from OSS.
I then updated them to Packman last night and rebooted. Packman works fine.
I then locked those packages and just did the update that broke the system, minus the locked Mesa.
I just rebooted and the system is back to normal.
This is NOT a Packman problem - this is a Mesa problem.
Any Mesa suhsequent to 24.0.9-1699.381.pm.1 is broken.

This is my current Mesa version:

S  | Name                      | Type    | Version              | Arch   | Repository
---+---------------------------+---------+----------------------+--------+----------------------
il | Mesa                      | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-demo-egl             | package | 9.0.0-3.3            | x86_64 | Main Repository (OSS)
il | Mesa-demo-x               | package | 9.0.0-3.3            | x86_64 | Main Repository (OSS)
il | Mesa-dri                  | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-gallium              | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-libEGL1              | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-libGL1               | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-libglapi0            | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-libva                | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman
il | Mesa-vulkan-device-select | package | 24.1.0-1699.382.pm.1 | x86_64 | Packman

So now I’m wondering when and if openSUSE or whoever is maintaining Mesa upstream will fix this and how can I know when this is done?

But you have 24.1.0-1699.382.pm.1 currently installed and working or am I missing something?

Yes, that version - from Packman, by the way - IS working fine. Any Mesa since then is broken. It doesn’t matter whether your version is from Packman or OSS, as long as it’s not newer than 24.1.0-1699.382.pm.1.

I had the OSS version of 24.1.0-1699.382.pm.1 when the system broke. I then switched it to Packman last night. I then locked the Mesa packages in Yast. Then I installed the update that broke the system. The system is fine now - with outdated Mesa packages.

People here are reporting that subsequent Mesa updates from today are NOT fixing their problem. This means it’s not a Packman or OSS issue, it’s a Mesa issue. Whoever is maintaining Mesa is not testing the Mesa system against AMD graphics.

2 Likes

the last known good version seems to be 24.0.8

I believe 24.0.9 should be fine too, at least my machine is fine when I lock 24.0.9

Any Mesa up to 24.0.9-1699.381.pm.1 will work. Anything subsequent will not work.

I’m sorry, I did a serious typo.

What WORKS is 24.0.9-1699.381.pm.1 - not 24.1.0.

1 Like

OK, clear now.
The “snapshot that broke the system” (20240614 ?) included upgrades from 24.0.8 to 24.0.9 (OSS version) and a bunch of KDE packages and a new kernel (6.9.4) just to name the main dishes.
Since I don’t have the HW to reproduce the problem, I cannot give any better advice for now.

The 20240617 snapshot is what breaks tw’s main repos without packman. For anyone who had packman enabled leading up to this issue, when they dup’ed and got the 20240614 snapshot for their main repos, that same dup is likely when packman upgraded mesa to 24.1.0. Rolling back, locking mesa at 24.0.9-1699.381.pm.1, and dup’ing back to 20240617 appears stable with packman enabled or disabled regardless.

@af420 the issue seems to be AMD specific…

Yes I believe it is AMD specific from what I’ve gathered here and on Reddit (should have mentioned that)

the issue seems to be AMD specific…

Well, sort of. Prior to 20240614 there were a whole host of conflicts with the same Mesa packages popping up between the Packman and OSS. Selecting the Opensuse packages were actually breaking the Nvidia drivers after upgrade. These were resolved with 20240614 . Apparently now the same is happening with AMD?

Sounds more like a Mesa issue to me.

@Android_Gynous Not here :wink: No issues with Intel and Nvidia… but then again, I only use the oss repo…

One of the packman fallout issues with linking to Factory.

1 Like

This issue is contained only to WM (on radeon), games are working fine. I’ve try OSS, packman and even branching mesa - results are the same - transparencies in WMs are broken.

1 Like

Yep. Everything works fine. However cursor is invisible. sddm greeter won’t allow to select another user. More fun lurking. Rolled back to 20240613.

1 Like

Bugreport: 1226505 – Recent Mesa update (24.1.0) broke QML rendering on Radeon

3 Likes

Hi! Do you know if there have been problems with Mesa in other distributions like Arch?