Also, no game starts. Arch Linux. (There are no 32-bit libraries in the system.)

steam-runtime-launcher-service[46076]: I: Running spawn command /home/volren/.local/share/Steam/steamrt64/steam-launch-wrapper
../clientdll/installscript_posix.cpp (522) : Assertion Failed: Standalone evaluator returned error code for app 668580
../clientdll/installscript_posix.cpp (522) : Assertion Failed: Standalone evaluator returned error code for app 668580
assert_20260324153135_35.dmp[46549]: Uploading dump (out-of-process)
/tmp/dumps/assert_20260324153135_35.dmp
chdir "/home/volren/.local/share/Steam/steamapps/common/Atomic Heart"
ERROR: ld.so: object '/home/volren/.local/share/Steam/steamrt32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/volren/.local/share/Steam/steamrt32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Game Recording - would start recording game 668580, but recording for this game is disabled
Adding process 46551 for gameID 668580
steam-runtime-launcher-service[46076]: I: Running spawn command /home/volren/.local/share/Steam/steamrt64/steam-launch-wrapper
ERROR: ld.so: object '/home/volren/.local/share/Steam/steamrt32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Adding process 46552 for gameID 668580
Adding process 46555 for gameID 668580
Game Recording - game stopped [gameid=668580]
Removing process 46555 for gameID 668580
Removing process 46552 for gameID 668580
Removing process 46551 for gameID 668580

