On Thursday, 8 February 2018 8:34 nicholas cunliffe wrote:

...

Most likely bsc#1079465 (bsc#1079748), fixed Mesa package is available in Tumbleweed update repository

update repo? - i updated 1 hour ago from a fully updated system?

...

Hint: there is already a thread with subject "White SDDM login screen after update Mesa 18" since yesterday. Did you read it?

a new snapshot released 1 hour ago knowing it would break peoples systems?!

Sorry, no idea what you are talking about. Updated packages (version 18.0.0-187.1) have been available since yesterday in Tumbleweed update repository. I updated to them yesterday and they fixed my issue (which had different symptoms - screensaver unable to unlock the session). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

i do NOT have ~/.cache/mesa_shader_cache i have now deleted .cache/qtshadercache/ and /var/lib/sddm/.cache. this allowed login screen but afterwards i get a black screen. one can see the toolbar shadow repeatedly appearing as if kwin or plasmashell etc is trying to restart. (note i could get this before by blindly typing in the password during the white screen) i did not pay attention to yesterdays thread since i had already updated and had no problems -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

i deleted entire .cache, all good now, thanks for help -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il giorno Thu, 08 Feb 2018 10:20:54 +0100 Arjen de Korte ha scritto:

well. Afterwards, it booted to a white screen. At what time did I have a broken Mesa version? Or was Mesa already broken in the previous snapshot and I just didn't notice yet?

Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.

On čtvrtek 8. února 2018 12:04:17 CET nicholas cunliffe wrote:

im not sure the explanation is complete... i was able to roll back perfectly, which would have also read ~/.cache?

If you rolled back to 17.3.3, it probably did not use any of the records in the cache since some other part of their signatures did not match. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On pátek 9. února 2018 12:59:31 CET Lars Marowsky-Bree wrote:

On 2018-02-08T10:40:35, Luca Beltrame wrote:

...

Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.

And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right?

Actually the old cached shaders should have been rejected by the updated Mesa. The fact that they were not is probably another bug in Mesa and is currently being investigated. Deleting the cache manually is a way to get it fixed right now. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 09.02.2018 13:17, H.Merijn Brand wrote:

On Fri, 9 Feb 2018 12:59:31 +0100, Lars Marowsky-Bree wrote:

...

On 2018-02-08T10:40:35, Luca Beltrame wrote:

...

Mesa wrote broken caches, but you don't notice when they are written, but when they are read back (program restarts etc.). That's why even after the update you have to remove the cache: the crashy data has been already written to disk.

And someone decided that manual intervention instead of fixing the programs to detect this and clean it up automatically was the way to go? Sigh. We're trying to drive users away, right?

TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap.

Your points are valid for sure. But at the same time Tumbleweed promised to deliver only stable Software. This usualy means released stuff, not Beta, not RC. Waiting for the official release *may* have prevented the Mesa18 Fallout. I love Tumbleweed for being bleeding edge while keeping a balance. In the last weeks I had the feeling some packagers are getting a bit overly confident to release early because openQA tells them *it works*. libreoffice RC => worked plasma 5.12 Beta => worked Mesa 18 RC => failed Next time we might not be so lucky to get 2 out of 3 right. my2cents, tomme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2018-02-12 at 11:53 +0100, Lars Marowsky-Bree wrote:

On 2018-02-09T13:17:21, "H.Merijn Brand" wrote:

...

TumbleWeed is bleeding edge. I hope you are aware that problems may arise. If you want automatic fixes, stick to Leap.

I think this is unfair to the promise of Tumbleweed.

I could understand how minor issues get past openQA, but a whitescreen after boot for a large portion of the user base deserves a second look as to how that slipped.

There are multiple things playing together and so far, openQA indeed does not catch this kind of problem. One of the biggest issue why openQA does not catch it is that most tests are based on 'fresh installs' and 'upgrades from released openSUSE versions': the fresh install gets obviously a clean cache state, not causing the problem. The upgrade scenario comes from Mesa 17.0 and apparently does not trigger the caches to go beserk. Reasons are not totally clear just yet, as there is a reboot towards the end of the test, where we do add more program tests afterwards. But one thing we DO miss in openQA are non-autologin enabled installs. So we pass sddm only once on the very specific test for 'logout, get to sddm and try to log back in' -> we reach sddm only once.

(Yes, I know, it's FLOSS, so the result might end up implying that I need to do something myself and contribute, but so far I don't yet understand enough as to where ;-)

