Proton 5.13-1 doesn't run with Flatpak Steam

[andreldmonteiro]

Proton 5.13-1 literally doesn't run any game, when clicked to play it will run and exit immediately.

Log:
proton5.13.txt

System info:
https://gist.github.com/monterrr/ed24a7ff787aa3e9e938fea607c5d2b8

Flatpak steam issue:
flathub/com.valvesoftware.Steam#642

[kisak-valve]

Hello @monterrr, this looks like a pressure vessel issue:

pressure-vessel-wrap[465]: Cannot run flatpak-spawn: wait status 256
pressure-vessel-wrap[465]: Diagnostic output:
Portal call failed: org.freedesktop.DBus.Error.ServiceUnknown

ln: failed to create symbolic link '/run/user/1000/SteamLinuxRuntime.a78991da9d9637b4/socket' -> '': No such file or directory

Please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[andreldmonteiro]

Bug has been updated.

[kisak-valve]

Thanks, pressure vessel currently can not be run inside of a Flatpak Steam install. The pressure vessel devs noted this in the initial announcement of the Steam Linux Runtime.

[andreldmonteiro]

I've been running all previous versions of proton and proton-ge without any issues there.

[ghost]

I've been running all previous versions of proton and proton-ge without any issues there.

Believe this is because this Proton version is built against the Steam runtime that provides pressure vessel as the change log states.

But, I feel Valve has made it a bit confusing for people to understand the whole thing. I'm really confused myself though I understand what they're doing.

Not sure if pressure vessel can be disabled or why Proton uses it when steam runtime isn't selected which seemed to be what was needed previously.

Too many unknowns.

[AsciiWolf]

Same issue on my Fedora 32 Workstation system with Flatpak Steam from Flathub and Proton 5.13-1. Is it possible to disable Pressure Vessel and run Proton directly just like the older versions used to run?

[gasinvein]

@AsciiWolf Yes, but it's not guaranteed to work properly since it would run on top of different Steam Runtime.

[ahvth]

