Native games using steam-rt 1 (scout) not working on Exherbo Linux

[tgurr]

Your system information

• Steam Runtime Version: steam-runtime_1.0.20251202.187498 / soldier_platform_2.0.20251202.187501 / sniper_platform_3.0.20251202.187502
• Distribution (e.g. Ubuntu 18.04): Exherbo Linux
• Link to your full system information (Help -> Steam Runtime Diagnostics): Gist - Steam Runtime Diagnostics:
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Depending on the game
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

#Name	Version		Runtime	Runtime_Version	Comment
depot	0.20240806.0			# Overall version number
LD_LIBRARY_PATH	-	scout	-	# see ~/.steam/root/ubuntu12_32/steam-runtime/version.txt
scripts	0.20240806.0			# from steam-runtime-tools

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name	Version		Runtime	Runtime_Version	Comment
depot	2.0.20251202.187501			# Overall version number
pressure-vessel	0.20251201.0	scout		# pressure-vessel-bin.tar.gz
scripts	0.20251201.0			# from steam-runtime-tools
soldier	2.0.20251202.187501	soldier	2.0.20251202.187501	# soldier_platform_2.0.20251202.187501/

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt

#Name	Version		Runtime	Runtime_Version	Comment
depot	3.0.20251202.187502			# Overall version number
pressure-vessel	0.20251201.0	scout		# pressure-vessel-bin.tar.gz
scripts	0.20251201.0			# from steam-runtime-tools
sniper	3.0.20251202.187502	sniper	3.0.20251202.187502	# sniper_platform_3.0.20251202.187502/

Please describe your issue in as much detail as possible:

Steam itself runs fine, games utilizing Proton run fine, stuff using steam-rt 3 sniper runs fine, but anything still using plain scout runtime fails to launch. This applies to for example factorio (427520) and shapez2 (2162800). After manually switching the runtimes e.g. for factorio by editing config.vdf:

~/.local/share/Steam/config/config.vdf

					"427520"
					{
-						"name"		"steamlinuxruntime"
+						"name"		"SteamLinuxRuntime_sniper"
						"config"		""
						"priority"		"250"
					}

I'm able to play the game just fine, the same applies to shapez2 (or at least did previously since it now runs into another issue which it didn't in the past - probably due to not built for/against steam-rt 3 but at least the game opens shows the game logo but crashes before getting into the main menu - unrelated to the actualy problem here)

Steps for reproducing this issue:

1. Try to launch a native game utilizing steam-rt 1 (scout)
2. See if fails to launch / display any game window

Logs

Factorio (default - stream-rt 1 scout - unmodified config.vdf): factorio-current_default.log
Factorio (stream-rt 3 sniper - modified config.vdf): factorio-current_steamrt3.log
Shapez2 (default - stream-rt 1 scout - unmodified config.vdf): shapez2_Player_default.log
Shapez2 (default - stream-rt 3 sniper - modified config.vdf): shapez2_Player_steamrt3.log

Please advise which additional useful info I could provide to narrow down the issue. glxgears and Gist - glxinfo work fine and since the games are 64bit already the 32bit compat libs shouldn't matter / play a role? For completeness the Gist - list of 32bit/i686 installed libraries

[kisak-valve]

Hello @tgurr, https://gist.github.com/tgurr/aa4a01fe191cfae0d9ed4978e0505f0d#file-gistfile1-txt-L592 looks like it's obscuring if there's a more subtle issue going in. What's there implies that you're just comparing a damaged or incomplete scout install to a healthy sniper install.

Please give https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information a read and see if you can collect a pressure vessel log with Steam doing the setup of scout, either for the runtime diagnostics or for a game.

[tgurr]

Please give https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information a read and see if you can collect a pressure vessel log with Steam doing the setup of scout, either for the runtime diagnostics or for a game.

@kisak-valve thanks for the hint, I've run steam with STEAM_LINUX_RUNTIME_LOG=1 steam and here are the requested logs:
Steam Runtime Diagnostics: slr-non-steam-game-t20251217T183919.log
Factorio: slr-app427520-t20251217T184220.log
Shapez2: slr-app2162800-t20251217T183236.log

[smcv]

-						"name"		"steamlinuxruntime"
+						"name"		"SteamLinuxRuntime_sniper"

This is not something that is intended to be supportable. The interface provided by Steam Linux Runtime 3.0 (sniper) is not intended to be compatible with Steam Linux Runtime 1.0 (scout): it discards several legacy ABIs that were provided by scout and therefore are relied on by some older games, such as libpng 1.2, gstreamer 0.10 and SDL 1.2.

sniper is only intended to be used by Linux games that were compiled in a sniper environment, like Counterstrike 2 or Retroarch, and Proton versions that were compiled in a sniper environment, like Proton 10.