That's part of the problem of the issue: it is not fully understood: from what I gathered so far it seems to be an invalid play of Mesa invalidating the cache, and Qt not liking it, resulting in render errors.

Is that because openQA runs virtualized and not with actual hardware?

This can well be part of the equation - making it even harder to detect it with openQA

...

That said, this problem was more intrusive that the other problems in the last 6 months as it prevents users to work at all. You need strong nerves to not start cursing.

Well, I was able to eventually fix it locally (noticing how sddm broke, failing to figure out why, and switching to kdm). But I'd still like to understand the failure and process better.

so do I - and hopefully come up with an openQA test. so far, the best thing we found is 'it does not matter if Mesa changes version, a simple rebuild of it will be enough to trigger the error again, as the cache is validated/invalidated based on build_ids. And a rebuild is nothing I can guarantee not to happen (possibly changed deps)

...

• FUN! I think I'm just masochistic enough to enjoy the occasional throwback.

There's certainly that.

But TW should also not be a dumping ground for unstable or untested code, and it shouldn't mean developers push without a local test.

Rest assured, it's not seen as a dumping ground at all.

And maybe it means TW's release process should eventually evolve to include a canary release stage, instead of instant "everyone, everywhere"?

In short: you want to have 'Factory' back? I'm open to hear proposals; I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots). Cheers Dominique

* Robby Engelmann [02-12-18 09:25]:

On Montag, 12. Februar 2018 12:04:32 CET Dominique Leuenberger / DimStar wrote:

...

I know of at leats one user that regularly tests in parallel to openQA, before things 'hit the shelves' - and he did report issues in the past (which we used to block snapshots).

Yes, and that very user was (for whatever reason) not bitten by this issue the time it appeared for most of the users, but one snapshot later. This time the clearing of the cache helped as for all others.

However, after the updated Mesa was removed from the update channel, I was hit again by this issue (or another one), but then clearing the cache did not help and I made a fresh install (in order to test the fresh storage-stack).

not that it makes any diff now, but I also got "hit" again when Mesa reverted, but removing the cache items again solved it and the solution has persisted since. rm -rf ~/.cache/qtshadercache /var/lib/sddm/.cache and I have amd/intel/nvidia graphics cards on various affected boxes. the nvidias all using NV....run drivers, and all on Tw. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Dominique Leuenberger / DimStar [02-12-18 22:13]:

On Mon, 2018-02-12 at 09:50 -0500, Patrick Shanahan wrote: [...]

...

not that it makes any diff now, but I also got "hit" again when Mesa reverted, but removing the cache items again solved it and the solution has persisted since.

There were no Mesa reverts. What did happen is a 'release number decrease' as the same code built in :Update is '1 ahead of non-Update' (which is good, as this helps us ensure Update is 'higher'); once the update is merged though into the mainline tree, the :Update is emptied, and the 'count' reset to what is in mainline. It was 100% identical sources (but still different build id, which is what makes Mesa discard the cache and Qt falling on the nose for not recompiline the Gl shaders)

tks, I understand that. just happened in such a way to make it look different. tks for you many efforts. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I have tried every hint in this and all the other threads regarding this subject and none of them does any good. if your saying deleting the caches doesnt work - *dont reboot* - delete from tty1 return to tty7 and login. if persists ctrl-alt-backspace*2 and try again. I had same issue with delete-reboot-black screen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Chuck Davis [02-12-18 22:48]:

I just did zypper dup from 20171228 to 20180209. When the process is complete the desktop is unresponsive -- nothing can be launched and the only option is using the big red switch. The result is a black screen with cursor arrow @ reboot.

I have tried every hint in this and all the other threads regarding this subject and none of them does any good.

maybe and maybe not, but "every hint" is not very helpful to anyone who cannot see your system and screen.

I have noticed that rpm has issues; particularly issues with several libopus* libraries. And the whole process starts with a selection of what to do with a gstreamer library. I don't know if any of this is relevant to the plasma issues or not.

those are multimedia files, afaik have nothing to do with your display.

So whatever is wrong is not fixed. Since I presume there are very few users who will be updating from the referenced version I'm not sure it's worth much effort to find and fix what is wrong. So, like Robby, I plan to download the latest image and try an install. It is at this point I really, really wish the old capability to "import mount points" was present and worked in the partitioner!

and we have no idea what you did or what is wrong from your description. do you have control of the tty's? what is your system, video card/driver, did you have any errors? do you have odd repos? you noted that rpm has issues, but ??? it really sounds like you have a local issue, and some frustration. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org