I think it would be best if we reserve this issue for NixOS (or whatever factor about @ranidspace's system is making this not work, but I think NixOS is the most likely), and for users who can successfully launch games on the same system when not using the steamrt3c-based Steam client.

@kisak-valve, perhaps you could retitle this to "[SteamRT3] Unable to launch any games on NixOS" or similar?

@hansjansen2:

There are no 32-bit libraries in the system

If that's the case, then the problem you are having is a duplicate of #13015.

Steam is documented to require at least a 32-bit glibc and graphics drivers. Swapping the main Steam client executable to be 64-bit does not remove this requirement: some of the supporting executables are still 32-bit (#13015, #3518). At the moment, the requirement to have 32-bit libraries is considered to be a known limitation rather than a bug.

@VolRencs:

Also, no game starts. Arch Linux. (There are no 32-bit libraries in the system.)

Sorry, I mixed up the mapping of issue to username when commenting before.

If you have no 32-bit libraries installed, then the problem you are having is a duplicate of https://github.com/ValveSoftware/steam-for-linux/issues/13015. Steam is documented to require at least a 32-bit glibc and graphics drivers, and is not expected to work without them. See my previous comment for more details.

@ranidspace, when attempting to start Terraria, your console-linux.txt says:

[2026-03-23 19:33:32] chdir "/home/ranid/.local/share/Steam/steamapps/common/Terraria"
[2026-03-23 19:33:32] ERROR: ld.so: object '/home/ranid/.local/share/Steam/steamrt32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
[2026-03-23 19:33:32] /bin/sh: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

The wrong ELF class: ELFCLASS32 thing is not actually a problem (it just looks scary). The libGL.so.1 error message is a genuine problem though.

This could indicate that something is going wrong with the Steam Linux Runtime container startup. Alternatively, it could perhaps mean that a working libGL.so.1 cannot be found - either a 32-bit or a 64-bit version, it isn't currently clear which. Steam is documented to require both, and it's necessary to have the appropriate OS packages (in your case those would be from NixOS) to provide both.

Collecting a new log from Terraria with the game's Launch Options set to

env -- STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 %command%

might be useful. In your case, the verbose log would appear with a filename like ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app105600-*.log. This will not work correctly with older betas: there was a fix that went in yesterday, so check that your Steam client is up to date.

It might be useful to do an apples-to-apples comparison of:

• Steam public beta, not opted-in to SteamRT3 client, Terraria with the launch options above
• Steam public beta, opted-in to SteamRT3 client, Terraria with the launch options above

and collect a log for each, so that they can be compared. I'm surprised that the steamrt3c client makes any difference for this specific error, but the game startup pipeline is complicated and so is NixOS, so maybe.

I see that in your logs, you're using custom launch options for Deadlock. There have been recent regressions and fixes for custom launch options (#13008, #13012) so let's ignore Deadlock for now, and concentrate on Terraria - making that work will probably provide useful information about any other games that might not be launching successfully.

It appears that all games work now?

I don't know what changed, the steam package on nixos hasn't been changed in 3 months, and the "programs" version of it hasn't been changed in 2 weeks.

Steam Beta Update: 1774488570 with SteamRT3. Unsure whether to close this as I cant confirm for anyone else, but from what I heard, other people with NixOS did have this issue

It appears that all games work now?

Thanks, then I think we can probably assume that whatever unknown problem you might have been experiencing, it was a regression that was (intentionally or accidentally) fixed by the changes in yesterday's beta 1774488570. Maybe it was related to #13008, which definitely was fixed by the new beta.

Unsure whether to close this as I cant confirm for anyone else

Because you're the original reporter of this issue, my inclination would be that if you say it's fixed, then it's fixed. If it now works for you, then any similar symptoms seen by other users must presumably have been caused by something different, such as #13012, #13015, or some as-yet-unknown issue.

Wait, it appears the issue still happens sometimes. It didn't launch a game, but when i changed some environment variables to get the log, it launched. Changing it back it continued to launch. I'll keep looking and if I can't find anything, I'll close the issue, but apparently it is still broken for some other users

Due to recent update stuff changed:

https://www.gamingonlinux.com/2026/03/steam-client-beta-bring-fixes-for-the-new-linux-steamrt3-beta/

Linux SteamRT3 Beta
Fixed games failing to start when when some custom launch options are specified.
Fixed client startup loop that could occur in rare circumstance when Steam config directory is in an unexpected state.

Looks like it just happens randomly per Steam session. I moved to SteamRT3 to get some logs, and everything worked. I closed and reopened Steam without changing any options whatsoever, and it broke again

env -- STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 %command%

With the launch options set on the games, it doesn't make a log at all. It only does if it properly boots.

I got logs for the steam client on both instances luckily.

RT3-Working.tar.gz

RT3-Broken.tar.gz

With the launch options set on the games, it doesn't make a log at all. It only does if it properly boots.

That's already very useful information: it implies that something is (intermittently?) going wrong during early game startup (Steam Client rather than Steam Runtime territory), before the Steam Linux Runtime compatibility tool has a chance to run.

I have the same issue; also on NixOS.
No logs are created with SteamRT3, with or without the above arguments. With brand new updates of Steam & NixOS.

Steam Version: 1775086565
Steam Client Build Date: Thu, Apr 2, 2026 01:00 UTC -08:00

When I open the steam console with steam://open/console and try to launch Terraria, this is what I see
with SteamRT3:

/usr/bin/steam-runtime-launch-client\0--alongside-steam\0--env-fd=155\0-c\0/home/hundvd7/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/hundvd7/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=105600 -- '/mnt/main/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- '/home/hundvd7/.local/share/Steam/steamapps/common/SteamLinuxRuntime'/scout-on-soldier-entry-point-v2 --  '/mnt/main/SteamLibrary/steamapps/common/Terraria/Terraria'\0Game process added : AppID 105600 "/home/hundvd7/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/hundvd7/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=105600 -- '/mnt/main/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- '/home/hundvd7/.local/share/Steam/steamapps/common/SteamLinuxRuntime'/scout-on-soldier-entry-point-v2 --  '/mnt/main/SteamLibrary/steamapps/common/Terraria/Terraria'", ProcID 18573, IP 0.0.0.0:0
Game process removed: AppID 105600 "/home/hundvd7/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/hundvd7/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=105600 -- '/mnt/main/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- '/home/hundvd7/.local/share/Steam/steamapps/common/SteamLinuxRuntime'/scout-on-soldier-entry-point-v2 --  '/mnt/main/SteamLibrary/steamapps/common/Terraria/Terraria'", ProcID 18573 

Is this normal? Without SteamRT3 the path is just /bin/sh. Which exists on my system. But /usr/bin/steam-runtime-launch-client sure does not.
Is this already in the sandbox? Or perhaps something that breaks on NixOS?

I am also experiencing this issue on NixOS on Steam Beta Update version 1775175108. The issue seems not to happen for me when accepting the prompt to restart after enabling SteamRT3 and after that attempting to launch a game, but, upon fully shutting down and starting the Steam client again it will no longer work anymore.

I've noticed when running Steam in the terminal that there are some suspicious errors that are printed only when the issue is present (not when using the 32-bit client or with SteamRT3 immediately after enabling it and accepting a restart). I wonder if this is what is causing the issue?

pv-adverb[265236]: W: Cannot run /sbin/ldconfig: Failed to execute child process “/sbin/ldconfig” (Too many levels of symbolic links)
pv-adverb[265236]: W: Recovering by keeping our previous LD_LIBRARY_PATH

And when finally attempting to launch the game when the issue is present it fails with this.

ERROR: ld.so: object '/home/bruh/.local/share/Steam/steamrt32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/usr/bin/steam-runtime-launch-client: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

Is [/usr/bin/steam-runtime-launch-client] already in the sandbox?

It's a container, not a sandbox, but yes. (The difference is that a sandbox would be a security boundary.)

In the experimental steamrt3c-based Steam client, the majority of the Steam client code runs inside a steamrt3c container. steam-runtime-launch-client is the mechanism that Steam uses to reach outside that container and run anything that needs to be happening outside the container, such as games (which need to run in their own, different container for compatibility) and diagnostic tools.

What's meant to happen is that Steam runs steam-runtime-launch-client --alongside-steam -- some command, and the result is some command running as a child of steam-runtime-launcher-service --alongside-steam, which is one of the few parts of Steam that still runs without a container (for this purpose).

Without SteamRT3 the path is just /bin/sh. Which exists on my system

Yes, that's also normal. In the older versions of the Steam client, the majority of the Steam client code doesn't run inside a container, which means it doesn't need to use steam-runtime-launch-client.

/usr/bin/steam-runtime-launch-client: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

That program is non-graphical and doesn't depend on libGL.so.1, so this is very strange. Possibly it's the gameoverlayrenderer that is making it behave as though it did have a dependency on libGL.so.1.

i can confirm the weird behaviour where it seems to work on the initial toggle and restart of steam, but any subsequent exits and re-opens make all my games fail to launch.

I get the same error about libGL. seems like a red herring to me.

I get the same error about libGL. seems like a red herring to me.

If it's just a warning then it might possibly be a red herring, but if it is actually preventing steam-runtime-launch-client from running, then it will definitely, 100% break the steamrt3c version of the Steam Client.

yeah, hmm. I grabbed logs for you from the initial switch to rt3, where Counter-Strike 2 launched fine, as well as a subsequent launch of steam rt3 where the game failed. Not sure why it's failing to find libGL only on subsequent launches of the client.

working.txt
not.txt

libGL looks like it I guess. I tried adding it to the library path for the client which didn't seem to help.

Will ask to re-open issue at https://github.com/NixOS/nixpkgs/issues/505824. Might be an issue with the FHSenv

can reproduce the issue
the initial switch ALWAYS boots & works fine
everything post initial switch though results in the issue

under the conditions when r3 works the simple test of echo %command% outputs the launch command to Steam's parent terminal as one would expect

on subsequent launches this outputs nothing
seeming to indicate that the shell itself doesn't even launch

for the record i am using Nix OS unstable
the exact version is 26.05.20260414.4bd9165 (Yarara)
very recently updated so should be the latest at the time of writing

some more observations

even in rt3's somewhat broken state running the game using the same command as Steam indeed launches the game
the game being the native version of half life 1
albeit without the overlay but the game itself is able to launch & of course connect to the running Steam instance for DRM purposes
game just crashes without Steam running as usual

launch command used steam-run /home/$USER/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/$USER/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=70 -- /home/$USER/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point --verb=waitforexitandrun -- /home/$USER/.local/share/Steam/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- /home/$USER/.local/share/Steam/steamapps/common/Half-Life/hl.sh -steam steam-run is just used to launch the game in the same fhsEnv that Nix OS makes for Steam

probably final note
when run like this Steam can't stop the game though i suspect that's normal
& game is acknowledged as running by Steam of course

After further investigation I'm thinking this is actually more of a nixpkgs issue. I've added additional context to the original issue. https://github.com/NixOS/nixpkgs/issues/505824#issuecomment-4276944333

Officially fixed in unstable.
Please close.

@ranidspace

@kisak-valve