Proton 5.13: bwrap: Can't mkdir parents for /tmp/pressure-vessel-wrap.XXXXXX/overrides

[juliansangillo]

I upgraded to Proton 5.13-4 so that I can play Cyberpunk 2077. Unfortunately, the game crashes consistently each time I try to start it. Same thing happens to the other two games I have installed which worked with Proton 5.0.10, RollerCoaster Tycoon 3: Platinum and RWBY: Grimm Eclipse. Even though I only have these 3 games installed, it seems no games will start for me with the newest Protons. I even tried with Proton experimental and it is the same result.

Perhaps there is some library I am missing on my system? It is hard to tell as there are no good logs that I know of that mentions the crash and why it happened. Please assist as soon as possible. Thanks.

OS: Ubuntu 20.04.1 LTS KERNEL: 5.4.0-54-generic CPU: AMD Ryzen 9 3900X 12-Core GPU: AMD AMD Radeon RX 5600 XT (NAVI10, DRM 3.35.0, 5.4.0-54-generic, LLVM 11.0.0) GPU DRIVER: 4.6 Mesa 21.0.0-devel (git-a9a8e05 2020-12-10 focal-oibaf-ppa) RAM: 32 GB

[kisak-valve]

Hello @juliansangillo, please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, 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.

[juliansangillo]

@kisak-valve Thanks for replying so quickly. I just tried the launch options you gave but it is not even generating the log. I even tried to set PROTON_LOG_DIR to my home directory to make sure it wasn't being generated somewhere else and that didn't work.

Here is the gist for my Steam system information.

https://gist.github.com/juliansangillo/4a2e15d70e3fdfbcfb2bc2b4281d3565

[kisak-valve]

The last line of the extended diagnostic information tells us that Pressure Vessel, which sets up Steam Linux Runtime - Soldier, the container environment that Proton 5.13 and newer runs inside, encountered a problem.

To steal the comment from @smcv at https://github.com/ValveSoftware/steam-runtime/issues/312#issuecomment-741037038:

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.

[juliansangillo]

Sure. Only thing I censored was my username. I replaced every occurrence with REDACTED. Everything else is the same.

https://gist.github.com/juliansangillo/79c84447cd7ba246b291c45ffcbece08

[smcv]

I think the key thing here is:

bwrap: Can't mkdir parents for /tmp/pressure-vessel-wrap.8VORV0/overrides: No such file or directory

[smcv]

@kisak-valve or @juliansangillo, please could you retitle this to avoid attracting comments from people who are seeing issues that have the same symptom but a different root cause? Something like:

Fails to start Proton 5.13: bwrap: Can't mkdir parents for /tmp/pressure-vessel-wrap.XXXXXX/overrides

[smcv]

It's trying to run this long command-line:

pressure-vessel-wrap[47170]: run: '/usr/bin/bwrap' \
'--ro-bind' '/' '/' \
'--bind' '/tmp/pressure-vessel-wrap.8VORV0/overrides' '/tmp/pressure-vessel-wrap.8VORV0/overrides' \
<many more options>

and the error message means it's failing to create /tmp/pressure-vessel-wrap.8VORV0/overrides to use as a mount point.

This is weird, because we create that directory before running the command, and --ro-bind / / should mean that every directory that exists on the host also exists in the container.

@juliansangillo, do you have anything unusual in your setup for /tmp, like unusual mount options, or a polyinstantiated /tmp (meaning different programs see different directories for /tmp), or libpam-tmpdir, or a "reaper" program that automatically removes temporary files?

[juliansangillo]

@smcv There isn't any reaper program that I am aware of. I just tried to mkdir that directory in question and it created it just fine, so it isn't permissions or anything like that. The only thing I can think of is that on my system, /tmp is actually a symbolic link to /data/tmp with /data mounted on another drive. I have it setup where some of my directories are on the other drive (/data) and instead have symbolic links to them.

I would normally not think that a symbolic link is an issue since it should be able to reference it just fine, but could it be that it is unable to create the directory for that reason? This is the only unusual setup that I am aware of with tmp that may have an impact.

[smcv]

The only thing I can think of is that on my system, /tmp is actually a symbolic link to /data/tmp with /data mounted on another drive

Aha, this could well be it. Workaround: use a bind-mount instead of a symlink.

Bind mounts are generally a better way to offload data onto another drive.

I would normally not think that a symbolic link is an issue since it should be able to reference it just fine

Normally yes, but symlinks sometimes cause weird issues, particularly when crossing container boundaries (which changes the meaning of filesystem paths).

[juliansangillo]

I see. I never thought to use bind mounts instead of symlinks when I first set up the system. I replaced the /tmp symlink with a bind mount. The games still crash but it takes longer to do so this time. I reran the command to generate a new container.log. Seems it no longer has an issue with /tmp but now has an issue with /home, which is also a symlink. So I think this is the problem.