Game developers wanting a more modern runtime environment can opt-in to using sniper, like the CS2 and Retroarch teams did (and I'd encourage developers of actively-maintained Linux games to do so), but that does need to be accompanied by recompiling the game in the sniper SDK, and testing the result.

[smcv]

Distribution (e.g. Ubuntu 18.04): Exherbo Linux

Remind me, what's unusual about Exherbo Linux? If I remember correctly, it uses cross-compiler-like directories (/usr/x86_64-pc-linux-gnu/lib for x86_64); is there anything else that users of a more typical distro like Debian or Arch would find surprising?

I'm thinking in particular of the ecosystem around libX11 and libGL: I dimly remember some distro having combined libX11 and a bunch of other related libraries into one large/monolithic library, but I can't remember whether that was Exherbo.

[smcv]

In the steam-runtime-system-info report:

/usr/bin/steam-runtime-system-info: symbol lookup error: /usr/bin/steam-runtime-system-info: undefined symbol: json_from_string

This is certainly not right, and implies that something has somehow gone badly wrong with the handling of libjson-glib.

I'm surprised to see that the Steam Linux Runtime 1.0 container ("scout runtime container" in the report) is not working, but Steam Linux Runtime 2.0 ("soldier runtime container") is OK. For historical reasons, SLR 1.0 consists of a SLR 2.0 container, with the legacy LD_LIBRARY_PATH runtime layered onto the top of it for backward compatibility with older games.

And according to the system info report, the legacy LD_LIBRARY_PATH runtime ("LD_* scout runtime") is also working fine when run on your Exherbo host system - it's only when we combine the SLR 2.0 container with the legacy LD_LIBRARY_PATH runtime that things go badly wrong.

Perhaps move your steamapps/common/SteamLinuxRuntime directory out of the way (so that we have a copy that can be inspected later), and then do a Verify integrity on the Steam Linux Runtime 1.0 (scout) compatibility tool?

[smcv]

I've run steam with STEAM_LINUX_RUNTIME_LOG=1 steam and here are the requested logs

Adding STEAM_LINUX_RUNTIME_VERBOSE=1 will collect more info, and might help to diagnose what is going on.

The closest thing we have to a useful diagnostic message so far is Factorio reporting:

   0.024 Error SDLWindow.cpp:260: Failed to create an application window. SDL_Error: Couldn't find matching GLX visual
   0.024 Error Util.cpp:81: Fehler beim Erstellen eines Anwendungsfensters. SDL_Error: Couldn't find matching GLX visual

... which, at a guess, might indicate that it's somehow having trouble loading Mesa's GLX drivers?

[smcv]

soldier 2.0.20251202.187501

This is the public beta of "Steam Linux Runtime 2.0 (soldier)". It would be interesting to know whether the same issue occurs with the non-beta version 2.0.20250929.168591, and if yes, whether it also occurs with the previous_release beta branch which should currently be at 2.0.20250826.159137.

[tgurr]

Replying to #791 (comment)

Yea and probably the reason why shapez2 crashes now hence I mentioned it's probably unrelated, but it allowed to me work around the problem locally for some time now and in the case of factorio it still works even though unsupported, I have to apologize that I didn't have time to actually report this issue properly and lived with that workaround for far too long now.

[tgurr]

Replying to #791 (comment)

Basically nothing that special apart from the /usr//lib cross directory layout /usr/x86_64-pc-linux-gnu/lib & /usr/i686-pc-linux-gnu/lib. We have regular packages and don't really destinct between host and cross, so more or less everything is cross and the packag reciepe is identical (we're source-based) and no large/mono stuff.

[tgurr]

Replying to #791 (comment)

Done that (moved away the directory and verified integrity to re-download stuff) and sadly it didn't help, looking at the content of slr 1.0 (scout) it seems it's just a wrapper to slr 2.0 soldier (which you've mentioned) so there's not that much of content:

-rwxr-xr-x  1 tgurr tgurr  447 18. Dez 16:12 mtree.txt.gz
-rwxr-xr-x  1 tgurr tgurr 2692 18. Dez 16:12 README.md
-rwxr-xr-x  1 tgurr tgurr  546 18. Dez 16:12 run-in-scout-on-soldier
-rwxr-xr-x  1 tgurr tgurr 8889 18. Dez 16:12 scout-on-soldier-entry-point-v2
-rwxr-xr-x  1 tgurr tgurr  203 18. Dez 16:12 toolmanifest.vdf
drwxr-xr-x  3 tgurr tgurr 4096 18. Dez 16:17 var
-rwxr-xr-x  1 tgurr tgurr  227 18. Dez 16:12 VERSIONS.txt

[tgurr]

soldier 2.0.20251202.187501

This is the public beta of "Steam Linux Runtime 2.0 (soldier)".

I've switched to the beta versions of the runtimes since I run steam beta (mainly to catch early issues/regressions but also to have the latest goodies) and have read that you should also use the beta versions of the runtimes together with steam beta.

It would be interesting to know whether the same issue occurs with the non-beta version 2.0.20250929.168591, and if yes, whether it also occurs with the previous_release beta branch which should currently be at 2.0.20250826.159137.

I have reverted to the stable versions and it's exactly the same behaviour so no immediate regression, as mentioned in one of my posts above, and I probably forgot to note that in the initial report, I'm experiencing this issue for quite some time now, can't tell exactly (as most games are Proton-based these days stumbling upon native builds has become quite rare). Looking at my factorio achievements and when I bought shapez2 I'm pretty sure I had the issue already nov/dec 2024 so it may have already happened / never worked when 1.0 scout became just a wrapper for 2.0 soldier maybe(?)

Edit: For completeness the log with the stable runtimes: slr-app427520-t20251218T161701.log

[tgurr]

I've run steam with STEAM_LINUX_RUNTIME_LOG=1 steam and here are the requested logs

Adding STEAM_LINUX_RUNTIME_VERBOSE=1 will collect more info, and might help to diagnose what is going on.

The closest thing we have to a useful diagnostic message so far is Factorio reporting:

   0.024 Error SDLWindow.cpp:260: Failed to create an application window. SDL_Error: Couldn't find matching GLX visual
   0.024 Error Util.cpp:81: Fehler beim Erstellen eines Anwendungsfensters. SDL_Error: Couldn't find matching GLX visual

... which, at a guess, might indicate that it's somehow having trouble loading Mesa's GLX drivers?

That's why I above also included the information of glxinfo and that glxgears runs fine. If there's anything else that comes to your mind that I can test in this regard I'd be glad to test.

Adding STEAM_LINUX_RUNTIME_VERBOSE=1 will collect more info, and might help to diagnose what is going on.

STEAM_LINUX_RUNTIME_VERBOSE=1 STEAM_LINUX_RUNTIME_LOG=1 steam log for factorio: slr-app427520-t20251218T165507.log

[smcv]

I'm experiencing this issue for quite some time now, can't tell exactly (as most games are Proton-based these days stumbling upon native builds has become quite rare). Looking at my factorio achievements and when I bought shapez2 I'm pretty sure I had the issue already nov/dec 2024

Certainly not a recent regression, then! That takes away a lot of the urgency to understand it.

Let's use Factorio as the canonical example of a game in which you are suffering this issue.

I've switched to the beta versions of the runtimes since I run steam beta (mainly to catch early issues/regressions but also to have the latest goodies) and have read that you should also use the beta versions of the runtimes together with steam beta.

They're no longer as tightly coupled as they were in the past, but it's good to have users of unusual distros running the beta so that we can get an early warning when the beta regresses something.

[smcv]

at a guess, might indicate that it's somehow having trouble loading Mesa's GLX drivers?

That's why I above also included the information of glxinfo and that glxgears runs fine.

On the host, sure - but they might well not work if you ran them in the SLR environment. (Which unfortunately you can't easily do, because the container doesn't have them, but it does have other diagnostic tools like wflinfo.

If/when you're able to spend some time digging into this issue, please try this: set Factorio to run under SLR 1.0, set its launch options to PRESSURE_VESSEL_SHELL=instead %command%, and run it. Instead of the game, you'll get an xterm inside the container which you can explore interactively. In the case of SLR 1.0, the xterm is actually in the SLR 2.0 'soldier' container, without the legacy compatibility layer for games from 2012, which means we can compare/contrast with and without that layer.

It's the traditional xterm rather than something more modern, so you'll have to use drag-to-select and middle-click paste (or redirect output to files) if you need to copy information out of it.

Here are some things you could try in that environment:

• steam-runtime-system-info > ~/tmp/slr2.log (this should be equivalent to the soldier runtime container in Help -> Steam Runtime Information)
• /mnt/games/Steam/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- steam-runtime-system-info > ~/tmp/slr1.log (this should be equivalent to the scout runtime container in Help -> Steam Runtime Information)
• or maybe /mnt/games/Steam/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info > ~/tmp/slr1.log might work better?
• wflinfo --platform glx --api gl (this is vaguely similar to glxinfo)
• /mnt/games/Steam/steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2 -- wflinfo --platform glx --api gl
• steam-runtime-identify-library-abi --ldconfig-paths --one-line
• /sbin/ldconfig -XNv | grep '^.*:'