- Dec 14, 2023
-
-
Simon McVittie authored
pv-wrap: Don't register stdout, stderr, --pass-fd with FlatpakBwrap See merge request !640
-
Simon McVittie authored
This fixes two separate issues. If we add a file descriptor to the FlatpakBwrap object with flatpak_bwrap_add_fd, then flatpak_bwrap_child_setup() will lseek() back to byte 0 before it execs the replacement process. This is often what we want - for example, when we have written out a file containing the container identification, we want any subsequent read from that file to start at byte 0. However, it is absolutely not what we want if stdout/stderr are directed to a log file, in which case any writes after the lseek() will start from the beginning and overwrite the content of the log file. The symptom for this is that debug messages from pv-adverb start at the beginning of the log file, overwriting earlier debug messages from pv-wrap (but directing the log to a pipe or to the systemd Journal works fine, because those aren't seekable). Similarly, if --pass-fd is being used for a seekable file, we probably don't want to force it to seek back to byte 0. The second issue is that adding a fd with flatpak_bwrap_add_fd() means the FlatpakBwrap object takes responsibility for closing that fd. This was incorrect to do for original_stdout and original_stderr without transferring ownership (which we don't want to do), because they are declared with glnx_autofd, meaning that they will be closed automatically when they go out of scope. In the error code path where pv_bwrap_execve() fails, this means they will be closed twice - once by glnx_autofd, and once by the g_autoptr(FlatpakBwrap) - leading to an assertion failure. This is mitigated by not being a problem in the success code path where pv_bwrap_execve() succeeds, which in practice is the one we always want to reach. Avoid both of these by using a separate list of fds to inherit, not seeking back to the beginning of those, and not closing them. This has the side-effect that fds from --pass-fd are also not closed, but that seems harmless, and arguably more correct: they're open on entry to main(), and they're still open on exit from main(), so no change of ownership has happened. steamrt/tasks#370 Fixes: 779d13fd "pv-wrap: Let pv-adverb restore our original stdout/stderr" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 08, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
populate-depot: Remove all DRI plugins from legacy-free SLR branches See merge request !638
-
- Dec 07, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Refactor creation of symlinks in an emulator's interpreter root See merge request !604
-
Simon McVittie authored
No functional changes in this commit, other than repeating the assertion that mutable_sysroot == NULL implies absence of PV_RUNTIME_FLAGS_INTERPRETER_ROOT in functions that didn't already have it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This just puts them through common code, and converts repeated similar function calls to be table-driven. No functional change intended: they continue to be written to the interpreter root only, as before. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
For files in /etc (and in theory /var), no functional change is intended: this just converts an open-coded equivalent of pv_runtime_bind_into_container() into a call into common code. However, for sockets in /run (as of this commit, only /run/bumblebee.socket, but others might be added in future), we only want to populate the real root's /run, not the rootfs' /run; so we need to distinguish between those two cases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with previous commits, this ensures that they show up in a readdir() of /etc by an x86 process under FEX-Emu. This commit covers files that we get from the host system. As with previous commits, this is actually slightly nicer than what happens under FEX-Emu without using pressure-vessel, which is that these files only exist in the real root and do not show up in readdir() (except for host.conf, which arguably shouldn't be in the rootfs either). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This ensures that it shows up in a readdir() of /etc. As with previous commits, this is actually slightly nicer than what happens under FEX-Emu without using pressure-vessel, which is that the file only exists in the real root and does not show up in readdir(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with previous commits, this means they'll show up in a readdir() from /etc by an x86 process under FEX-Emu. This is actually slightly nicer than what happens under FEX-Emu without using pressure-vessel, which is that these files only exist in the real root and do not show up in readdir(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with previous commits, this ensures that a readdir() on /etc or /var/lib by an x86 process under FEX-Emu will show it as existing. This also reduces repetition a little. This is actually slightly nicer than what happens under FEX-Emu without using pressure-vessel, which is that the machine ID only exists in the real root and does not show up in readdir(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This generalizes commit 5e0f8520 "pv-runtime: Duplicate symlinks in /etc, /var in the interpreter root" to use shared machinery. For symlinks, no functional change is intended; for regular files and directories, this commit gives them the same handling. This ensures that readdir() on those paths by an x86 process in FEX-Emu will show all the files: previously, they would not show up in readdir() (but, confusingly, directly opening them would still have worked). This function call cannot legitimately fail, because the only reason for it to fail would be if the destination was outside /var, which it is not; so treat failure as a programming error, which will cause a critical warning. steamrt/tasks#342 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will allow each --ro-bind to be classified into real root, interpreter root, or both when using FEX-Emu. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will allow commit 5e0f8520 "pv-runtime: Duplicate symlinks in /etc, /var in the interpreter root" to be generalized to cover more of the symlinks we create. No functional change intended, yet: all callers currently pass in EMULATION_ROOTS_INTERPRETER_ONLY, which has the same behaviour that MAKE_SYMLINK_FLAGS_INTERPRETER_ROOT previously did. EMULATION_ROOTS_REAL_ONLY replaces the (currently unused) MAKE_SYMLINK_FLAGS_NONE, and EMULATION_ROOTS_BOTH is new and does both at the same time. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that our $FEX_ROOTFS does not have its own /run, we need this to point to a path that physically exists. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Most of what we export via FlatpakExports or pv_wrap_share_sockets either is meant to show up at a corresponding path inside the container's real root, for example /home -> /home, or belongs to /var and is meant to show up at a corresponding path in the real root and/or the $FEX_ROOTFS, for example /var/tmp -> /var/tmp. However, some paths that come via pv_wrap_share_sockets() are bind-mounts with their destination inside /run/host, for example $FEX_ROOTFS/usr/share/fonts -> /run/host/fonts. We want to mount those in the real root, not in the $FEX_ROOTFS, to avoid a split-brain situation where ARM and x86 code sees a different /run. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
No functional change: all of the current callers are creating symlinks in /etc or /var, or creating the /overrides symlink. This will matter more when we expand the use of this function, to check that we're still using it correctly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Inside our container, both /run and /var are on tmpfs, so both are equally suitable. Using /var for this has the advantage that it avoids a split-brain situation where ARM and x86 code under FEX-Emu will see different content in /run. /var is already split between the real root used by ARM code and the $FEX_ROOTFS used by x86 code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with previous commits, if we do that, then sockets mounted in the real /run won't show up in a readdir() by x86 code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes room for /run/host to be used for the $FEX_ROOTFS. We currently implement this by distinguishing between /run/host and $FEX_ROOTFS/run/host, but we want to stop doing that, because it interferes with path resolution for /run if it exists inside the $FEX_ROOTFS. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We have to mount the graphics provider below $FEX_ROOTFS, so that when other parts of the $FEX_ROOTFS have symbolic links into it, those symlinks are resolved successfully even with FEX's interference (it resolves symlinks as if chrooted into the $FEX_ROOTFS). However, if we mount anything below $FEX_ROOTFS/run, that has the undesired effect that sockets mounted in the real root filesystem's /run are not visible to a readdir() by emulated x86 code. If we move the graphics provider outside /run, we can avoid this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 05, 2023
-
-
Simon McVittie authored
This saves around 100M for a software rendering driver that, in practice, we will never use: we look for the one on the host system instead. steamrt/tasks#364 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 01, 2023
-
-
Simon McVittie authored
pv-runtime: Avoid relying on soname-match and therefore ld.so.cache See merge request !636
-
- Nov 30, 2023
-
-
Ludovico de Nittis authored
populate-depot: Allow SteamLinuxRuntime_whatever/.ref to exist See merge request !637
-
- Nov 29, 2023
-
-
Simon McVittie authored
pv-wrap creates this lock file for compatibility with very old (pre-2021) versions of the Steam Linux Runtime, which took this lock before unpacking scout or soldier from a tarball, because at the time the Steampipe CDN did not cope well with a large number of small files. Fixes: 0f89e027 "populate-depot: Write a top-level mtree" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 28, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Same reasoning as the previous commit, but for the graphics stack rather than NSS. Helps: https://github.com/ValveSoftware/steam-runtime/issues/632 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Normally, operating systems arrange for ld.so.cache to contain all core system libraries for both word sizes, and especially glibc. However, on heavily customized systems, they might not be in the ld.so.cache at all, only in the LD_LIBRARY_PATH. soname-match is implemented in terms of the ld.so.cache and therefore ignores the LD_LIBRARY_PATH, so we cannot rely on it on such systems. Instead, try to load a concrete SONAME directly, which takes into account the LD_LIBRARY_PATH (and other information sources like RUNPATHs). Continue to fall back to using soname-match for future-proofing against possible future glibc changes on systems that make a normal level of use of the ld.so.cache. Helps: https://github.com/ValveSoftware/steam-runtime/issues/632 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 27, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 24, 2023
-
-
Ludovico de Nittis authored
pv-runtime, pv-adverb: Use ${LIB} instead of ${PLATFORM} if possible Closes tasks#349 See merge request !635
-
Ludovico de Nittis authored
pv-wrap: Fix minor issues caught by the test suite See merge request !634
-
- Nov 23, 2023
-
-
Ludovico de Nittis authored
pv-wrap: Don't try to construct a sysroot for a NULL path See merge request !633
-
Ludovico de Nittis authored
subprocess: Avoid using timeout(1) to impose a timeout on subprocesses Closes #88 See merge request !626
-