When I get a moment, I am probably just going to replace all my symlinks in root that are pointing to /data with the corresponding bind mounts to prevent these kinds of issues from happen again later. Will let you know if the games are able to run after that.

[smcv]

Seems it no longer has an issue with /tmp but now has an issue with /home, which is also a symlink

That'll potentially have similar problems, yes. In principle both ought to work, and we've been trying to fix this systematically; but there are a lot of directories that we want to import into the container, and each one potentially needs changing to not do the obvious thing.

[juliansangillo]

I just changed all my symlinks to bind mounts and that worked. My games are finally able to run. Guess now I know I should be using bind mounts instead for what I was trying to do. Thanks for all the help @smcv and @kisak-valve .

[smcv]

Note to anyone trying to reproduce this: when I tried this on a test system, a relative symlink /tmp -> TMP actually works fine, but /tmp -> /TMP fails like this.

[smcv]

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/199 fixes this for /tmp.

/home being a symlink is harder to deal with. There's some refactoring that we need to do anyway, for Flatpak support, that should make it easier.

[juliansangillo]

Note to anyone trying to reproduce this: when I tried this on a test system, a relative symlink /tmp -> TMP actually works fine, but /tmp -> /TMP fails like this.

That's funny. All of my symlinks were absolute, which explains that.

[jhaand]

OK. This looks indeed like the problem I have in #322. I will try this shortly. Especially being able to use relative links should make this easier.

[jhaand]

Thank you for pointing this out. Doing the bind-mount did solve this issue.

Using relative links didn't work unfortunately.

Although it's now a bit harder to figure out how all my mounts and drives are now tied together. But that's progress I guess. ;-)

[DistantThunder]

Hi, I re-installed Solider/pressure vessel a few moments ago as I was having issues with Mangohud again specifically with Proton VKD3D titles.

I think I may be hitting this user's problems, I can't run anything with Proton 5.13.x as a result...:

pressure-vessel-wrap[3832930]: Replacing self with bwrap...
bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system
ln: failed to create symbolic link '/tmp/SteamPVSockets.AVr7WY/SteamLinuxRuntime.6ec29bbe56106482/socket' -> '': No such file or directory
ERROR: ld.so: object '/home/_USER_/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/_USER_/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
pressure-vessel-launch[3837936]: Can't connect to peer socket: Could not connect: No such file or directory

My /tmp/ is a proper mount with a submount to a RAMFS in a subdir but nothing too exotic I'd say.

[kisak-valve]

Hello @DistantThunder, there's a good chance you're encountering #303 instead of the issue reported here.

[DistantThunder]

Hi @kisak-valve, I dropped MANGOHUD from the CLI but no games are running at all with Pressure Vessel at the moment. The issue is beyond Vulkan Layers for me atm.

You must be right about the original MANGOHUD issue, but I think I've hit something else as well.

EDIT: Uploading my log. pv_c2077.problems.zip

• System: Host: HOST Kernel: 5.9.13-3 x86_64 bits: 64 compiler: N/A Desktop: N/A Distro: Arch Linux
• CPU: Topology: 8-Core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP arch: Zen L2 cache: 4096 KiB
• Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] vendor: Sapphire Limited driver: amdgpu v: kernel bus ID: 0c:00.0 Display: tty server: X.Org 1.20.10 driver: amdgpu resolution: 2560x1440~144Hz OpenGL: renderer: AMD Radeon RX 5700 XT (NAVI10 DRM 3.39.0 5.9.13-3-gc LLVM 11.0.0) v: 4.6 Mesa 21.0.0-devel (git-ac0d393eb1) direct render: Yes

[smcv]

@DistantThunder You are not experiencing the same bug as the original reporter of this issue. The key thing in your log is:

bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system

I've opened #328 for this. Other people have seen this before, but we've never been able to get the necessary information to figure out what is wrong or fix it, so I'll be asking you for more information over on #328.

[DistantThunder]

@smcv

Fair enough. Thanks for your time.

[smcv]

The original issue reported here is partially fixed in pressure-vessel versions >= 0.20210105.0. /tmp being a symlink should now be OK, although I would still recommend using bind-mounts instead of symlinks for large-scale rearrangement of the filesystem hierarchy.

These versions are available in the beta branch of SteamLinuxRuntime and SteamLinuxRuntime_soldier starting from today (check VERSIONS.txt). They are not in the normal/stable branch yet, but probably will be soon.

An ancestor of $HOME being a symlink (such as /home -> /media/bigdisk/home, where your home directory is /home/me) is not expected to work yet. That's still a known issue. Workaround: use bind-mounts.

$HOME itself being a symlink (such as /home/me -> /media/bigdisk/home/me) hasn't been tested, but probably has the same problem, with the same workaround.