steam-runtime icon indicating copy to clipboard operation
steam-runtime copied to clipboard

pressure-vessel not finding gconv modules, drirc.d on NixOS?

Open smcv opened this issue 4 years ago • 9 comments

System information

Issue report from @baracoder's logs:

  • Steam Runtime Version: unofficial scout from NixOS; soldier depot 0.20210630.17, modified with unofficial build of pressure-vessel from https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/336
  • Distribution (e.g. Ubuntu 18.04): NixOS
  • Link to your full system information (Help -> System Information) in a Gist: https://gist.github.com/baracoder/cd6bcaa1aede3261fde16c9be609c944
  • 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?: see above

Steps for reproducing this issue:

  • Run Steam with STEAM_LINUX_RUNTIME_LOG=1
  • Overwrite SteamLinuxRuntime_soldier/pressure-vessel/ with unofficial build from https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/336
  • Run a game under Proton 5.13+, e.g. Soldat
  • Inspect log

Please describe your issue in as much detail as possible:

23:38:37.721369: pressure-vessel-wrap[865116]: I: We were expecting the gconv modules directory in the provider to be located in "/nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/gconv", but instead it is missing
23:38:37.721486: pressure-vessel-wrap[865116]: I: We were expecting the drirc.d directory in the provider to be located in "/nix/store/di9209219s0zq5nsz93qibhi66xfic09-mesa-21.1.4-drivers/share/drirc.d" or "/usr/share/drirc.d", but instead it is missing
...
23:38:37.849537: pressure-vessel-wrap[865116]: I: We were expecting the gconv modules directory in the provider to be located in "/nix/store/d2lr6zj99qymk1c8qci433yjx1ggx5l4-glibc-2.32-48/lib/gconv", but instead it is missing
23:38:37.849618: pressure-vessel-wrap[865116]: I: We were expecting the drirc.d directory in the provider to be located in "/nix/store/7v68h5sr6wzlprv6mk5wcv9srhpmg972-mesa-21.1.4-drivers/share/drirc.d" or "/usr/share/drirc.d", but instead it is missing
23:38:37.854388: pressure-vessel-wrap[865116]: W: Found more than one possible libdrm data directory from provider

This might mean that programs in the soldier container cannot load:

  • glibc plugins for conversion between non-UTF-8 character sets via iconv(), located in ${libdir}/gconv on FHS distributions like Debian
  • Mesa workarounds and tweaks from drirc.d/00-mesa-defaults.conf, located in /usr/share/drirc-d on FHS distributions

which could cause weird bugs.

The warning about "more than one possible libdrm data directory" is probably harmless, as long as the 32- and 64-bit versions of libdrm are using sufficiently similar versions of amdgpu.ids and any other data files in libdrm/. These would be located in /usr/share/libdrm on FHS distributions.

We'll need help from @baracoder or another NixOS user to be able to do anything about this.

smcv avatar Jul 22 '21 11:07 smcv

Information we'll need:

  • It would be useful to see a log similar to the ones on #431, but captured after running Steam with STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 steam. This will be more verbose than the normal log and might include more personal information like filenames etc., which you can redact if necessary. The parts I'm particularly interested in are a few lines before and after any mention of gconv, libc.so.6, libGLX_mesa.so.0, drirc.d, libdrm.so.2 or share/libdrm.

  • Where does NixOS keep its gconv plugins? What you're looking for is a directory containing files like gconv-modules, gconv-modules.cache and UTF-16.so. On Debian, it's /usr/lib/x86_64-linux-gnu/gconv and /usr/lib/i386-linux-gnu/gconv. From @baracoder's log, it looks as though we might have found libc.so.6 at /nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/libc.so.6, so we were expecting /nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/gconv/, but that directory doesn't exist.

  • Where does NixOS keep its drirc.d? What you're looking for is a directory containing 00-mesa-defaults.conf. On Debian it's in /usr/share/drirc.d. In @baracoder's log, it looks as though we found /nix/store/di9209219s0zq5nsz93qibhi66xfic09-mesa-21.1.4-drivers/lib/libGLX_mesa.so.0, and we expected to find an adjacent drirc.d in /nix/store/di9209219s0zq5nsz93qibhi66xfic09-mesa-21.1.4-drivers/share/drirc.d.

