Blender UI broken, Substance Painter, 3d Coat | Fedora 40 | AMD GPU

This worked for me, thanks!

1 Like

@flood & @hakanrw Welcome to the :fedora: Community and thanks for the contribution :party:

1 Like

Awesome, that’s fantastic news! Thanks!

Question: How did you discover what lib was making this problem, uninstalling one by one, reading the release of each lib? I am just curious, maybe I will learn something of it for the future? I mean, if you are willing to share :slight_smile:

From the other hand, I was able to run my Substance Painter 2020.2 (6.2.2) in distrobox with Fedora 39 :slight_smile: A bit fiddling with dependencies and checking what Qt libs are missing, and it is running again, and because distrobox it will run just fine despite any update.

Today I try to do the same with Substance Designer, this time on Ubuntu under dbox what is recommended, in this case, despite app is delivered as rpm, but I was able to do deb via alien, but we will see how it goes. It was never running on Linux for me in the past, in contrast to the Painter.

If you are going for that approach, I would strongly recommend giving these apps their own /home directory so as to not pollute your /home All dependencies stay together and you don’t need to worry about your Bash profile or anything.

A better recommendation would be to image it with podman. . . Once you know it works ofcourse.

So they are not separated in distrobox? I was thinking that distrobox is separate environment for the apps. I’m a bit confused right now :sweat_smile: Will take a look what Podman is, I’ve heard that name already for sure, but no idea what it is :slight_smile:

About the bash profile, it is not a problem, my goal to not enter particular distro box env ever again after I install it and create desktop file for it.

toolbox, distrobox use your home directory. In distrobox, you can isolate them by designating a /home for those tools.

toolbox does not work this way, which is why many prefer Distrobox now.

As for podman, You can use compose an image, then use it in toolbox/distrobox for the tools you need.

Here are some examples :
A Web Browser called Thorium

Here is anaconda-navigator

This type of thing will get you out of dependency hell . . . :fedora:

1 Like

For reference, this affects OpenImageIO v2.5.9.0 and later. The latest working version should be v2.5.9.0.

The cause has now been documented as an issue in OpenImageIO.

1 Like

As far as Blender the glibc-2.39-17 upgrade fixed the UI problem that was being caused by OpenImageIO.

1 Like

Welcome to :fedora: @cthuflu Thanks for the tips.

1 Like

Latest version of Blender rpm fixed this issue.


I tend not to update in the middle of a Project ( industry habit ), so I am glad you updated this post !

I have experienced this exact same problem with the repo version of Blender 4.1 after a recent update.
I keep older versions of Blender on my operating system going back to 2.48 using Wine for .exe installation. Went back to version 3.6 as a stand alone installation and that version runs okay with GPU HIP being recognized and usable. If you can get along with the 3.6 version you might temporarily install that version as a standalone until some updated correction is available. Also have bforartists installed through the repos and the 4.1 version does have the icons visible correctly yet nothing appears in support for GPUs.

I don’t think going back to 3.6 is a good solution here. I was a package for some and Mesa version for others. Also, the featureset of 3.x to 4.x is different. Flatpak users can revert to a previous commit without issed as well. as noted here :

I will be adding the Flatpak update method here in a day or 2 for user who want that option.

Using 3.6 worked okay a few days for my hobby circumstances. Today I just installed some updates that have corrected this problem. Things seem to be back to normal with the repo installed version 4.0.2.

But of course it would !