NVIDIA GPU Driver and CUDA on Linux: Archived Runfile Workflow and Version Checks

This archived workflow mixes CentOS 7, older SUSE/Ubuntu procedures, driver 390.46 and CUDA 9.x/10.x/11.0 examples. It is not one validated installation combination or a current support matrix. Select a supported GPU/OS/kernel/compiler/driver/toolkit/application combination from NVIDIA’s matching release documentation before changing a host. Do not mix package-manager and runfile installations without the documented migration/uninstall procedure.

1. Preparation

1.1 Identify the GPU and operating system

Record the actual GPU model and OS release/architecture. Use NVIDIA’s English driver site and CUDA downloads to obtain verified packages for that combination. The source’s Linux 64-bit choice is an archived x86_64 example, not a selection suitable for every Linux architecture:

1.2 Check application, driver and toolkit compatibility

The source suggests a newer toolkit/driver for applications built with older CUDA, mentioning 10.1/10.2 with a 10.2-era driver and 11.0 with an 11.0-era driver. These are historical compatibility examples, not a rule to install the newest toolkit. Application framework requirements, supported GPU generation, minimum driver and OS/kernel/compiler support must all match. NVIDIA’s archived matrix lists Linux minimums 418.39 for CUDA 10.1 and 440.33 for CUDA 10.2. CUDA 11.0 GA uses 450.51.05 or newer; later 11.0 updates differ. The source’s 390.46 driver command belongs to a CUDA 9.1-era example and does not satisfy those 10.x/11.0 requirements.

The native English download screenshot selects Linux,x86_64,CentOS 7 and a local runfile. It is an example, not an instruction to reuse that obsolete package for another OS:

1.3 Verify GPU enumeration

lspci | grep -i nvidia

Confirm all expected GPUs are visible. This output can include NVIDIA bridges as well as GPUs; do not count every matching line as a GPU. The source recommends reseating/cross-testing hardware when detection is incomplete, using the server’s supported powered-down service procedure:

1.4 Remove conflicting prior installations through their matching method

For a prior runfile installation, the source names these uninstallers; substitute the actual installed CUDA version:

/usr/bin/nvidia-uninstall
/usr/local/cuda-X.Y/bin/cuda-uninstaller
# Alternative for applicable older CUDA releases:
/usr/local/cuda-X.Y/bin/uninstall_cuda_X.Y.pl

These are alternative release-specific paths. A package-managed installation must be removed through its supported package procedure, not blindly with a runfile uninstaller. Check the selected components before accepting removal:

1.5 Provide supported compilers and build tools

The runfile kernel-module build needs a compatible compiler. Building C++ samples requires the appropriate C++ compiler and make; merely unpacking toolkit binaries is different from compiling samples. Check versions:

gcc -v
g++ -v

Source CentOS7 package examples:

yum install gcc
yum install gcc-c++

Source SUSE examples:

zypper in gcc
zypper in gcc-c++

Source Ubuntu examples, correcting its gpt-get typo to apt-get:

apt-get install gcc
apt-get install g++
apt-get install make
dpkg -l gcc
dpkg -l g++
dpkg -l make

Do not assume the newest available compiler is compatible with an old CUDA release. No package installation was performed here.

1.6 Match the running kernel’s development files

For the source’s RHEL/CentOS7 branch:

uname -r
yum install kernel-devel-$(uname -r) kernel-headers-$(uname -r)

For Ubuntu, the source incorrectly suggests kernel headers can simply be omitted. When building the driver kernel module, install the matching development files through the supported repository; NVIDIA’s archived Ubuntu example is:

apt-get install linux-headers-$(uname -r)

The source lists zypper install kernel-source-$(uname -r) and zypper install kernel-default-devel-$(uname -r), and calls the first alone sufficient. Those name strings are not a universal SUSE package specification. Determine the running version and flavor; NVIDIA’s archived form is zypper install kernel-<variant>-devel=<version>, where the angle-bracket values must be replaced. Resolve additional required source/development packages for the actual release. Its photo shows an older 3.0.76 kernel family, not proof that every listed package version matches the running kernel:

1.7 Disable Nouveau for the applicable proprietary runfile-driver workflow

lsmod | grep nouveau

The source creates /usr/lib/modprobe.d/blacklist-nouveau.conf for its CentOS7 example with the following contents. Other releases can use /etc/modprobe.d; follow their supported path:

blacklist nouveau
options nouveau modeset=0

It then rebuilds initramfs. Correct the source’s single-dash dracut -force to:

dracut --force

For its Ubuntu branch, add the same two lines to the applicable /etc/modprobe.d configuration(the source uses /etc/modprobe.d/blacklist.conf), then run:

update-initramfs -u

Rebuilding the image does not unload the current Nouveau module. Reboot through the planned maintenance workflow and verify its state again. The source’s empty grep result means no matching loaded module was printed, not that driver installation has already succeeded:

1.8 Enter the appropriate text-mode maintenance session

For this archived runfile-driver method, stop graphical clients and use the supported text-mode procedure. The source’s CentOS7 command changes the persistent default target:

systemctl set-default multi-user.target

Its Ubuntu branch stops LightDM if that is the actual display manager and optionally changes the default target:

systemctl stop lightdm
systemctl set-default multi-user.target

The source also names Ctrl+Alt+F1, F7 for its graphical session, and init 3. Console-key assignments and runlevels differ; these are not universal current Ubuntu commands. Its old SysV SUSE branch edits /etc/inittab from id:5:initdefault: to id:3:initdefault:, which is not the configuration method for a systemd SUSE release. Record the original configuration, reboot as needed for Nouveau changes and verify the actual text session before installation. No display manager or default target was changed here.

