PS. Given all the issues I have had with Steam on Linux, I think Valve's official support of linux gaming is little more than mouth noises. For the lack of noises on their end, GoG's support is vastly more reliable...

Any hints from
$ ldd ~/.local/share/Steam/ubuntu12_32/steam # list library dependences
(I have no problems with F28 and latest steam client though the Linux kernel I use is a bit old)

I have both i686 and x86_64 versions of libc installed. Steam isn't the only package that depends on a 32bit libc.

Originally posted by Rogue:

Originally posted by Arkanae:

PS. Given all the issues I have had with Steam on Linux, I think Valve's official support of linux gaming is little more than mouth noises.

Not sure if that's fair to say since Fedora isn't what Valve officially supports.

True on the surface of it... but since there are reports of the same exact issue on Ubuntu, where steam *is* officially supported, sorry, that excuse doesn't apply here.

I have not had such issues, but I have much legacy software that relies on the superb multilib support from Fedora and RHEL derivatives, and is actually one of the firs things I install...

have you tried launching Steam with either the STEAM_PREFER_SYSTEM_LIBS=1 or STEAM_RUNTIME =0 ? (I would double check the exact names of the variables, though)

As I previously stated, both 32 and 64 version of the libc are installed. Also, there is no package named "libc.i686" on Fedora. The correct package name would actually be "glibc-2.i686".

I have, indeed, tried reinstalling steam. I have, also, tried the STEAM_PREFER_SYSTEM_LIBS=1 and STEAM_RUNTIME=0 tricks (reported in previous forum posts). Since the issue IS NOT that libc.so.6 (32-bit) is missing, those provide no fix.

Again: the error message reported by the script IS A RED HERRING. The actual issue has clearly nothing to do with a missing version of the libc, since if that was the case nothing else would be working on the system.

in Linux Mint 17.x and 18.x I had a similar error message and it was fixable by deleting (actually renaming so it can be restored) the libc.so.6 in the steam runtime folder for 32-bit libs (in a /home/user/.steam sub-sub-subfolder called ubuntu_x86 or something lik3 that)

it forced steam to use this lib in the system-provided version instead of the runtime one and that solved the issue

linux mint already had it so it was not necessary to install it specifically or anything like that

may not help, but worth trying... just rename back the file if it doesn't work

and be careful, rename just the file inside /home/user/.steam/... not the one(s) in the system folder(s)

Mine works ok. Haven't any issues with Steam of Fedora since end of F27. 10 days ago upgraded to F29 and haven't this or any other issues with Steam.

Steam beta client; Nvidia 396.54 driver.

OK... Solution found.

Apparently wiping out the whole Steam folder under .local and letting steam reinstall its runtime from scratch (all 20000 updates of it) was the solution for it.

As it appears: there was nothing wrong with my system, and everything wrong with how steam borked itself somehow. Color me unsurprised.

Longer explanation for the technically inclined:

It turns out that the steam rpm is actually just the steam runtime installer. Uninstalling, reinstalling it has no effect at all, because the actual steam install is a set of binaries, libs etc... compiled for ubuntu 32bit, and installed for each user under ~/.local/share/Steam/ubuntu12_32/

Since it is installed by steam as a whole block, from a tarball, if one of the updates get screwed up, there is no recovering from it except wiping the whole thing to trigger a reinstall with the (hopefully fixed) last version.

---

Note also that I discovered this install comes with a bunch of *system* libs for Ubuntu (like libgcc, libstdc++ and libxcb-*) which DEFINITELY shouldn't be used on a Fedora, rather the system libs should be used instead.

In that light, I would recommend steam users on Fedora to start steam with

In addition, it seems safer to nuke the extra Ubuntu libraries from orbit:

In fact, after just doing that, steam is running much more smoothly than it used to, at least without using 100% CPU like it had the bad habit of doing.

You installed Steam from RPM Fusion?

Good of you to point to the Github tracker. This never showed up in my searches, given that they were based off the displayed (and in this case unhelpful) error messages. I think linking to this somewhere more prominent in the linux dist docs would be useful.

I think the core of the issue here is the notion of what a runtime should contain, and how to manage that against a variety of distros. The current runtime seems to be packaging in all the libraries that could possibly be needed. This seems overkill, and as a result impossible to maintain in such a wide environment.

The line could be drawn in some other location (further down, e.g. include userland drivers as well, to ensure that video drivers are also uniform? or further up, e.g. not include standard libs like glibc, libstdc++ and basic graphic libs, instead assuming those will be uniform enough?).
Alternately those basic dependencies could be included in the steam package deps, providing a more uniform way to resolve them per distro.

Overall, the current situation results in workarounds that are, as judiciously noted in the page you linked, "not supportable". Changes of these assumptions and design choices would be needed to make them supportable.

Fedora uses flatpak by default, download steam again via flathub.

Originally posted by SirZarmO::

Fedora uses flatpak by default, download steam again via flathub.

We still dont even know from where OP installed his Steam package?

1. RPM Fusion.
2. negativo17
3. Download from official Steam site.
4. Maybe he using flatpak?

I've found that both RPM Fusion and Negativo 17 Steam packages work well on Fedora, at lest I have had no issues with the pakcages themselves. I have had issues with how Steam updates itself, and some times when entering/leaving Beta that stuff gets wonky and for instance wont properly get all the pieces for the Runtime, which apparently is what happened in this case, I do not think the package procedence is of much relevance in this scenario.

Personallly I have not had libc issues with the Runtime, but I have had issues with other libs/components for which I had to disble the Runtime and on only one occasion neeeded to delete Steam from my $HOME in order to force a reinstall.