eb73692618
NVIDIA Container Toolkit 1.17.5 requires Go >= 1.22 [1], and starts
using enable-cuda-compat hooks in the Container Device Interface
specification generated by it [2]. For example:
"hookName": "createContainer",
"path": "/usr/bin/nvidia-cdi-hook",
"args": [
"nvidia-cdi-hook",
"enable-cuda-compat",
"--host-driver-version=570.153.02"
]
The new hook makes it possible to have containers with a
/usr/local/cuda/compat/libcuda.so.* that's newer than the proprietary
NVIDIA driver on the host operating system, so that applications can use
a newer CUDA without having to update the driver [3]. Even though this
sounds useful, the hook has been disabled until it's handled by the
'init-container' command and there's a clear way to test it.
The src/go.sum file was updated with 'go mod tidy'.
[1] NVIDIA Container Toolkit commit 5bdf14b1e7c24763
https://github.com/NVIDIA/nvidia-container-toolkit/commit/5bdf14b1e7c24763
https://github.com/NVIDIA/nvidia-container-toolkit/pull/941
https://github.com/NVIDIA/nvidia-container-toolkit/pull/950
[2] NVIDIA Container Toolkit commit 76040ff2ad63fb82
https://github.com/NVIDIA/nvidia-container-toolkit/commit/76040ff2ad63fb82
https://github.com/NVIDIA/nvidia-container-toolkit/pull/906
https://github.com/NVIDIA/nvidia-container-toolkit/pull/948
[3] https://docs.nvidia.com/deploy/cuda-compatibility/
https://github.com/containers/toolbox/pull/1662
|
||
|---|---|---|
| .github | ||
| data | ||
| doc | ||
| images | ||
| playbooks | ||
| profile.d | ||
| src | ||
| test | ||
| .codespellexcludefile | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| .zuul.yaml | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| GOALS.md | ||
| NEWS | ||
| NEWS.old | ||
| README.md | ||
| SECURITY.md | ||
| gen-docs-list | ||
| meson.build | ||
| meson_options.txt | ||
| meson_post_install.py | ||
| toolbox | ||
README.md
Toolbx is a tool for Linux, which allows the use of interactive command line environments for software development and troubleshooting the host operating system, without having to install software on the host. It is built on top of Podman and other standard container technologies from OCI.
Toolbx environments have seamless access to the user's home directory, the Wayland and X11 sockets, networking (including Avahi), removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc..
This is particularly useful on OSTree based operating systems like Fedora CoreOS and Silverblue. The intention of these systems is to discourage installation of software on the host, and instead install software as (or in) containers — they mostly don't even have package managers like DNF or YUM. This makes it difficult to set up a development environment or troubleshoot the operating system in the usual way.
Toolbx solves this problem by providing a fully mutable container within
which one can install their favourite development and troubleshooting tools,
editors and SDKs. For example, it's possible to do yum install ansible
without affecting the base operating system.
However, this tool doesn't require using an OSTree based system. It works equally well on Fedora Workstation and Server, and that's a useful way to incrementally adopt containerization.
The Toolbx environment is based on an OCI
image. On Fedora this is the fedora-toolbox image. This image is used to
create a Toolbx container that offers the interactive command line
environment.
Note that Toolbx makes no promise about security beyond what's already available in the usual command line environment on the host that everybody is familiar with.
Installation & Use
See our guides on installing & getting started with Toolbx and Linux distro support.
