- Jul 02, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is desirable if we are running something other than the main game, for example steam-runtime-system-info or various preparatory steps involved in running Proton. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 24, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
- Jun 23, 2020
-
-
Simon McVittie authored
Follow-ups for !26 See merge request steam/pressure-vessel!54
-
Simon McVittie authored
runtime: handle merged-/usr host OS with non merged-/usr container See merge request steam/pressure-vessel!53
-
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
Because we do a "cheap copy" with hard-links where possible, .ref is a hard-link to its counterpart in the original (non-copied) runtime, so a lock on one is a lock on the other. We hold a lock on the original runtime while we do setup, so we would never actually delete the temporary runtimes unless we break the hard-link by re-creating the lock file. Resolves: T22035 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This log file contains pressure-vessel's debug messages (which happen outside the scout container), not just the output of inside-scout.py, so calling it inside-scout.log is misleading. If we're running pressure-vessel-wrap --only-prepare, then we never actually get as far as running inside-scout.py or entering the container, so the log file name is doubly misleading. 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 makes it easier to try out UI changes in the source tree: we can do everything except actually launching pressure-vessel-wrap. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Prioritize "/usr/" over "/lib/" if it is available to avoid issues when we use a non merged-/usr container with a host system that is merged-/usr (Fixes: T22125) Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This has the advantage of always being an absolute path. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 17, 2020
-
-
Simon McVittie authored
Create a mutable copy of the runtime See merge request steam/pressure-vessel!26
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Flatpak is not going to give us control over the root directory when using sub-sandboxing - the most we're likely to get is control over which directory is chosen to be /usr. Prepare for this by using /usr/lib/pressure-vessel/overrides instead of /overrides for the things we overwrite. To be nice to developers and steam-runtime-tools, put a symlink overrides -> usr/lib/pressure-vessel/overrides at the root, as a hint for where to look. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a mutable sysroot, overwrite ld.so with a symlink into /run/host. We overwrite both the interoperable path (to avoid long chains of symlinks in the common case) and the canonicalized path (to make sure nothing can end up finding the container's ld.so, which is incompatible with the libc we have dropped in). If building a long bwrap command-line, we have to mount over the canonicalized path, and just live with the fact that there will be a long chain of symlinks leading to it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We currently arrange for the overridden libraries to be used by setting the LD_LIBRARY_PATH, but this fails in two cases: - If we want to use the scout LD_LIBRARY_PATH Steam Runtime inside a newer container (approximating how Steam games currently run in practice), it will reset the LD_LIBRARY_PATH instead of prepending to it. - Games also sometimes overwrite the LD_LIBRARY_PATH instead of prepending to it. We can avoid all that by arranging for our directories in /overrides to be in the default search path for ld.so, by editing ld.so.conf and running ldconfig, like Flatpak does (T14481). However, if we do that, we cannot reliably force a resolution order: ldconfig considers the OS ABI tag, which exists on some libraries and in particular on the versions of glibc and Mesa in scout, to be more important than directory search order. See also: https://bugs.freedesktop.org/show_bug.cgi?id=26663 If we don't remove the unwanted version of glibc, we also run the risk of encountering mismatched copies of glibc and ld.so, leading to an immediate crash. This is particularly likely to happen if we use bwrap to enter the partially-set-up container. Because we have a temporary mutable copy of the sysroot, we can solve this easily by deleting the overridden libraries. That way, there can be no confusion: the only remaining implementation of each SONAME is the one we wanted :-) Note that after removing the overridden libraries, we will be unable to execute code in the sysroot without mounting /overrides/lib and setting up the LD_LIBRARY_PATH to point into it: for example, in the common case where we have taken libc from the host, the mutable sysroot no longer contains libc.so.6. This is why it's so important that a previous commit avoided the call to readlink(1) inside the container for the mutable case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we have a mutable copy of the sysroot (which we know is a complete sysroot, not just /usr), then we don't need to use bwrap to rearrange it into something where we can canonicalize a path. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
A possible future enhancement would be to have an option to mount some of these (those that live in the mutable sysroot) read/write, but for now any ad-hoc developer modifications will have to happen outside the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This no longer needs to be read/write, because we make all the changes we are going to make during setup. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The host system is assumed to be at least as new as scout (otherwise nothing will work, least of all pressure-vessel-wrap), so we can assume that the host glibc will be used. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we don't need to alter the PATH in the runtime. If we're using a mutable runtime, we'll delete the version in the runtime and replace it with a symlink to /run/host/usr/bin/locale or similar; if not, we'll bind-mount the host /usr/bin/locale onto it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because that isn't going to work if you have EGL/Vulkan ICDs installed in your home directory or something, and the JSON file is small, we fall back to copying in this case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Feature parity with the existing code requires that we check for a compatible container: in containers where /usr/share/libdrm is not a directory, this won't work. Beef up the compatibility check a bit so that it checks for directory vs. non-directory generically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We only strictly need pressure-vessel-with-lock and GLib (and we could skip even the GLib dependency if we assume the runtime contains GLib >= 2.32, as all ours do), but the relocatable copy is designed to be portable to any OS, so for now let's copy the whole thing in. When we do it like this, it's in /usr, because we anticipate that Flatpak sub-sandboxing is not going to give us control over /run. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
For gconv we only make the assertion for a Debian host for now, because non-Debian hosts put their gconv libraries in different places. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Flatpak sub-sandboxing won't let us bind-mount arbitrary things over arbitrary locations, but if we have a mutable copy of the runtime, we can delete runtime content and replace it with host system equivalents. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're about to start editing the mutable runtime in-place to replace files we don't want with symlinks to /run/host, but if /run/host isn't mounted then that can't work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Even in the case where we're using a temporary directory, it's going to survive at least as long as the call to locale-gen, so we don't need to translate it into a long series of --dir and --symlink directives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This means we're able to inspect it in --only-prepare mode. At the moment we still create /overrides/bin/localedef, /overrides/bin/locale, and sometimes EGL and Vulkan JSON via --symlink or --ro-bind, so we have to make /overrides read/write from the perspective of the container. However, when we have moved to creating those files as symlinks in /overrides, we will be able to lock it down to read-only from the perspective of the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
I'd originally intended this to be done by a wrapper script, but in fact it's just as straightforward to do it here, which has the advantage that it keeps all the knowledge about the contents of the temporary runtimes directory in one place. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-