smcv avatar Jul 22 '21 11:07 smcv

i don't have the ability to collect a log right now, but i can quickly give info about the other two things:

  • i have the exact path you mentioned in my local nix store so i can answer this one directly; /nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/gconv/ absolutely does exist, so i'm not sure why it's not being found. it's also linked in at /usr/lib/gconv in the steam fhsenv.
  • the mesa package has multiple outputs. what you're looking for is in mesa.out, not mesa.drivers. they are at completely different store paths, so it's impossible to find one relative to the other. from what i can see, mesa is supposed to be in the environment steam runs in. if share/drirc.d isn't being linked into a fhs location, that might be on us to fix.

ashkitten avatar Jul 22 '21 18:07 ashkitten

I think we might be using the realpath() of the library to find these; even if there's a symlink in the FHS environment used for Steam, we seem to be looking for them in /nix.

what you're looking for is in mesa.out, not mesa.drivers. they are at completely different store paths, so it's impossible to find one relative to the other

That's unfortunate, because the only way we can guess where this particular OS puts files that are conceptually part of a library or loadable module is to get the path of that library or loadable module, and then work from there.

smcv avatar Jul 22 '21 18:07 smcv

If you are providing logs to help to debug this issue, please use SteamLinuxRuntime_soldier depot 0.20210703.18 or newer. As of 2021-07-23, this is available in the client_beta branch of Steam Linux Runtime - soldier, but not in the default branch. It will be copied to the default branch when we are more confident that it does not cause new regressions.

smcv avatar Jul 23 '21 11:07 smcv

I have uploaded the logs from running Soldat with STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 steam on runtime version depot 0.20210723.18 There is also a list of files found in /nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/ https://gist.github.com/baracoder/6996099b3796b29adc3cd3dc76081671

baracoder avatar Jul 23 '21 12:07 baracoder

Oh, I see what the problem is for gconv. To cope with unmerged-/usr systems like older Debian installations, if we find libc.so.6 in /lib, then we look for the gconv modules in /usr/lib/gconv rather than the obvious /lib/gconv. We're currently applying that to all paths, so we look in /usr/nix, which is wrong; but we should probably only do it for /lib*, or we should try the obvious path first and fall back to trying again with /usr prepended, or something like that.

Also, the log message is misleading: it's based on where we found libc.so.6, not on where we actually looked.

I think this part of the issue is a pressure-vessel bug, which we should fix there.

smcv avatar Jul 23 '21 13:07 smcv

As for drirc.d:

14:04:58.110926: pressure-vessel-wrap[1074962]: I: We were expecting the drirc.d directory in the provider to be located in "/nix/store/di9209219s0zq5nsz93qibhi66xfic09-mesa-21.1.4-drivers/share/drirc.d" or "/usr/share/drirc.d", but instead it is missing

If NixOS developers are willing to take responsibility for solving the drirc.d part of the issue, then this:

if share/drirc.d isn't being linked into a fhs location, that might be on us to fix

might be the best way to do it.

smcv avatar Jul 23 '21 13:07 smcv

my pull request fixing this was merged and i can confirm it solves the drirc.d issue. https://nixpk.gs/pr-tracker.html?pr=131279 for tracking its progress

ashkitten avatar Jul 24 '21 19:07 ashkitten

Great, let's use this issue to deal with the gconv side (which is pressure-vessel's fault). I'll try to get that sorted out in a future beta. It isn't going to be a particularly high priority, because at the moment it's only a theoretical issue (we haven't had any reports of it breaking things in practice), but we should clean it up eventually.

smcv avatar Jul 24 '21 22:07 smcv