2. Install the matching GPU driver

The source’s historical administrator-run example is shown with ASCII double-hyphen options restored. It is for the named 390.46 package only; choose the verified driver required by the actual GPU/application/toolkit instead of copying this old filename:

chmod +x NVIDIA-xxx.run
./NVIDIA-Linux-x86_64-390.46.run --no-opengl-files --ui=none --no-questions --accept-license

The xxx filename is a placeholder and must correspond to the actual file. The options request noninteractive operation, OpenGL omission and license acceptance. Review the applicable installer’s help/license and whether OpenGL is needed; those are not universal installation defaults.

2.1 Persistence mode and startup examples

nvidia-smi -pm 1
nvidia-smi

The source calls this memory-resident mode. It actually controls persistence of driver/GPU initialization state across clients; it does not reserve application GPU memory. Verify the setting and GPU visibility in nvidia-smi. NVIDIA also documents the distribution-integrated persistence daemon for supported drivers.

For its historical rc.local branch, add the persistence command to the existing startup script and make the actual script executable:

# /etc/rc.d/rc.local, where used:
nvidia-smi -pm 1
# Set the existing script executable:
chmod +x /etc/rc.d/rc.local

If the release uses /etc/rc.local instead, the source uses that file and chmod +x /etc/rc.local. The file must be integrated with the real init system; creating a file alone does not guarantee it runs.

The source gives this third-party Ubuntu 18.04 compatibility-unit example as /etc/systemd/system/rc-local.service:

[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

Its /etc/rc.local content and activation commands are:

#!/bin/sh -e
nvidia-smi -pm 1
exit 0

chmod +x /etc/rc.local
systemctl enable rc-local.service
systemctl start rc-local.service
systemctl status rc-local.service

These are retained as a legacy source template, not a verified unit for current systems. The Type=forking assumption, obsolete SysVStartPriority directive, daemon ordering and driver readiness require review; use the supported packaged service where available. The source calls for a reboot and verification after startup, which is not demonstrated here.

For an older SUSE release that actually executes /etc/init.d/after.local, the source creates/edits that file to contain the same persistence command, then makes it executable:

# /etc/init.d/after.local:
nvidia-smi -pm 1
# Existing startup script permissions:
chmod +x /etc/init.d/after.local

Confirm the release’s startup integration; this old path is not a guarantee on systemd releases.

3. Install the CUDA toolkit

If a compatible GPU driver is already installed, the source leaves Driver unchecked in the toolkit installer. Do not replace it accidentally with an older bundled driver. The 10.1 screenshot specifically shows driver 418.67 unchecked and toolkit/samples/demo/documentation selected:

The source runfile example is:

chmod +x cuda-xxx.run
./cuda-xxx.run --no-opengl-libs

Again, xxx is a filename placeholder. The OpenGL flag is a historical installer option; check the selected release rather than forcing it onto an installer that does not accept it.

The old interactive transcript below is preserved as an illustration, with its Chinese comments translated after the block. It mixes 9.2 prompts with a 9.1 default directory and must not be treated as one internally consistent successful install:

Do you accept the previously read EULA?
accept/decline/quit: accept
Install NVIDIA Accelerated Graphics Driver for Linux-x86_64 387.26?
(y)es/(n)o/(q)uit: n
Install the CUDA 9.2 Toolkit?
(y)es/(n)o/(q)uit: y
Enter Toolkit Location
[ default is /usr/local/cuda-9.1 ]:
Do you want to install a symbolic link at /usr/local/cuda?
(y)es/(n)o/(q)uit: y
Install the CUDA 9.2 Samples?
(y)es/(n)o/(q)uit: y
To uninstall the CUDA Toolkit, run the uninstall script in /usr/local/cuda-9.2/bin
To uninstall the NVIDIA Driver, run nvidia-uninstall
Please see CUDA_Installation_Guide_Linux.pdf in /usr/local/cuda-9.2/doc/pdf for detailed information on setting up CUDA.
Logfile is /tmp/cuda_install_62403.log

The source comments say to review/accept the license when authorized, decline the bundled driver when it is already installed, accept the intended toolkit, confirm its actual installation directory, and install the requested link/samples. Its transcript leaves the displayed default-location prompt blank, but the 9.1/9.2 mismatch needs resolution before accepting a real target. Inspect the actual installer log when installation fails; the example log filename is not universal.

3.1 Set the actual toolkit environment and verify

The source adds these exports to /etc/profile for system-wide shell setup, then reloads it. Use the actual toolkit path/link and intended shell scope:

export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
source /etc/profile
nvcc -V

Verify that nvcc resolves to the intended toolkit. Its version alone does not prove application/GPU runtime compatibility. Check the running driver and a supported workload as required by the matching release procedure. No package removal, driver installation, boot change, service start or reboot was performed here.

References

• https://www.nvidia.com/en-us/drivers/
• https://developer.nvidia.com/cuda-downloads
• https://docs.nvidia.com/cuda/archive/10.2/cuda-installation-guide-linux/
• https://docs.nvidia.com/cuda/archive/11.0/cuda-toolkit-release-notes/index.html
• https://docs.nvidia.com/cuda/archive/9.2/cuda-installation-guide-linux/index.html
• https://docs.nvidia.com/deploy/driver-persistence/persistence-daemon.html