Skip to content
Snippets Groups Projects
  1. Jan 31, 2024
  2. Jan 30, 2024
  3. Jan 26, 2024
  4. Jan 25, 2024
    • Simon McVittie's avatar
      pressure-vessel: Look for internal Nvidia helper libraries by name · 3ae631a9
      Simon McVittie authored
      The Nvidia drivers have various helper libraries that get loaded as
      dependencies. Some of them are hard dependencies via `DT_NEEDED`, but
      others are loaded dynamically with `dlopen()`: for example,
      at the time of writing, `libGLX_nvidia.so.0` has a `DT_NEEDED`
      dependency on `libnvidia-glcore.so.VERSION` which is sufficient for
      OpenGL, but dlopens `libnvidia-glvkspirv.so.VERSION` when asked to act
      as a Vulkan driver.
      
      Normally, we can find these libraries by their entry in
      `soname_globs_even_if_older[]`, by using the `soname-match:` syntax
      to search `/etc/ld.so.cache` for SONAMEs matching a glob pattern like
      `libnvidia-glvkspirv.so.*`. This works because OS distributions normally
      install these libraries into the default system library directory
      `/usr/lib{,32,64}` or `/usr/lib/MULTIARCH`, which is indexed by
      ldconfig(8).
      
      However, when using Canonical's Snap apps, the Nvidia drivers can only
      be found in the `LD_LIBRARY_PATH`, and `soname-match:` does not
      implement `LD_LIBRARY_PATH` search. This leads to a situation similar
      to https://github.com/ValveSoftware/steam-runtime/issues/632 where
      these libraries are not found. The result is that the Nvidia Vulkan
      driver is present, but fails to load.
      
      If we can read `/sys/module/nvidia/version` (which Flatpak also relies
      on as its way to discover the current Nvidia driver version), then we
      can resolve this by looking for each of the known libraries by name.
      This takes into account `LD_LIBRARY_PATH` and `DT_RUNPATH`, not just
      the `ld.so.cache`. Making this effective will require a snapd change,
      to make `/sys/module/nvidia/version` readable.
      
      Helps: https://github.com/ValveSoftware/steam-runtime/issues/586
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      3ae631a9
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Merge branch 'wip/sr644' into 'main' · eb51817f
      Simon McVittie authored
      pv-wrap: When running in Flatpak, forward inherited fds to subsandbox
      
      See merge request !651
      eb51817f
    • Simon McVittie's avatar
      pv-wrap: When running in Flatpak, forward inherited fds to subsandbox · 9a5be0be
      Simon McVittie authored
      When we are using steam-runtime-launch-client to set up a subsandbox
      for the pressure-vessel container, it is not enough to mark fds as
      non-O_CLOEXEC: we also need to instruct s-r-launch-client to forward them
      over D-Bus to flatpak-portal. We already did this for the fds managed
      by the FlatpakBwrap object, but not for other inherited fds.
      
      Before v0.20240103.0, all fds that we wanted to send to the remote
      subsandbox were managed by the FlatpakBwrap object, but this was wrong
      because it had the side-effect of seeking log files back to byte 0
      (steamrt/tasks#370). Since v0.20240103.0, we split out some of the fds
      into the inherit_fds array, but we did not emit --forward-fd for those.
      
      In some situations (notably launching the SteamLinuxRuntime_sniper
      container for the steamwebhelper process in recent Steam client betas)
      this worked anyway, but it seems that this only happened by coincidence.
      
      Addresses <https://github.com/ValveSoftware/steam-runtime/issues/644>
      and probably <https://github.com/flathub/com.valvesoftware.Steam/issues/1235
      
      >.
      
      Fixes: 8ee66f4c "pv-wrap: Don't register stdout, stderr, --pass-fd with FlatpakBwrap"
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      9a5be0be
  5. Jan 24, 2024
  6. Jan 23, 2024
  7. Jan 19, 2024
Loading