Soldier runtime prevents proton from running

[CosmicToast]

Your system information

• Steam Runtime Version: v0-111-gc94c8fd | soldier 0.20201007.0
• Distribution (e.g. Ubuntu 18.04): Fedora 33
• Link to your full system information (Help -> System Information) in a Gist: https://gist.github.com/CosmicToast/f9079360bb0533700d2564fba0b34a4b
• Have you checked for system updates?: Yes
• Are you using the Steam Linux Runtime compatibility tool?: Yes (Proton 5.13 dependency)

Please describe your issue in as much detail as possible:

1. Launch steam with PRESSURE_VESSEL_VERBOSE=1
2. Run a game with proton 5.0-9 - launches
3. Run a game with proton 5.13 - does not launch
4. Edit soldier entrypoint to skip over it, run agame with proton 5.13 - launches

This narrows down the culprit to soldier.
Note that in the log there is a 5. this is a repeat with point 3 (unedited proton 5.13) but the launch options reset to default, purely for demonstration purposes.

Log edits:

1. Username change to "USER"
2. Hostname changed to "HOSTNAME"
3. Steam Username changed to "STEAMUSER"
4. Additional ____ STEP X ____ were inserted to help identify the steps from the above description. These are purely informative (i.e may not be at the VERY start of the block, but I did put in reasonable effort).

Full log: https://gist.github.com/CosmicToast/7a1dd02c9bc7a2d3cc2005bfea79df0b
The expected results are for step 3 (and 5) to launch the game.

Steps for reproducing this issue:

Repeat of the above for consistency purposes.

1. Launch steam with PRESSURE_VESSEL_VERBOSE=1
2. Run a game with proton 5.0-9 - launches
3. Run a game with proton 5.13 - does not launch
4. Edit soldier entrypoint to skip over it, run agame with proton 5.13 - launches
5. Edit soldier entrypoint back to its original state (or use "verify files") and remove any launch options (while staying with proton 5.13) - does not launch

MISC

There are various reports of people having trouble with proton 5.13.
Since the issue is clearly with the runtime, this issue is here to serve as a meta tracker, as well as consolidate the soldier runtime-specific data.
Common reports talk about disabling the runtime, which is done in this log (this is step 4) for demonstration and logging purposes.
Note that PROTON_LOG with proton 5.13 and the runtime enabled has no effect (thus it was not included).

Other threads to see:

• Proton 5.13 forces Steam Linux Runtime -> No MangoHud flightlessmango/MangoHud#369 (comment) (procedure for disabling soldier runtime)
• Proton 5.13 breaks all non-Linux games Proton#4278 - one of the related proton issues. Though one person in the thread had a different problem, people with this issue are in the thread as well.
• Proton 5.13-1 can't run games in Gnome Wayland session Proton#4270 - another related issue (original reporter not seeing issues with the runtime disabled)

Additional details: prior to the log running, all components involved (scout runtime, soldier runtime, proton 5.0 and proton 5.13) were reinstalled. The game being tested (wildfire) is installed on the same disk as them (the main one in /home) for clarity purposes.

[smcv]

consolidate the soldier runtime-specific data

This might be counter-productive. There are lots of reasons why the container-based runtime might fail to start, with the same user-facing symptom (it doesn't start). Fixing one root cause will have no effect on all the others.

If people use a single issue report for multiple root causes, then in practice we will never be able to close that issue report, because there will always be one more root cause that isn't fixed yet - and that isn't particularly helpful for issue tracking and triaging.

[smcv]

Common reports talk about disabling the runtime

You can experiment with this for your own interest, but please do not recommend it, especially to less knowledgeable users. Disabling or bypassing the Steam Runtime, either the older LD_LIBRARY_PATH runtime or the newer container runtimes, is completely unsupported.

Proton 5.13 is compiled to run on Steam Runtime 2 'soldier' and is not expected to work in other runtime environments. If native Linux games are compiled against 'soldier' in future, they will also be intended to work only on 'soldier', not in other runtime environments. (There are currently no native Linux games on Steam that need 'soldier', and it's unlikely to happen until the container runtime system is more robust.)

Similarly, older Proton builds like 5.0, and all current native Linux games on Steam, are compiled against Steam Runtime 1 'scout' and intended to run in a 'scout' environment, either the traditional LD_LIBRARY_PATH runtime (which ends up being a mixture of 'scout' and the host system) or the newer SteamLinuxRuntime container runtime. They are not intended to run in any other environment (not even 'soldier').

[CosmicToast]

please do not recommend it

I'm not recommending it.
The statement is there for two purposes:

1. The issue is severe enough that there are people already doing this, with examples.
2. It actively demonstrates that the root cause is soldier (since it is the only variable being modified).

It not being supported is obvious, since it's modifying steam internals.

Though on that note, this is the typical "different library versions" problem, so all that really matters is (non-kernel) ABI compatibility. The general concept of a runtime environment is consequently mostly void.
Looking into soldier I'm seeing only a couple of things actually bundled, namely:

• glibc 2.28 (fair, glibc loves breaking abi)
• nss modules (not sure why that's needed, but they're bundled with glibc so it's fine)
• pam (does not break ABI very often afaik)
• gtk 2, gtk 3 and pixbuf 2 (does not break ABI very often afaik)
• v4l (not sure why this is here)
• pulse 12.2 libraries (this will actually likely break systems running pipewire as their only audio daemon)
• gio (which is prominent in the logs (dconf settings) for failing to load)
• gconv (does not break abi very often afaik)
• dri (including virtio, old nouveau and vm drivers, and even radeon; but not amdgpu for some reason)
• python (understandable since proton has python components)

This is actually a significant departure from scout, which also included some common things, such as:

• openssl
• pango
• sasl
• gstreamer
• alsa

Which I would expect to be used relatively often (e.g openssl in games with networking).

From this I induce that soldier is (at least for now) explicitly just the bare minimum required for proton 5.13, which does indeed raise the question of why it needs gtk 2, gtk3, v4l and similar.

This might be counter-productive. There are lots of reasons why the container-based runtime might fail to start, with the same user-facing symptom (it doesn't start). Fixing one root cause will have no effect on all the others.

Are you perchance familiar with the concept of a meta-bug?
If these issues turn out to be separate root causes I have little issue with adding a checklist with the various root causes to the OP.

[TTimo]

The "STEP 3" logs show no sign of problem with the soldier container layer - the various Proton commands are executed and work as expected. If the game does not start (fails before it opens a render window I assume), the root cause may be exposed in Proton or the title logs.

[CosmicToast]

The "STEP 3" logs show no sign of problem with the soldier container layer

At the end of the day, disabling the layer leads to games launching, while it being enabled results in no game being launchable.

I ran a quick test with PROTON_LOG=1 set in the launch options (instead of globally for the steam client) and it looks like this method actually works (I have no idea why it wouldn't otherwise, maybe some part of the process strips global env).
https://gist.github.com/CosmicToast/de260555716c77c64d4d8aad9a5cda2e

The relevant part appears to be this:

239006.303:0020:00a4:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
239006.303:0020:00a4:err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.

This is running on gnome+wayland, but xwayland is very much enabled.
Is it possible that the dri components of soldier are outdated or don't expect to be run in a wayland (with xwayland) session?
Alternatively, could it be the lack of amdgpu in dri? (this is a navi10 card)

[TTimo]

Likely running into: ValveSoftware/Proton#4266

[CosmicToast]

I'm closing this in favor of ValveSoftware/Proton#4289.
Though the issue seems to be in pressure vessel / soldier, there's an existing (more complete) meta issue so it makes sense to defer to it.