X86 Proton games do not load under pressure vessel

[Kevok93]

Your system information

• Steam Runtime Version:
• Distribution (e.g. Ubuntu 18.04):
  Ubuntu 21.10
• Link to your full system information (Help -> System Information) in a Gist:
  https://gist.github.com/Kevok93/18941966d629d5b5128d505102d2601d
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton 5.13+
• If you are using Steam Linux Runtime, or Proton 5.13 or newer: What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name Version Runtime Runtime_Version Comment
depot 0.20211014.30 # Overall version number
pressure-vessel 0.20210906.2
scripts v0.20210917.0-0-g1cf127d # Entry point scripts, etc.
soldier 0.20211013.0 soldier 0.20211013.0 # soldier_platform_0.20211013.0/

Please describe your issue in as much detail as possible:

Any executables running in x32 bit mode do not launch under protons 5.13+. Games running x64 binaries run just fine.

Steam log output
https://gist.github.com/Kevok93/ece03261f4f28b3d79d3ba708cb87dae

PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log
https://gist.github.com/Kevok93/3e9caa0f8d717dcbf926263c55a6dbd0

[RyuzakiKK]

It seems like the i386-linux-gnu-inspect-library fails with a segmentation fault, and this leads to have unexpected libraries inside the container for i386.

Just to exclude an issue with the new Ubuntu 21.10, I tried it on a VM and I was not able to reproduce it.

If for example you try to run ~/.steam/steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/libexec/steam-runtime-tools-0/i386-linux-gnu-inspect-library libGL.so.1 does it correctly print in output the information about libGL.so.1? (adjust the path if you installed SteamLinuxRuntime Soldier in another location)

[Kevok93]

It does,

{
  "libGL.so.1": {
    "SONAME": "libGL.so.1",
    "path": "/lib/i386-linux-gnu/libGL.so.1",
    "dependencies": [
      "linux-gate.so.1",
      "/lib/i386-linux-gnu/libdl.so.2",
      "/lib/libc.so.6",
      "/lib/ld-linux.so.2",
      "/lib/i386-linux-gnu/libGLdispatch.so.0",
      "/lib/i386-linux-gnu/libGLX.so.0",
      "/lib/i386-linux-gnu/libX11.so.6",
      "/lib/i386-linux-gnu/libxcb.so.1",
      "/lib/i386-linux-gnu/libXau.so.6",
      "/lib/i386-linux-gnu/libXdmcp.so.6",
      "/lib/i386-linux-gnu/libbsd.so.0",
      "/lib/i386-linux-gnu/libmd.so.0"
    ]
  }
}

[smcv]

It's not just i386-linux-gnu-inspect-library, i386-linux-gnu-detect-platform is also segfaulting:

pressure-vessel-adverb[58769]: W: Unknown expansion of the dl string token $PLATFORM: Unhandled wait status 139 (killed by signal?)

[smcv]

I wonder whether this might be part of the problem:

      "library-details" : {
        "libc.so.6" : {
          "soname" : "libc.so.6",
          "path" : "/lib/libc.so.6",
          "issues" : [
            "missing-symbols"
          ],
          "missing-symbols" : [
            "malloc_get_state@GLIBC_2.0",
            "malloc_set_state@GLIBC_2.0"
          ]
        }
      },

[smcv]

... wait, why do you have /lib/libc.so.6 on an Ubuntu system? I would have expected the only libc.so.6 on Ubuntu to be /lib/x86_64-linux-gnu/libc.so.6 and /lib/i386-linux-gnu/libc.so.6, because Ubuntu uses multiarch paths.

[smcv]

If you run /sbin/ldconfig -XNv on the host system and show us the output, that might give us some clues.

[Kevok93]

$ stat /lib/libc.so.6
  File: /lib/libc.so.6 -> /lib/i386-linux-gnu/libc.so.6
  Size: 29              Blocks: 8          IO Block: 4096   symbolic link
Device: 1ch/28d Inode: 45055992    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-10-26 22:37:26.182596329 -0400
Modify: 2021-07-14 05:51:17.981166332 -0400
Change: 2021-07-14 05:51:17.981166332 -0400
 Birth: 2021-07-14 05:51:17.981166332 -0400

Dunno why it's there, but at least they're the same file. EDIT: dpkg-query doesn't know why either, so it might be something old. Not sure why the mtime is only july then though.

$ dpkg-query --search /lib/libc.so.6 
dpkg-query: no path found matching pattern /lib/libc.so.6

ldconfig at https://gist.github.com/Kevok93/2ef57ea9befff981d5c9e79d4dc70b5f

EDIT2: I deleted the symlink, and steam-runtime-system-info doesn't crash anymore, but games still don't start. Uploading new logs.
https://gist.github.com/Kevok93/c3c723db6a178b67a093ece8153e89bf
https://gist.github.com/Kevok93/bae2be52dc26811a19ddb59139199c49
https://gist.github.com/Kevok93/df375ef2de030f7864df2e3a975c4cde

[smcv]

Hmm, this is weird. I'm not seeing any 32-bit libraries at all in your ldconfig output; it's as though /etc/ld.so.conf.d/i386-linux-gnu.conf has somehow gone missing.

Does debsums -a libc6:i386 report any errors? (You might have to install the debsums package first)

[smcv]

This seems suspicious as well:

/lib: (from <builtin>:0)
...
	ld-linux.so.2 -> ld-lsb.so.3

[Kevok93]

Alright, so I have no idea what DPKG's major malfunction was, but /etc/ld.so.conf.d/i386-linux-gnu.conf did disappear and reinstalling libc6:i386 refused to recreate it... My best guess was that dpkg -D7777 suggested very vaguely that creating the config file was skipped, based only on this line (below). However, I was able to --force-all --purge libc6:i386 and reinstall, which was able to unstupify DPKG and get my install fixed.
86303 D000020: deferred_configure '/etc/ld.so.conf.d/i386-linux-gnu.conf' (= '/etc/ld.so.conf.d/i386-linux-gnu.conf') useredited=1 distedited=0 what=202

At this point, games appear to be running again. I have absolutely no idea what happened to my system's x86 installs, but I don't believe this has anything to do with Steam, and I'm happy to close the issue. Thanks everyone for your support!

[kisak-valve]

Closing per the last comment.

[smcv]

Alright, so I have no idea what DPKG's major malfunction was, but /etc/ld.so.conf.d/i386-linux-gnu.conf did disappear and reinstalling libc6:i386 refused to recreate it...

FYI, if you have deleted a configuration file, dpkg interprets that as a configuration change, and preserves it across upgrades and reinstallations.

In this case, you presumably didn't deliberately delete the configuration file (maybe it was deleted by some tool you ran or by some piece of third-party software you installed?), but dpkg can't know the difference.