For a whole host of reasons, Flatpak is currently the best way to use Steam on Linux (read: X sandbox under wayland so I don't have to switch from my secure wayland desktop to X to play games that rely on it, running my system with only 64-bit libs installed natively, and also true distro agnosticism).

It would be genuinely wonderful if Valve would work with the Steam for Flatpak maintainers to get this working!

[ahvth]

@kisak-valve I'm tagging you because you are the only Valve representative in the thread.

I had a chat with an acquaintance in the Fedora Telegram group and he had a productive suggestion on how to solve this issue without compromises in Pressure Vessel's functionality.

Essentially, the idea would be to not enforce enforce the process isolation by conditionally skipping the spawning of a new namespace if already inside a namespace (or perhaps if the namespace just fails to spawn in general), as would be the case when running Steam in a flatpak. Presumably the new namespace is spawned as part of the "better isolation" intended as part of this new packaging method, but it's our opinion that this is redundant if Steam itself is already isolated from the host system.

See bubblewrap and its implementation of FS rebinding without a user namespace.

I'd love to hear what the devs think about the feasibility of this! ❤️

[kisak-valve]

Hello @ahvth, friendly note that I'm a moderator for Valve's issue trackers on Github and not a Valve dev myself. We'll need to hear from a Pressure Vessel dev if there's progress on this issue. As a tracking note, I left this on the Proton issue tracker for a while for visibility, but this issue is something to be resolved in Pressure Vessel or related projects.

[smcv]

See also flathub/com.valvesoftware.Steam#642.

See bubblewrap and its implementation of FS rebinding without a user namespace.

This is exactly how pressure-vessel works - we use bubblewrap (we even use code recycled from Flatpak to run it). However, Flatpak doesn't allow that, because it would undermine some of the namespace properties that Flatpak relies on for security.

Solving this properly is not straightforward. We aim to solve it, but it will require code in both Flatpak and pressure-vessel (flatpak/flatpak#3797 is the Flatpak side).

There are community builds of Proton 5.13 against the freedesktop.org SDK that can be used in the meantime (see flathub/com.valvesoftware.Steam#642).

the idea would be to not enforce enforce the process isolation by conditionally skipping the spawning of a new namespace if already inside a namespace

We are not using the new namespace for process isolation, so this wouldn't help. pressure-vessel is not a security boundary.

We are using the new namespace to get the ability to replace /usr with a known library stack, eventually on a per-game basis, so that old native Linux games can use Steam Runtime 1 'scout' (like Proton 5.0 does), new native Linux games can use Steam Runtime 2 'soldier' (like Proton 5.13 does), and even newer native Linux games can use a future Steam Runtime 3, without new games causing old games to regress.

We are using the new namespace to replace /usr, rather than using an LD_LIBRARY_PATH a mile long like the traditional Steam Runtime setup did, because it is becoming clear that the LD_LIBRARY_PATH approach is not sustainable. In particular, if we want to be able to ship runtimes that are strictly newer than some users' systems (for example when Steam Runtime 2 'soldier', which is based on Debian from 2019, is run on the Ubuntu 18.04 legacy LTS version from 2018), then we cannot do that with LD_LIBRARY_PATH and must use filesystem namespaces.

The first thing to be using Steam Runtime 2 happens to have been Proton 5.13 rather than a game, because the Proton developers were finding it increasingly difficult and limiting to keep compiling Proton against what is effectively a version of Ubuntu from 2012. It's the same principle: the official Proton 5.13 binaries want the library stack from Steam Runtime 2, not older, not newer.

There's more background information in the doc/ directory of this repository or in my talk at FOSDEM 2020.

[ahvth]

I just wanted to say thanks for taking the time to reply, and it all sounds very exciting!

[nickavem]

I love the Steam flatpak (and maybe even hope valve upstreams it at some point wink) and I really hope this issue gets fixed soon. Community Proton Builds built on the actual flatpak runtime seem to bypass a lot of these issues. This can easily be installed with flatpak install com.valvesoftware.Steam.CompatibilityTool.Proton and should show up with all the other proton versions in Force the use of a specific compatibility tool. I'm honestly not completely sure how or why it works, but hey, it works!

[cold-distance]

Hi, I just want to say that Proton provided through Steam doesn't work with the Flatpak version of the client, but Proton Community Edition provided through Flatpak seems working.

I'm using Fedora 33 Workstation now, but I'm thinking to switch back to Debian Bullseye with the Flatpak version of Steam because my intention is to keep Bullseye when it becomes into the Stable branch of Debian, so the parallel version of Mesa provided in Flatpak format can be very helpful for me.

[MavropaliasG]

Hi, I wanted to share my output, as I just purchased Bloons TD 6, and I am trying to run it with Proton experimental and nothing happens. See attached info about my system, and the terminal output when I tried to run the game (twice) unsuccessfully.

Output
https://gist.github.com/MavropaliasG/363bb9fa4b6725c459aa98c6f2973754

My system
https://gist.github.com/MavropaliasG/0e680530e57495658aaf90d0f1677f92

@kisak-valve mentioned that this belongs here. Dota 2 (running without Proton) opens and plays fine.

[smcv]

Hi, I just want to say that Proton provided through Steam doesn't work with the Flatpak version of the client, but Proton Community Edition provided through Flatpak seems working.

This is the current state. There is no need to post comments or logs that confirm this: we are aware that this issue exists.

As several people have already said, the community builds of Proton can be used as a workaround. They are not supported by Valve, but neither is the Steam Flatpak app.

This issue will be updated when there is something available to test. Until then, there is no need to reply or comment. The eventual solution is likely to require updated versions of both Flatpak (I'm hoping to get the necessary code included in Flatpak 1.10) and the SteamLinuxRuntime_soldier depot.

[smcv]

With the latest development versions of everything, it is possible to run games in the container runtime from within Flatpak (including official Valve releases of Proton 5.13 and 6.3, and the "Steam Linux Runtime" for native Linux games). At the moment this is still an "early adopters"-only feature.

You need:

• An operating system where unprivileged users can create user namespaces (non-setuid bubblewrap)
  • Debian >= 11 can work, Debian <= 10 won't
  • RHEL/CentOS >= 8 can work, RHEL/CentOS <= 7 won't
  • Arch Linux with the default linux kernel can work, Arch Linux with linux-hardened and bubblewrap-suid won't
  • Most other distributions can work (e.g. Ubuntu)
• Flatpak 1.11.1 or later. This is a development version, so use it at your own risk.
  • Ubuntu users can get this from the PPA
  • Debian users can get this from experimental
  • Arch Linux users can find this in the default repositories
• A fully-up-to-date version of the Steam Flatpak app
  • It should list the per-app-dev-shm feature in its permissions
• For Proton games: Steam Linux Runtime - soldier version 0.20210415.0 or later
  • All supported versions should meet this requirement by now
  • Check steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt to see which version you have
• For native Linux games with "Steam Linux Runtime": Steam Linux Runtime version 0.20210415.0 or later
  • All supported versions should meet this requirement by now
  • Check steamapps/common/SteamLinuxRuntime/VERSIONS.txt to see which version you have

Known issue: flatpak/flatpak#4286 can result in games failing to launch (it's intermittent). Re-launching the same game will usually succeed. This has been fixed in Flatpak git master, and the fix should be in 1.11.2 (not yet released).

If you are sure that you have all the requirements, and it still isn't working, please report a new issue. Please be as specific as possible and make sure to include all the required information.

If you do not have all of the requirements above, then this will not work. Please don't report that as a bug.

[hpfr]

I believe this can be closed due to smcv's much-appreciated work on Flatpak 1.12.

[kaimast]

Yes, this has been fixed for a while now as far as I can tell.

[cold-distance]

Now I'm focused on native games for Linux, but I'm using Fedora Silverblue and I did two gameplays with Proton took from the Steam client. Both worked fantastic but they are old games (Dead Space and Doom 2016).

[smcv]

I believe this can be closed due to smcv's much-appreciated work on Flatpak 1.12.

To confirm, yes, Flatpak 1.12.x is the first stable branch that fixes this. You want at least 1.12.1 for some regression fixes (but the latest 1.12.x, currently 1.12.2, is better). Debian 11 users can get this from bullseye-backports, and Ubuntu users can get this from the Flatpak PPA (if all goes well, Ubuntu 22.04 should come with a suitable version in the base distro).

As mentioned in my previous comment, you need an OS with unprivileged bubblewrap. I believe the latest versions of all major distros meet this requirement, with one notable exception: Arch Linux's non-default linux-hardened kernel.

All the other requirements mentioned in my previous comment should be easy to get now.

[kisak-valve]

Closing per the last comment.