- Feb 26, 2021
-
-
Simon McVittie authored
This is experimental and subject to change. It requires branches of Flatpak that have not yet been reviewed or merged, so it's guarded by (deliberately undocumented) environment variables by default. Only enable this if you are a pressure-vessel developer and know precisely what you're doing. This feature also requires a non-setuid bwrap executable, and a kernel that allows the non-setuid bwrap to create new user namespaces. Fedora, Ubuntu, Debian >= 11, and Arch Linux's default kernel are examples of systems that should be OK; Debian <= 10, SteamOS 2, and Arch Linux's linux-hardened are not. I'm landing this despite its experimental status because leaving it in a branch means we have to rebase it all the time, which just slows us down. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the FlatpakExports has set these up to be symlinks, it's harmless to use --dir redundantly; but if we do these too soon, the FlatpakExports would be unable to create its symlinks and would fail. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/368 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These indicate which lines are harmless and which lines are really bad, without taking up too much space. The mapping from GLib log level to message is not 100% obvious, because G_LOG_LEVEL_ERROR is "worse than" an error. We diagnose "can't happen" situations (assertion failures, etc.) as "Internal error". Ideally, users should never see these: they indicate a bug. For situations that will cause pressure-vessel to exit with an error, introduce a new log level flag PV_LOG_LEVEL_FAILURE and map it to the apt-style "E:" prefix. pv_log_failure() is a convenience macro to log at level PV_LOG_LEVEL_FAILURE. Conceptually this is a fatal error, but it's a fatal error prompted by something external to pressure-vessel, for which we want pressure-vessel to clean up "nicely" and exit gracefully, even though it's going to fail - so we can't use g_error() for this. In the parts of main() that involve parsing command-line arguments, add usage_error() as syntactic sugar for pv_log_failure(). I might eventually turn these into G_OPTION_ERROR_FAILED as we factor out more of main() into helper functions, but for now they're handled separately. For less-severe log levels, use single-letter prefixes similar to apt's. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 25, 2021
-
-
Simon McVittie authored
wrap.c is generally too big, and so is main() specifically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
wrap.c is generally too big, and so is main() specifically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The Flathub Steam app loads a LD_AUDIT module to ignore bundled libraries in games where they cause problems. We want to treat that essentially the same as LD_PRELOAD, at least until we take on its functionality. While we're changing this, also change the misleading name of the option. It was called --host-ld-preload, but it actually took the LD_PRELOAD module from the current execution environment, not the host. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
If needed, try to run `nvidia-modprobe` to load the necessary `nvidia_uvm.ko` kernel module. Fixes: #59 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 24, 2021
-
-
Simon McVittie authored
If we don't have at least the equivalent of `flatpak run --filesystem=host-os` then we are not going to get very far. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
For historical reasons, we assume that /run/host is a relatively complete view of the host system, like it would be inside Flatpak. However, in a systemd-nspawn container, /run/host contains other things but not usually /usr or /etc. Previously, the default was exactly equivalent to the old PRESSURE_VESSEL_HOST_GRAPHICS=1, which in turn is equivalent to either PRESSURE_VESSEL_GRAPHICS_PROVIDER=/run/host (if we appear to be in a container) or PRESSURE_VESSEL_GRAPHICS_PROVIDER=/ (if not). Now, the default is basically PRESSURE_VESSEL_GRAPHICS_PROVIDER=/, to maximize the chance that if Steam games can run in the older LD_LIBRARY_PATH-based Steam Runtime, they'll also run in our containers. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/367 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 23, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is opt-in: the idea is that the shell scripts will enable this option when they switch from doing deployment themselves to letting the C code do it. The soldier and scout names are hard-coded, because those are the only legacy runtimes that have ever had public releases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 22, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, this was done by the deploy-runtime script in SteamLinuxRuntime. Moving it into C code gives us better error handling and more reliable locking. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv_runtime_init_variable_dir() creates it if it doesn't already exist, so we don't need to check that it already exists, which in turn means we don't need to pre-create it in main(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
At the moment the only use for the variable directory is for --copy-runtime-into, but in future we will also use it to unpack temporary runtime archives. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 27, 2021
-
-
Simon McVittie authored
We share /tmp with the host, and it seems odd to share /tmp but put /var/tmp on our private tmpfs, particularly when /var/tmp is traditionally longer-lived and more spacious than /tmp (for example, /tmp on a small tmpfs and /var/tmp on a large disk is common). In the unusual case where we are using a fake $HOME, we mount its ~/.cache/tmp on our container's /var/tmp, consistent with Flatpak. That doesn't change here, and it's still persistent unless explicitly deleted. Prompted by <https://github.com/ValveSoftware/steam-runtime/issues/313#issuecomment-766526963 > Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There are three user-space Vulkan driver stacks for recent AMD GPUs: - Mesa RADV, open-source drivers from the Mesa community - AMDVLK, open-source drivers from AMD - AMDGPU-PRO, proprietary drivers from AMD (presumably based on AMDVLK) At least one of the two AMD-maintained drivers requires files that are installed in /etc/amd. Partially addresses <https://github.com/ValveSoftware/steam-runtime/issues/313 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 18, 2021
-
-
Ludovico de Nittis authored
If we parse the "env-if-host" options as "G_OPTION_ARG_STRING_ARRAY", Glib assumes them to be encoded with the current locale. This can be an issue when pressure-vessel needs to run the main game, because Steam will set "LC_ALL=C", but the "env-if-host" might still contain characters that are not ASCII. To solve this we use "G_OPTION_ARG_FILENAME_ARRAY" that treats the options as opaque byte-blobs. Fixes: #52 Fixes: steam-runtime#349 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 12, 2021
-
-
Simon McVittie authored
This is a container-manager-agnostic version of probing /.flatpak-info and /run/pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 11, 2021
-
-
Ludovico de Nittis authored
If we don't use `--setenv` directly, the process that we create with "pv_bwrap_execve()" could throw some errors because it is unable to preload the libraries that we specified, because they are valid only in the container structure. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 08, 2021
-
-
Simon McVittie authored
This will reduce the diff in later commits that actually change logic, hopefully making them easier to review. Best reviewed with `git diff --ignore-space-change` or similar. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of this pseudocode: bwrap += argv_in_container final_argv += bwrap if we do this: final_argv += bwrap final_argv += argv_in_container it will be easier to adapt to Flatpak sub-sandboxing, in which we never directly build up a bwrap command-line and so bwrap remains NULL. This means that in the case where we are escaping from a Flatpak sandbox to run commands on the host, we have to forward the fds from argv_in_container in addition to the fds from bwrap. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This refactoring will be helpful when running in Flatpak. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We always need a mutable copy of the runtime when running in Flatpak, because we are unable to run bwrap to do container setup. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we are not using the --launcher, then there's no point in setting this up: they won't be used for anything anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 05, 2021
-
-
Ludovico de Nittis authored
Now that we have the ability to set the log level to "info", this commit promotes, from the debug level, all the messages that can be useful to have, for debugging purposes, but that are not too lousy. Over time, when we also gain more first hand experience with the issue reports that users provide, we can tweak the log messages even more. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This serves two purposes: it gives us a timestamp for when pressure-vessel started, and it puts the version number in the log. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This keeps track of environment variables' values and their locked status in one place. We build it up over time, and then serialize it into final_argv->envp. In particular, this is a step towards no longer storing anything in the variable named bwrap except for bubblewrap options, which will be a necessary piece of refactoring when we move to launching the game as a Flatpak sub-sandbox, without ever invoking bubblewrap ourselves. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's easier to be sure that we are not using this variable outside the expected range of lines if it's only declared within those lines. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The environment variables we have built up in `bwrap` are appropriate for the container itself, but inappropriate for the environment in which we run pressure-vessel-launch to ask Flatpak on the host to run bwrap. Keep them more carefully separate. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we're going to run the -launcher, then argv[1...] are the arguments for -launcher, not an argv array in their own right. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes the boundary between things inside the container and things outside the container clearer, which will be valuable when we stop always invoking bwrap directly ourselves. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We previously parsed this to decide whether we could use --unshare-uts, but we stopped doing that more than a year ago, in commit 210fbd8c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are more similar than they are different. In a subsequent commit we'll change how this works, and re-indenting it here will make that more reviewable. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're using FlatpakBwrap as a convenient way to collect up a set of argv, envp and inherited file descriptors, but it isn't actually a bwrap command in all cases. Use a less misleading name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The reason we originally did this is that older versions of bwrap didn't support the GNU-style "--" argument separator, used to disambiguate between non-option arguments and strangely-named executables that happened to start with a minus. However, we now wrap our user-controlled "payload" command with pressure-vessel-adverb(1) in all cases, which means we don't need this. bwrap's first non-option argument is the absolute path to pressure-vessel-adverb, which definitely does not start with "-" and so cannot be confused with an option; and all of our own commands, notably pressure-vessel-adverb, use GOptionContext and therefore support the "--" option-separator correctly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Only use the name wrapped_command when it is genuinely a command that we are wrapping. Use a new temporary FlatpakBwrap structure, launcher_argv, for the case where it just contains arguments for the launcher. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-