Skip to main content

diagnose-driver-install

Diagnose NVIDIA driver installation failures on DeepOps-managed nodes — nvidia-smi errors, "No devices were found", DKMS build failures, or GPU pods crash-looping. Use before reinstalling anything.

소스 정보

저장소
NVIDIA/deepops
최근 소스 활동
2026년 7월 14일 15:16
감지된 SKILL.md 언어
영어
스타
1,482
포크
362

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
diagnose-driver-install
description
Diagnose NVIDIA driver installation failures on DeepOps-managed nodes — nvidia-smi errors, "No devices were found", DKMS build failures, or GPU pods crash-looping. Use before reinstalling anything.
# Diagnose an NVIDIA driver install Work through these in order; most "driver failures" are one of the first three and need no reinstall. ## 1. Are you being fooled by GPU hiding? On DeepOps **Slurm** nodes, GPUs are hidden from ordinary SSH sessions by design. Bare `nvidia-smi` over SSH reporting `No devices were found` on an otherwise healthy node is expected. ```bash srun --gpus=1 nvidia-smi # the authoritative test on Slurm nodes ``` If the srun job sees the GPU, the driver is fine. Stop here. ## 2. Is the hardware visible at all? ```bash lspci | grep -i nvidia ``` No output → not a driver problem. The GPU is absent, unseated, or bound by VFIO passthrough or platform firmware; escalate to hardware support before touching software. ## 3. Open vs proprietary kernel modules `nvidia-smi: No devices were found` immediately after a clean install is the classic symptom of the wrong module flavor for the GPU generation: - Turing and newer (T4, A100, H100, RTX PRO Blackwell): open kernel modules supported — DeepOps default `nvidia_driver_ubuntu_use_open_kernel_modules: true` is correct. - Pascal and older (P100, GTX 10xx): open modules are **not** supported — set `nvidia_driver_ubuntu_use_open_kernel_modules: false` in `config/group_vars/all.yml` and rerun the driver play. Check what is loaded: `modinfo nvidia | grep -i license` (open modules say MIT/GPL, proprietary says NVIDIA). ## 4. Did the kernel module actually build and load? ```bash dkms status # driver module state per kernel dmesg | grep -iE 'nvidia|nvrm' | tail -20 lsmod | grep nvidia ``` - DKMS shows an error for the running kernel → usually missing headers (`linux-headers-$(uname -r)`) or a kernel updated after the driver install. Install headers or reboot into the matching kernel, then rerun the driver play. - Module loaded but `nvidia-smi` fails → check `dmesg` for RmInitAdapter or fallen-off-the-bus errors; these are hardware/firmware territory. ## 5. Rerun the play, don't hand-fix After correcting configuration, converge with the playbook rather than manual package surgery, then validate: ```bash ansible-playbook -l <host> playbooks/nvidia-software/nvidia-driver.yml python3 scripts/validation/validate_slurm.py --json # or validate_k8s.py ``` Reruns are idempotent; a healthy converged rerun reports `changed=0`. ## Kubernetes-specific notes GPU Operator crash-looping driver pods: `kubectl logs -n <gpu-operator namespace> <driver-pod>` usually names the same root causes — missing headers, wrong module flavor, or a node reboot needed. Fix via the operator values or node state, not by installing drivers by hand on the host (the operator owns the driver on Kubernetes nodes unless DeepOps was configured for host drivers).
GitHub에서 보기