pressure-vessel don't find ld.so whenever I launch any game using proton

[zn3x]

Your system information

• Steam Runtime Version: Up to date with arch linux package rolling release
• Distribution: Arch linux
• Have you checked for system updates?: Yes
• Are you using the Steam Linux Runtime compatibility tool?: Yes

When running any game using proton I get the following error in debug:

pressure-vessel-wrap[2400]: Configuring runtime /home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier/files...
pressure-vessel-wrap[2400]: pv_runtime_provide_container_access: Using bwrap to set up runtime that is just /usr
pressure-vessel-wrap[2400]: Enumerating EGL ICDs on provider system...
pressure-vessel-wrap[2400]: Enumerating Vulkan ICDs on provider system...
pressure-vessel-wrap[2400]: Enumerating Vulkan explicit layers on provider system...
pressure-vessel-wrap[2400]: Enumerating Vulkan implicit layers on provider system...
pressure-vessel-wrap[2400]: Checking for x86_64-linux-gnu libraries...
pressure-vessel-wrap[2400]: run: '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/x86_64-linux-gnu-capsule-capture-libs' '--print-ld.so'
pressure-vessel-wrap[2400]: -> /lib64/ld-linux-x86-64.so.2
pressure-vessel-wrap[2400]: run: '/usr/sbin/bwrap' '--ro-bind' '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier_0.20210126.1/files' '/usr' '--symlink' 'usr/lib64' '/lib64' '--symlink' 'usr/lib' '/lib' '--symlink' 'usr/bin' '/bin' '->
bwrap: Can't find source path /run/host/etc: No such file or directory
pressure-vessel-wrap[2400]: Container does not have /lib64/ld-linux-x86-64.so.2 so it cannot run x86_64-linux-gnu binaries
pressure-vessel-wrap[2400]: Checking for i386-linux-gnu libraries...
pressure-vessel-wrap[2400]: run: '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/i386-linux-gnu-capsule-capture-libs' '--print-ld.so'
pressure-vessel-wrap[2400]: -> /lib/ld-linux.so.2
pressure-vessel-wrap[2400]: run: '/usr/sbin/bwrap' '--ro-bind' '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier_0.20210126.1/files' '/usr' '--symlink' 'usr/lib64' '/lib64' '--symlink' 'usr/lib' '/lib' '--symlink' 'usr/bin' '/bin' '->
bwrap: Can't find source path /run/host/etc: No such file or directory
pressure-vessel-wrap[2400]: Container does not have /lib/ld-linux.so.2 so it cannot run i386-linux-gnu binaries
pressure-vessel-wrap[2400]: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)
pressure-vessel-wrap[2400]: Exiting with status 1
>>> Adding process 2402 for game ID 813780
>>> Adding process 2404 for game ID 813780
>>> Adding process 2405 for game ID 813780
>>> Adding process 2406 for game ID 813780
>>> Adding process 2408 for game ID 813780
>>> Adding process 2409 for game ID 813780
>>> Adding process 2410 for game ID 813780
Game removed: AppID 813780 "", ProcID 2399

Same thing happens When I try running a PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log from ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/ log.txt

[kisak-valve]

Hello @mobrine1, I suspect your issue is similar to #300. Can you try something similar to #300 (comment)?

[zn3x]

Hi, I think soldier folder now are in .local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var, I did try to rename soldier_0.20210126.1 to something like soldierbug and add file keep inside it, but I still get same error.
Also I did try to uninstall steam soldier from steam client, and removing it manually. But same happens

[zn3x]

Just wanted to add this. Until this is fixed, if you suffer from same issue, and don't mind running game outside of the SLR container try this

[smcv]

if you suffer from same issue, and don't mind running game outside of the SLR container

Please try not to propagate this workaround further around the internet. The purpose of the SLR container is to give Proton the libraries it needs, at the versions it needs. Running official builds of Proton 5.13+ without the SLR container is unsupported - if it works, it's only working by coincidence.

[smcv]

