NVIDIA-CTK-INSTALLER(1)

πŸ“¦ version 1.19.1, in ubuntu stonking

🌸 NAME 🌸

okay so bestie, meet nvidia-ctk-installer ✨ β€” yeah it's literally the same name twice, she's got main character energy like that. This page lives in section 1 of the manual, the User Commands shelf, which is where all the executable girlies hang out. 🫢


πŸ’– DESCRIPTION πŸ’–

πŸŽ€ NAME πŸŽ€

nvidia-ctk-installer β€” installs the NVIDIA Container Toolkit and configures the runtime you picked so it actually knows about the nvidia runtime. no cap, that's the whole job.

πŸš€ USAGE πŸš€

nvidia-ctk-installer [global options]

⭐ VERSION ⭐

1.19.1 β€” that's the one, periodt.

πŸ‘‘ GLOBAL OPTIONS πŸ‘‘

okay here comes the big list, hydrate first πŸ’… β€” every single flag, exactly as written:

  • --no-daemon, -n β€” dips out immediately after the runtime is set up. and like, no cleanup will be performed, so don't come crying to me later 😭 [$NO_DAEMON]
  • --no-runtime-config β€” turns OFF configuring a container runtime. use this when the runtime is already configured for the toolkit and you're only here to deploy the NVIDIA Container Toolkit components. [$NO_RUNTIME_CONFIG]
  • --enable-nri-plugin, -p β€” if it's true, the toolkit stands up an NRI Plugin server that injects CDI devices into containers 🌈 careful though: this one gets ignored if --no-daemon is set. [$ENABLE_NRI_PLUGIN]
  • --nri-plugin-index uint β€” pick the plugin index to register to NRI (default: 10) [$NRI_PLUGIN_INDEX]
  • --nri-socket string β€” the path to the NRI socket file where the NRI plugin server gets registered (default: "/var/run/nri/nri.sock") [$NRI_SOCKET]
  • --nri-namespace string β€” the kubernetes namespace the toolkit's NRI plugin is running in [$NRI_NAMESPACE]
  • --runtime string, -r string β€” which runtime to set up on this node. one of {'docker', 'crio', 'containerd'}. this setting is ignored if --no-runtime-config is specified. (default: "docker") [$RUNTIME]
  • --toolkit-install-dir ROOT, --root ROOT β€” where the NVIDIA Container Toolkit gets installed. the toolkit components go to ROOT/toolkit. heads up: if you're in a containerized installer, this is the path in the container, and it's recommended it match the path on the host. (default: "/usr/local/nvidia") [$TOOLKIT_INSTALL_DIR, $ROOT]
  • --toolkit-source-root string β€” the folder where the required toolkit artifacts live. if you don't say, the path /artifacts/{{ .ToolkitPackageType }} is used, where ToolkitPackageType is the resolved package type [$TOOLKIT_SOURCE_ROOT]
  • --toolkit-package-type string β€” the package type for the toolkit. one of ['deb', 'rpm', 'auto', '']. if 'auto' or '' is used, the type gets inferred automatically. (default: "auto") [$TOOLKIT_PACKAGE_TYPE]
  • --pid-file string β€” path to a toolkit.pid file, so only one configuration instance runs at a time, no chaos allowed πŸ’€ (default: "/run/nvidia/toolkit/toolkit.pid") [$TOOLKIT_PID_FILE, $PID_FILE]
  • --debug β€” turns on debug-level logs in the toolkit installer πŸ› [$TOOLKIT_DEBUG]
  • --driver-root string, --nvidia-driver-root string β€” (default: "/run/nvidia/driver") [$NVIDIA_DRIVER_ROOT, $DRIVER_ROOT]
  • --driver-root-ctr-path string β€” (default: "/run/nvidia/driver") [$DRIVER_ROOT_CTR_PATH]
  • --dev-root /dev β€” where /dev is located. if you don't specify, the driver-root is assumed. [$NVIDIA_DEV_ROOT, $DEV_ROOT]
  • --dev-root-ctr-path /dev β€” where /dev is located in the container. if you don't specify, the driver-root-ctr-path is assumed. [$DEV_ROOT_CTR_PATH]
  • --nvidia-container-runtime.debug string, --nvidia-container-runtime-debug string β€” where the debug log file for the NVIDIA Container Runtime goes [$NVIDIA_CONTAINER_RUNTIME_DEBUG]
  • --nvidia-container-runtime.log-level string, --nvidia-container-runtime-debug-log-level string β€” (the manual just gives us the env var here, iykyk) [$NVIDIA_CONTAINER_RUNTIME_LOG_LEVEL]
  • --nvidia-container-runtime.mode string, --nvidia-container-runtime-mode string β€” [$NVIDIA_CONTAINER_RUNTIME_MODE]
  • --nvidia-container-runtime.modes.cdi.default-kind string β€” [$NVIDIA_CONTAINER_RUNTIME_MODES_CDI_DEFAULT_KIND]
  • --nvidia-container-runtime.modes.cdi.annotation-prefixes string [ --nvidia-container-runtime.modes.cdi.annotation-prefixes string ] β€” [$NVIDIA_CONTAINER_RUNTIME_MODES_CDI_ANNOTATION_PREFIXES]
  • --nvidia-container-runtime.runtimes string [ --nvidia-container-runtime.runtimes string ] β€” [$NVIDIA_CONTAINER_RUNTIME_RUNTIMES]
  • --nvidia-container-runtime-hook.skip-mode-detection β€” [$NVIDIA_CONTAINER_RUNTIME_HOOK_SKIP_MODE_DETECTION]
  • --nvidia-container-cli.debug string, --nvidia-container-cli-debug string β€” where the debug log file for the NVIDIA Container CLI goes [$NVIDIA_CONTAINER_CLI_DEBUG]
  • --accept-nvidia-visible-devices-envvar-when-unprivileged β€” sets the accept-nvidia-visible-devices-envvar-when-unprivileged config option [$ACCEPT_NVIDIA_VISIBLE_DEVICES_ENVVAR_WHEN_UNPRIVILEGED]
  • --accept-nvidia-visible-devices-as-volume-mounts β€” sets the accept-nvidia-visible-devices-as-volume-mounts config option [$ACCEPT_NVIDIA_VISIBLE_DEVICES_AS_VOLUME_MOUNTS]
  • --cdi-enabled, --enable-cdi β€” enables generating a CDI specification ✨ [$CDI_ENABLED, $ENABLE_CDI]
  • --cdi-output-dir string β€” where the CDI output files get written. if you set it to '', no CDI specification is generated. (default: "/var/run/cdi") [$CDI_OUTPUT_DIR]
  • --cdi-kind string β€” the vendor string used for the generated CDI specification (default: "management.nvidia.com/gpu") [$CDI_KIND]
  • --create-device-nodes string [ --create-device-nodes string ] β€” (only applicable with --cdi-enabled) says which device nodes should be created. if any one of the options is set to '' or 'none', no device nodes will be created. (default: "control") [$CREATE_DEVICE_NODES]
  • --config string β€” path to the runtime config file (default: "RUNTIME_SPECIFIC_DEFAULT") [$RUNTIME_CONFIG, $CONTAINERD_CONFIG, $DOCKER_CONFIG]
  • --drop-in-config string β€” path to the NVIDIA-specific drop-in config file (default: "RUNTIME_SPECIFIC_DEFAULT") [$RUNTIME_DROP_IN_CONFIG]
  • --drop-in-config-host-path string β€” when running in a container, this is the path to the drop-in config (--drop-in-config) on the host. it's required to correctly update the top-level config if needed, since the paths there must be host-relative. [$RUNTIME_DROP_IN_CONFIG_HOST_PATH]
  • --executable-path string β€” the path to the runtime executable. this is used to extract the current config [$RUNTIME_EXECUTABLE_PATH]
  • --socket string β€” path to the runtime socket file (default: "RUNTIME_SPECIFIC_DEFAULT") [$RUNTIME_SOCKET, $CONTAINERD_SOCKET, $DOCKER_SOCKET]
  • --restart-mode string β€” how the runtime should be restarted; pick 'none' and it just won't be restarted. [signal | systemd | none ] (default: "RUNTIME_SPECIFIC_DEFAULT") [$RUNTIME_RESTART_MODE]
  • --enable-cdi-in-runtime β€” enable CDI in the configured runtime πŸ’œ [$RUNTIME_ENABLE_CDI]
  • --host-root string β€” the path to the host root used when restarting the runtime with systemd (default: "/host") [$HOST_ROOT_MOUNT]
  • --runtime-name nvidia, --nvidia-runtime-name nvidia, --runtime-class nvidia β€” the name of the nvidia runtime. if set-as-default is selected, the runtime is used as the default runtime. (default: "nvidia") [$NVIDIA_RUNTIME_NAME, $CONTAINERD_RUNTIME_CLASS, $DOCKER_RUNTIME_NAME]
  • --config-source file, --config-sources file [ --config-source file, --config-sources file ] β€” the config sources for the container runtime. any combination of [command | file]. when file is specified, the absolute path to the file to be used as a config source can be specified as file=/path/to/source/config.toml (default: "command", "file") [$RUNTIME_CONFIG_SOURCES, $RUNTIME_CONFIG_SOURCE]
  • --use-legacy-config β€” whether a legacy (pre v1.3) config should be used. this makes a version 1 container config get created by default, and makes the containerd.runtimes.default_runtime config section define the default runtime instead of container.default_runtime_name. [$CONTAINERD_USE_LEGACY_CONFIG]
  • --runtime-type string β€” the runtime_type to use for the configured runtime classes (default: "io.containerd.runc.v2") [$CONTAINERD_RUNTIME_TYPE]
  • --nvidia-container-runtime-modes.cdi.annotation-prefixes string [ --nvidia-container-runtime-modes.cdi.annotation-prefixes string ] β€” [$NVIDIA_CONTAINER_RUNTIME_MODES_CDI_ANNOTATION_PREFIXES]
  • --runtime-config-override string β€” extra runtime options as a JSON string. the paths are relative to the runtime config. (default: "{}") [$RUNTIME_CONFIG_OVERRIDE, $CONTAINERD_RUNTIME_CONFIG_OVERRIDE]
  • --hooks-dir string β€” path to the cri-o hooks directory (default: /usr/share/containers/oci/hooks.d) [$CRIO_HOOKS_DIR]
  • --hook-filename string β€” filename of the cri-o hook that gets created / removed in the hooks directory (default: oci-nvidia-hook.json) [$CRIO_HOOK_FILENAME]
  • --config-mode string β€” the configuration mode to use. one of [hook | config] (default: "config") [$CRIO_CONFIG_MODE]
  • --help, -h β€” show help πŸ†˜
  • --version, -v β€” print the version πŸ”–

πŸ’œ SEE ALSO πŸ’œ

the full documentation for nvidia-ctk-installer is maintained as a Texinfo manual πŸ“š and bestie, if the info and nvidia-ctk-installer programs are properly installed at your site, this command

info nvidia-ctk-installer

should give you access to the complete manual. so if you want the deep lore, that's the door πŸ¦‹


k that's the whole page, love you, bye β€” this was nvidia-ctk-installer 1.19.1, dated June 2026, and the page itself answers to the name NVIDIA-CTK-INSTALLER(1) βœ¨πŸ’–πŸ«Ά

πŸ“¦ where this page comes from