So for some reason the issue went away with kernel update 6.6.16 as I suspected it would, at least on my system. Time will tell where this fully goes.

Hopefully nvidia does their part as well.

1 members found this post helpful.

The 545.29.06 driver worked with 6.6.16 but now Steam won't work. It had a segmentation fault. An update from Feb 2nd to Feb 9th broke it.

2 members found this post helpful.

Yep. https://www.linuxquestions.org/quest...ce-4175733503/

2 members found this post helpful.

Thank you! That explains a lot.

1 members found this post helpful.

Not having a segmentation fault with the flatpak of Steam. Using the 545.29.02 drivers, been gaming all day. I am not running multi-lib though. I decided to go with a pure 64bit system awhile back.

I did run Slackware with multilib about a year ago but wasn't happy with the performance for games in steam with things like Mass Effect 2, I monitored massive frame dips so I tried the
flatpak, found across the board better performance on my system with gaming.

I even have less issues with steam than when I was on an Arch based distribution with native steam packages and libraries.

I am sharing all of this as an alternative if you want to give it a go. So far I am a big fan of containerization with this stuff. I feel it's much less maintenance.

Flatpak is not the devil, it may turn out as a very good friend for whoever decides to go its route with gaming. You can still compile a lot of native games without 32libs, I did a manual compile of GZdoom (which is a complex process if you don't go with sbopkg/sboui) and some other stuff that went well all pure 64bit. I am also running a pure 64bit version of vkbasalt system wide that I built for native games that support vulkan.

Just an option.

2 members found this post helpful.

Hmm... I just tried the unpatched 470.223.02 driver, it installed fine with 6.6.16. No issues with Steam.

2 members found this post helpful.

Thank you for the information. That sounds interesting! I may try that with Slackware 15.1 when it comes out. I had trouble with Slackware 15 and Final Fantasy 7 Remake Intergrade. It just wouldn't load for some reason but it does with Current.

Thank you for telling me, I tried it out and it works great except for games that require the newer drivers!

I have both my Slackware 15 stable and Slackware current setup with flatpak for gaming. I also recommend flatseal to give permissions to access drives to add game libraries. I actually have static steam and lutris gaming libraries, they stay on drives so I don't have to re-download them when I want to play a title, they just get updated or I setup the prefix for a title. Both Slackware stable and current share the same gaming library drives. Stable I use as my fallback auxiliary.

There is a small learning curve but in the end you end up using the same stuff like mangohud and vkbasalt if you want to "flatpak search vkbasalt" then "flatpak install org.freedesktop.Platform.VulkanLayer.vkBasalt" of course you might have to copy the config file example from github and save it under /home/name/.var/app/com.valvesoftware.Steam/config/vkBasalt/vkBasalt.conf, same thing goes for mangohud. It's pretty seamless with GloriousEggroll/proton-ge-custom versions as well, you can install them from the flatpak command line, me personally I go to the site and read through releases then manually unpack stuff and move it over.

Your 32bit libraries are going to be consistently well maintained for Steam while being containerized and not system wide. It's all set it and forget it. All you do is 'flatpak update' every so often or if you install newer nvidia drivers and that's it.

For me there is no contest it's flat out the most intelligent way to do gaming with Steam. Especially after using it for awhile. Gabe Newell actually recommended Manjaro as the best alternative to the Steamdecks SteamOS, I was an advanced Manjaro user for five or so years 'I liked how much software was available for it in the repos', I can tell you right now Slackware with flatpak is undoubtedly better by hundreds of country miles. There are some minor drawbacks but easily worked around.

Whenever gaming on GNU Linux is brought up, you will always see me recommend flatpak for Steam and Lutris. Why? Updates are easy to maintain and system updates of any kind usually don't break Steam. That is unless flatpak and it's dependencies need to be rebuilt, for every three or so Steam breaking updates that I had a year on a rolling release distribution, I have had zero Steam breaking updates on Slackware current with flatpak.

You could try it right now along side what you already have, maybe even do some benchmarks and see for yourself? You don't have to wait for something special like a fresh install of a new distribution release.

I know there are some folks that are older than me on here but I have been at this since 2001, I am no spring chicken. Trust me, after a hard day's work or after much studying the last thing I want to do is be faffing about like a bell end, wondering why Steam won't load when I all want to do is unwind with a game.

I had heard about flatpak for years but never really had first hand experience with it. If someone were to ask me today what's flatpak? I'd simply reply "Really good engineering for certain software choices but not to be used for everything."

So far since manually compiling GZDoom, I have already had to create at least one symbolic link. For flatpak, none. Low maintenance.

I also have the Steam flatpak well integrated for launch with both XFCE and Plasma through launch panels that autohide. Gaming is one of my few specialties, there are lots of things I am not as experienced with.

Hopefully the Steam and Lutris flatpaks continue to be as good as they have been, which is pretty impressive.

Thing is, though, it's 32-bit OpenGL that's broken for nvidia users with glibc 2.39 compiled with binutils 2.42. (so af7567 discovered, footnote: https://www.linuxquestions.org/quest...ce-4175733503/) That's going to be a problem for more than just steam, so it's useful to try to figure out A.) what went wrong and B.) how it can be fixed.

I don't use multilib for those reasons, I tend to bypass certain things if they have historically caused me issues but only if I've found another route. Of course that's not fixing the problem for people that want to go multilib but it solved mine.

With Arch multilib they usually did a good job keeping up in terms of performance but in other area's it was still a bit of a mess down stream after system updates, too much stuff usually needed to be reinstalled or some other thing, after trying something else and finding out I'm fine without a mixed 64bit and 32bit system I have been pretty ok.

I only need 32bit libraries for gaming, it's a good thing I found something where those requirements are met via portable packaging that's distribution independent.

I wish I could help but I am not in the business of maintaining in that respect. I can only offer my solution that I have found.

The only thing I can suggest is if maybe a few people get together and network with Arch package maintainers to see how they are handling such things compiling etc., they seem to be pretty up on that stuff. Even then if all is said and done, I still think there are going to be issues. A problem of too much complexity and not enough hands to manage that complexity.

I may be full of it, who knows.

There is also conty if someone wants to be brave and give that a spin, seems to work pretty well but therein still lies the home directory clutter issue steam and steam proton have been known to make. I prefer it more tightly contained.

It's obviously not all about Steam though. It looks like a Slackware 32bit and NVIDIA issue, I can only surmise the origin of the issue is on Slackware's end, surmise.

Some people think multilib is a simple affair, it's clearly not, hence the usual pitfalls of it.

1 members found this post helpful.

slackdruid, I've run into a problem with flatpak with my unusual setup, I prevent my users from accessing the internet outside of a proxy or a specific group other than users. I tried running it using env with http_proxy to set my proxy and steam could not access the internet with it. If I switch groups to the one with internet access I get

Hmmm.

You might try first logging out of your current session then logging back in.

If it persist, restart your system. I think I might have seen something strange like that once but only once.

A reboot may be just what is needed. You might try going init 3, then init 1, then fully bringing everything
back up into the init 4 runlevel just to see if it persist before a reboot just to see. It may be a simple
matter of logging out of your current account and then logging back in as well.

Even as long as I have done this stuff there is a massive glut of things to learn.

Below I am providing a little bit of insight into this.

https://github.com/flatpak/flatpak/issues/1256



..........

1 members found this post helpful.

Steam starts loading under the users group but I've blocked internet for that group with iptables. I switch group with sg to one that I allow internet with and bubblewrap says "permission denied." And launching the Steam flatpak with something like env=http_proxy=127.0.0.1:9999 doesn't give internet access to Steam. I've got a weird setup.

I spun up Slackware live to test Steam with flatpak and it worked fine, except that when I try to run any game with a version of Proton any higher than 5.13 the game will not start. I don't have the exact error in front of me since I am not at home, but has anyone here had any issues running proton games with flatpak steam?