pressure-vessel-wrap[2400]: run: '/usr/sbin/bwrap' '--ro-bind' '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier_0.20210126.1/files' '/usr' '--symlink' 'usr/lib64' '/lib64' '--symlink' 'usr/lib' '/lib' '--symlink' 'usr/bin' '/bin' '->
bwrap: Can't find source path /run/host/etc: No such file or directory

What is /usr/sbin/bwrap, and what Arch Linux package does it come from?

Are you running Steam inside a container?

When you run ./run -- steam-runtime-system-info --verbose to debug, are you running that inside the same container?

[smcv]

Please attach Steam system information (Help -> System Information) as requested in the bug reporting template.

[zn3x]

• /usr/sbin/bwrap comes from bublewrap package from arch pacmanager

$ pacman -Qo /usr/sbin/bwrap
/usr/bin/bwrap is owned by bubblewrap 0.4.1-1

• When running ./run -- steam-runtime-system-info --verbose:

bwrap: Can't find source path /run/host/etc: No such file or directory
bwrap: Can't find source path /run/host/etc: No such file or directory
pressure-vessel-wrap[120]: None of the supported CPU architectures are common to the host system and the container (tried: x86_64-linux-gnu, i386-linux-gnu)

• Yes I'm running steam under a systemd-nspawn container, all commands are done in this container, container doesn't depend on any host binary/library, in fact I don't have anything related to steam in host machine to run that command with
• info.txt

[smcv]

Yes I'm running steam under a systemd-nspawn container

The pressure-vessel container runner is not really designed to be run inside a container, although it can work in some cases.

I think the problem here is that pressure-vessel is detecting that it's being run inside an intermediate container (because /run/host exists) and assuming that you want the graphics drivers from the host system, not from the intermediate container. This mechanism is designed for Flatpak apps with --filesystem=host-os. However, /run/host in your container doesn't make the host's /etc available at /run/host/etc, so this fails.

For the best match for what would happen in non-pressure-vessel games, we should probably default to using graphics drivers from the environment in which pressure-vessel itself was run (possibly with an exception made for Flatpak), unless we're specifically told to do otherwise.

[zn3x]

pressure-vessel-wrap[2172]: run: '/usr/sbin/bwrap' '--ro-bind' '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier_0.20210208.0/files' '/usr' '--symlink' 'usr/lib64' '/lib64' '--symlink' 'usr/lib' '/lib' '--symlink' 'usr/bin' '/bin' '--symlink' 'usr/lib32' '/lib32' '--symlink' 'usr/.ref' '/.ref' '--symlink' 'usr/sbin' '/sbin' '--ro-bind' '/home/steam/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/soldier_0.20210208.0/files/etc' '/etc' '--ro-bind' '/run/host' '/run/gfx/usr' '--ro-bind' '/run/host/etc' '/run/gfx/etc' 'readlink' '-e' '/lib/ld-linux.so.2'
Yeah it seems like it's trying to read only bind /run/host/etc but it ends up not finding it

[smcv]

Workaround: try running Steam with PRESSURE_VESSEL_GRAPHICS_PROVIDER=/ in the environment.

[smcv]

You will not necessarily be able to run pressure-vessel inside a system-nspawn container at all, depending on the extent to which systemd-nspawn restricts what we can do. pressure-vessel needs to create new namespaces, and if systemd-nspawn doesn't allow that, then it just won't work.

A good rule of thumb is that if you can run a simple Flatpak app, pressure-vessel can also be made to work (we recycle a lot of the container-related code from Flatpak).

Being too keen to use /run/host is a bug, which I'm looking into fixing. PRESSURE_VESSEL_GRAPHICS_PROVIDER=/ is a way to make the current version have behaviour similar to what will happen after we fix that bug.

[smcv]

Workaround: try running Steam with PRESSURE_VESSEL_GRAPHICS_PROVIDER=/ in the environment.

Please could you try this workaround and report back whether it is successful?

[zn3x]

Sorry for the delay
using PRESSURE_VESSEL_GRAPHICS_PROVIDER=/ it seems to work fine