- Mar 24, 2020
-
-
Ludovico de Nittis authored
If we are using the host's libc, we also bind its `locale` otherwise it might happen that the container's `locale` will not be able to run. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 23, 2020
-
-
Ludovico de Nittis authored
The container didn't have the host system's gconv modules, and the host system's glibc didn't use the Steam Runtime's older gconv modules because they weren't in the directory where it expected to find them. Now if we are using the host's glibc we also bind its gconv modules. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 18, 2020
-
-
Ludovico de Nittis authored
If we are using the host's libc, we also bind its ldconfig otherwise it's likely that the container's ldconfig will not be able to run. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 04, 2020
-
-
Simon McVittie authored
Now that we have this working, there's no real reason why we need a separate run per filename/SONAME pattern; we can just do them all at once, leaving only ICDs with more complicated requirements to be done separately. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it a bit clearer what's going on. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In practice we always want the host graphics stack, but maybe this will be useful when debugging. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This sketches out roughly how we'd do this if we were in a container such as a Flatpak environment, rather than on the host system. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There's very little refactoring so far: bind_runtime() is still basically monolithic, and takes individual bits of PvRuntime's state rather than a PvRuntime object. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
wrap.c is getting rather large, so the idea is that this will encapsulate everything related to swapping in a different /usr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 26, 2020
-
-
Simon McVittie authored
This will let us duplicate a runtime and edit it in-place. The major appeal of doing this is that it's something we can do in a Flatpak environment, where recursively invoking bubblewrap isn't allowed. It also seems like it might yield a more reliable way to overwrite parts of the runtime with their host-system equivalents than the tricks we currently use with files and directories mounted over their runtime counterparts. The major down side is that after we've done this, we have a copy of the runtime, which we need to garbage-collect and clean up eventually. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We want all the libQUAL directories, including lib32 and lib64 (and in principle also libx32, libn32 etc.), but we specifically don't care about libexec. Real systems don't usually symlink /usr/libexec into the root directory. If we create a /libexec symlink, the only effect it might have is that game developers start relying on it, which we certainly don't want. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
libdrm reads /usr/share/libdrm/amdgpu.ids to find information about AMD GPUs. So if we are using libdrm.so.2 from the host we also mount its libdrm folder. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 17, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In the case where we bind-mounted the entire root filesystem, since commit 77f3e3d7 we mounted it over the top of API filesystems like /dev, /proc, /sys. This results in /dev being mounted with the nodev option, which breaks a lot of normal functionality like /dev/null. Some games can work despite this, but only badly (Floating Point launches with indirect or software rendering and a horrible framerate), and the xterm activated by PRESSURE_VESSEL_SHELL=instead fails to launch because it can't create a pseudo-terminal. Adjust the order to get this right. Fixes: 77f3e3d7 "wrap: Make sure the intermediate bwrap object can be used as a base" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 10, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's a little confusing if we run p-v-wrap --test --verbose, which logs: pressure-vessel-wrap: Original argv: ... pressure-vessel-wrap: Checking for bwrap... and then exits. If we add one last line pressure-vessel-wrap: OK (/usr/bin/bwrap) then the result is clearer. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In some places we said exit status, but meant wait status (the status from waitpid() or similar, which encodes whether the process exited normally, the exit status if yes, the fatal signal if any, and whether a core was dumped). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us import files from Flatpak that explicitly #include "config.h" as-is, reducing avoidable delta. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 03, 2020
-
-
Jeremy Whiting authored
When --test is used check for bubble wrap executable and return 0 if found, 1 otherwise.
-
- Jan 23, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Taken from Flatpak. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This syncs us up with how Flatpak does it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes us match how Flatpak includes it, which makes our versions of Flatpak files more similar. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Taken from Flatpak. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps us more in sync with the equivalent code in Flatpak, helping us to merge fixes from there. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 06, 2020
-
-
Simon McVittie authored
Non-OFD locks don't propagate across fork(), and bwrap needs to clone() itself (which behaves like fork() in this respect) to separate itself into a parent outside the container and a child inside the container. This change adds a weak dependency on Linux 3.15. If we run on an older version, everything should still *work*, but there will be a short period of time during which we have already decided to use the runtime, but it is not locked (and in particular not protected from deletion). Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These more modern locks, introduced in Linux 3.15 and not yet included in POSIX, propagate across fork(), dup(), fd-passing etc. the way you'd expect: as long as at least one copy of the inherited or fd-passed file descriptor remains open, the lock remains held. This allows us to pass a lock fd to a child process across bwrap's fork-and-exec the way we were already trying to, and have it actually work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is redundant with us passing the fd to be held by pressure-vessel-with-lock, and it causes bwrap to produce the wrong exit status (see https://github.com/containers/bubblewrap/issues/336 and https://github.com/containers/bubblewrap/pull/325 ). It should have been removed when the "pass the lock fd" code path was added. Fixes: 959fd338 "wrap: Take out a lock on the container's runtime for the duration" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 13, 2019
-
-
Simon McVittie authored
When we're using a non-trivial runtime, we need to make pressure-vessel-with-lock available to the container. Previously, if your pressure-vessel installation was visible via your home directory (if shared), via $(realpath ~/.steam/steam), or via the current working directory at the time of running pressure-vessel-wrap, then it would exist in the container at the same path as outside the container, so this would work. However, if you have installed it in an alternative Steam library such as /media/big/library, none of these mount points would make it visible and bwrap would fail to run it. Circumvent this by mounting the relocatable pressure-vessel prefix on /run/pressure-vessel, which lets us run it via that path. Bug: https://github.com/ValveSoftware/steam-runtime/issues/204 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 14, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can use this in the SteamLinuxRuntime depot to deploy and garbage-collect runtimes stored in tarballs. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-