proton versions newer then 5.0 dont function at all

[Vertabreak]

I've been investigating this and so far none of the versions newer then 5.0 produce any logs at all when configured to. It's like something is happening in the change over from steam to proton. I plan to run steam with console attached to see if steam will give me any additional info. I have tested 5.13 and the experimental version as well as there beta options and a custom version GE latest so far. I welcome suggestions and guidance and am willing to work to correct this. Should my investigating bare fruit I would also be happy to contribute it via pull request back to the community for the greater good. System details xubuntu 21.04 nvidia driver v455 on a gtx 1070 on a 4ghz 8 core amd cpu with 16gb ram.

[kisak-valve]

Hello @Vertabreak, the fact that Proton doesn't generate logs hints that you've encountered a Pressure Vessel issue, which Proton 5.13 and newer uses to run inside of Steam Linux Runtime - Soldier.

---

Please could you show us a log of what pressure-vessel is thinking, and exactly what happens? You can do this without involving Proton (which should make things a bit simpler) like this:

cd /path/to/SteamLinuxRuntime_soldier
PRESSURE_VESSEL_VERBOSE=1 ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log

and then send container.log as a gist. You can edit/censor the log if there's anything in it that you consider private, as long as it's obvious where it has been edited, for instance replacing your username with REDACTED.

The SteamLinuxRuntime_soldier directory will be in one of your Steam libraries. The most likely place is ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier if you haven't reconfigured the installation path.

Also please show us the full system information (Help -> System Information in Steam), after waiting for the diagnostic tools to finish thinking about what drivers you have. Again, you can edit/censor it if you need to, and please send it as a gist.

(from #312 (comment))

[GTB3NW]

Not OP but same issue - https://gist.github.com/GTB3NW/202d43ecd7cdefd9afd4ad78e83f08a5

(sorry about original comment, I've appended it to gist)

[kisak-valve]

Hello @GTB3NW, Pressure Vessel not working the Flathub-provided steam packaging is a known issue being tracked at #294.

[GTB3NW]

Hello @GTB3NW, Pressure Vessel not working the Flathub-provided steam packaging is a known issue being tracked at #294.

Ah crap! Thank you! :)

[jhaand]

Hi,
I run the steam package provided by Debian Testing. When I run the diagnostic command suggested by @kisak-valve, I find the last line peculiar.
bwrap: Can't make symlink at /home: File exists
I don't understand what bwrap wants to do in this case.
You can find the full logging here:
container.log

Note: /home is a symlink to my big data drive /mnt/big-data/home/

[Vertabreak]

This issue is present in ubuntu 21.04 alpha but after revet to stable 20.10 no issues where noted. I don't expect much support for alpha yet as issues are likely os related.

[jhaand]

This issue is present in ubuntu 21.04 alpha but after revet to stable 20.10 no issues where noted. I don't expect much support for alpha yet as issues are likely os related.

Well 21.04 alpha is derived from a current Debian Unstable. So that might indicate the issue was introduced shortly. Since my laptop doesn't have the issue, but my desktop does, there might even be more going on. Although the problem with a symlink to //home might also have to do something with it.
I might create an issue on the Debian bugtracker for this.

[jhaand]

Further investigation.

I tried this command to see where things go wrong.

strace -f ./run ls

It seems that everything goes fine until this part.

[pid 118966] stat("/newroot", {st_mode=S_IFDIR|0755, st_size=340, ...}) = 0
[pid 118966] stat("/newroot/home", 0x7fff822ba9f0) = -1 ENOENT (No such file or directory)
[pid 118966] mkdir("/newroot/home", 0755) = 0
[pid 118966] mount("tmpfs", "/newroot/home", "tmpfs", MS_NOSUID|MS_NODEV, "mode=0755") = 0
[pid 118966] stat("/newroot", {st_mode=S_IFDIR|0755, st_size=360, ...}) = 0
[pid 118966] symlink("mnt/big-data/home/", "/newroot/home") = -1 EEXIST (File exists)
[pid 118966] write(2, "bwrap: ", 7bwrap: )     = 7
[pid 118966] write(2, "Can't make symlink at /home", 27Can't make symlink at /home) = 27
[pid 118966] write(2, ": File exists\n", 14: File exists
) = 14
[pid 118966] exit_group(1)              = ?

The script detects the correct location of my /home directory in /mnt/big-data/home. But the tmpfs gets mounted on this location and then it tries to mount the home directory again on /newroot/home.
Unfortunately pressure-vessel-wrap is an ELF binary, so I can't check what's going on there.
This does not look

[kisak-valve]

Hello @jhaand, please see #321 (comment).

[jhaand]

@kisak-valve Thank you for pointing this out. Doing the bind-mount did solve this issue.
Although it's now a bit harder to figure out how all my mounts are now tied together.

[smcv]

People who are not @Vertabreak: please don't comment here just because you have the same high-level symptom of Proton not starting. Even if the behaviour is superficially similar, there is not enough information in the initial report to know whether you are experiencing the same root cause (for instance, no specific error messages are mentioned).

We are waiting for more information from @Vertabreak to be able to get closer to the root cause of this particular issue report, and until we have that, this particular issue report can't move forward - but that doesn't necessarily mean your issue report can't be fixed.

If you have the same superficial symptom of Proton/the container not starting, please look for more information (see the issue-reporting documentation and #322 (comment) which might help), then look for an issue report that matches more closely than this one does. For instance, bwrap: Can't mkdir parents for /tmp/SOMETHING would point you towards #321. If you don't find a similar issue report that is specific enough to be confident that the root cause is the same, it's better to open a new issue report with whatever details you can find, instead of commenting on a relatively nonspecific issue report like this one.

Otherwise, we'll spend more time figuring out whether people are really experiencing the same issue than we do actually fixing bugs, and nobody wants that.

Thanks!