- Aug 09, 2024
-
-
Simon McVittie authored
If we're using a pressure-vessel-based container framework, it's potentially still desirable to switch to a LDLP runtime under test. This affects the execution environment for the reaper, the steam-launch-wrapper, and pressure-vessel-unruntime (although we expect that its effect is undone by pressure-vessel-unruntime). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's reasonable for steam-launch-wrapper to want to adjust the PATH or LD_LIBRARY_PATH that were provided by the LDLP runtime, for example for steamrt/tasks#489. That won't work if we immediately overwrite them by switching into a different LDLP runtime. This also means that while testing a non-default LDLP runtime, we'll use the runtime under test (and not the LDLP runtime that Steam is using, if different) to run the steam-launch-wrapper and reaper. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
They were already treated as functionally equivalent. Formalize that by turning them into an ordered list of essentially arbitrary "adverb" wrappers. The functional change here is that previously, we would only have recognised the nesting used in practice by Steam, where `%command%` expands to: reaper ... -- steam-launch-wrapper ... -- [compat-tools --] game but now we recognise, and preserve, the opposite order, which is preferable if steam-launch-wrapper starts putting its contents into a systemd cgroup: steam-launch-wrapper ... -- reaper ... -- [compat-tools --] game steamrt/tasks#266 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv-utils: Reserve /var/lib/dbus, /var/run See merge request !745
-
- Aug 07, 2024
-
-
Simon McVittie authored
If the user has /var/run as a directory (not a symlink), and if they (unwisely) run with --filesystem=/var/run, then that would prevent us from creating the symlink `/var/run -> ../run`. steamrt/tasks#493 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need to prevent /var/lib/dbus (and parent directories like /var/lib) from being shared with the container. Otherwise, a /var/lib/dbus/machine-id that is a regular file on the host can prevent us from creating it as a symlink (to /etc/machine-id) in the container. steamrt/tasks#493, steam-runtime#688 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 06, 2024
-
-
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
capsule-capture-libs: Add log severity prefixes, silence a confusing warning about libnvidia-pkcs11 See merge request !742
-
Simon McVittie authored
My understanding is that these libraries are dlopen'd by other parts of the Nvidia driver for confidential-computing GPGPU use-cases, and unlikely to be critical for gaming. There are currently two implementations, one that depends on OpenSSL 1.1 and one that depends on OpenSSL 3.0. The way they are packaged in Ubuntu means that in 24.04, the one for OpenSSL 1.1 is present but does not have its dependencies satisfied, leading to confusing warning messages from capsule-capture-libs that could confuse our users. Silence those messages by using the new "quiet:" pattern prefix. (The message is actually reduced to LOG_DEBUG level rather than being silenced, so CAPSULE_DEBUG=tool will reinstate it if someone needs to look at capsule-capture-libs behaviour in fine detail.) steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us highlight warnings and fatal errors from capsule-capture-libs as such. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
SLR 1.0: Assume that steam-runtime.tar.xz is a monolithic tarball See merge request !744
-
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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
logger: Fix always re-opening files when --log-fd is used See merge request !743
-
Simon McVittie authored
Previously, if we were using --remap-link-prefix but not --link-target (as in pressure-vessel), and if the path at which we found the library in the provider (`needed_path_in_provider`) was such that after resolving symlinks, the canonicalized result (`path`) did not match any of the --remap-link-prefix options, then we would reset to using the `needed_path_in_provider` as the symlink target. However, this was wrong, because it did not take into account the possibility that the original path might have matched one of the --remap-link-prefix options even though its canonicalized version didn't. For example, consider the NixOS "FHS environment", a bwrap-based container that has been populated with symlinks of the form /lib/libGL.so.1 -> /nix/store/something. Depending on the precise behaviour of libc and libdl (the exact trigger for the differing behaviour is unknown), when we open that library, we might find that the `needed_path_in_provider` is either /lib/libGL.so.1 or a path below /nix/store. If the `needed_path_in_provider` is /lib/libGL.so.1, we would canonicalize it to /nix/store/something, then decide that /nix/store/something didn't match any of the remapping rules such as `/lib*` → `/run/host/lib*`, and go back to using /lib/libGL.so.1 as the symlink target. But, inside pressure-vessel's container, `/lib` is from the container runtime and not the provider - which is precisely why we need to rewrite /lib paths to /run/host/lib in order to be able to find the library we want. Instead, we must limit the situation where we keep the `needed_path_in_provider` as-is to the situation where there is no symlink target rewriting: no --link-target, and no --remap-link-prefix. In this situation, we are expecting the meaning of a symlink in the container environment to be identical to the meaning of a symlink in the environment from which we are running capsule-capture-libs, therefore it's slightly preferable to use a non-canonicalized symlink if we have one: that way, if the target of a symlink changes during the container's lifetime (perhaps as a result of an OS upgrade), it will still work. Conversely, if we are using either --link-target or --remap-link-prefix, we want to stick to using only the canonicalized paths of libraries, because that's the only way we can avoid a symlink being interpreted differently outside and inside the container, for example as a result of its parent directory being mounted in a different place, or as a result of something different being mounted at its target. This means that we have to relax one of our test assertions slightly. Helps: https://github.com/ValveSoftware/steam-runtime/issues/684 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In older Steam releases this was distributed broken up into pieces (`steam-runtime.tar.xz.part*`), but since beta 1705630720 (2024-01-19) and GA 1714854927 (2024-05-04) it's a single large file. Adjust our fallback code path to take this into account. steamrt/tasks#490 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This would have made it considerably easier to spot that commit 8f65507d "logger: Recreate output log files if they get deleted" was reopening the log file more often than it should have been. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Otherwise, after reopening a deleted or replaced file, we would reopen it once per line, because its inode number constantly differs from the original inode number. After commit 1f502cb4 "logger: Fix always re-opening files when --log-fd is used", this was the only remaining place where we assign to self->file_fd without also assigning to self->file_stat. Fixes: 8f65507d "logger: Recreate output log files if they get deleted" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a test that already emits a warning message, prepending "quiet:" to the pattern should de-escalate the warning to a debug message. In a test that emits a fatal error, prepending "quiet:" to the pattern has no effect: it's still an error. steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Sometimes we find ourselves capturing a library for which the dependencies can legitimately be missing, for example `libnvidia-pkcs11.so.*` on Ubuntu 24.04 (which depends on OpenSSL 1.1, which Ubuntu no longer provides). This is really an OS bug (providing a library without its dependencies), and ideally Ubuntu should stop providing `libnvidia-pkcs11.so.*` (like Debian did), but it results in confusing messages that could make a user wrongly believe that it's the root cause of a genuine problem. steamrt/tasks#488 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 05, 2024
-
-
Ryan Gonzalez authored
I wasn't aware that simple assignment worked here. steamrt/tasks#487 Signed-off-by:
Ryan Gonzalez <ryan.gonzalez@collabora.com>
-
Ryan Gonzalez authored
`self->file_stat` was only initialized if an fd was *not* given, which would lead it to always re-create the log file once. steamrt/tasks#487 Signed-off-by:
Ryan Gonzalez <ryan.gonzalez@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
logger: Recreate output log files if they get deleted See merge request !740
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously we said "warning:" for about half the warnings, and didn't annotate fatal errors at all. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Repeat the test-case where we produced an error message about a library having the wrong ABI, but this time, use --level-prefix and assert that we add the <3> prefix for a fatal error. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will allow the output of capsule-capture-libs (and in principle other tools) to be piped to a log handler such as `logger --prio-prefix`, `systemd-cat --level-prefix=true` or `srt-logger --parse-level-prefix` which will filter or format the messages according to their severity. As currently implemented, fatal errors are emitted as LOG_ERR, warnings are LOG_WARNING, and all debug messages are LOG_DEBUG. A facility such as LOG_USER is not included: this is optional for logger(1), and not allowed for systemd-cat(1) and srt-logger. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a couple of places this requires explicitly emitting the stringified value of errno, because we have equivalents of warnx() and errx(), but not warn() and err(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These mimic the behaviour of errx() and warnx(), but will benefit from future enhancements to capsule_log(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows them to be distinguished from messages logged by some other executable invoked around the same time, and makes `capsule_log( LOG_WARNING, ... )` a drop-in substitute for `warnx()`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us change the behaviour of all diagnostic messages at once, by changing only capsule_logv(). For now, the syslog-style severity is accepted but ignored. Subsequent commits will make use of this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We don't enforce a specific error message, but we do assert that there's no output on stdout, and an error message prefixed with the program name on one of the lines of stderr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-