Ubuntu Pinning og NVIDIA Driver Management til AI-servere

Hvis du er ansvarlig for en AI-server, som andre mennesker er afhængige af, er den mest sandsynlige årsag til dit næste strømafbrydelse ikke en hardwarefejl, en modelfejl eller en strømafbrydelse. Det er en apt-get upgrade som du eller din distribution kørte i baggrunden, hvilket hentede en ny kerne, som NVIDIA DKMS-modulet ikke genopbyggede korrekt imod, og som efterlod nvidia-smi vender tilbage Failed to initialize NVML: Driver/library version mismatch ved næste genstart. Det er det mest almindelige supportopkald fra Kentino, efter at en server har kørt i to eller tre måneder.

Denne artikel handler om, hvordan man forhindrer det. Den dækker, hvilken Ubuntu LTS man skal vælge i midten af ​​2026, hvordan man installerer NVIDIA-driveren på en måde, man rent faktisk kan ræsonnere over, hvordan man fastlåser driveren og kernen, så en uovervåget opgradering ikke stille og roligt kan ødelægge din stak, og hvordan man gendanner, når nogen alligevel har gjort det.

Publikummet er den, der skal skrive sudo på en 4-GPU eller 8-GPU boks, der skal holde til at virke i årevis.

Hvorfor Ubuntu LTS overhovedet

Der findes teknisk velegnede Linux-distributioner, som ikke er Ubuntu — Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Ingen af ​​dem er forkerte, og et par af dem er uden tvivl bedre udviklet. Vi anbefaler stadig Ubuntu LTS til AI-servere af fire grunde, der ikke har noget at gøre med elegance.

NVIDIA tester først mod Ubuntu LTS. Deres apt depotskibe cuda-keyring pakker eksplicit til ubuntu2204, ubuntu2404og (siden foråret 2026) ubuntu2604Driverinstallationsvejledningen navngiver Ubuntu LTS efter versionsnummer; den navngiver andre distributioner bagerst i dokumentet.

Containerøkosystemet forudsætter Ubuntu. Hvert NGC-billede (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) er bygget på en Ubuntu LTS-base. Værtsdistributionen behøver ikke at matche containeren, men når den gør det, stemmer kernen og brugerområdets antagelser overens.

De fleste tredjeparts AI-værktøjer antager Ubuntu i deres README-fil. vLLM, llama.cpp, SGLang, FlashAttention-byggevejledninger, Hugging Face Accelerate-eksemplerne — alle skrevet og testet mod Ubuntu først. RHEL fungerer; du vil være den, der rapporterer problemerne, når det ikke fungerer.

Puljen af ​​personer, der har stødt på dit problem før, er størst på Ubuntu. nvidia-smi returnerer nonsens kl. 02:00, vil de første tre Stack Overflow-hits være Ubuntu-specifikke. Det betyder mere end det burde.

Debian og RHEL er ikke dårlige valg til en AI-server. De er mindre testflader, langsommere NVIDIA-valideringscyklusser og et mindre fællesskab, når noget går galt. Hvis du har en stærk organisatorisk grund til en af ​​dem - air-gapped FedRAMP, en eksisterende RHEL-sitelicens, et Debian-shop sysadmin-team - så brug det. Hvis du ikke har det, så vælg Ubuntu LTS som standard.

22.04 vs. 24.04 vs. 26.04 i maj 2026

Tre LTS-udgivelser er i aktiv support i dag. Den ærlige matrix:

Et par ting, der er værd at tage frem fra bordet.

22.04 er stadig den største installationsbase globalt, og det er det, NVIDIAs valideringspipeline har den største historik på. Hvis du har en fungerende 22.04-flåde, så gå ikke i panik over at opgradere. Den er fuldt understøttet indtil april 2027 med standardopdateringer, og Ubuntu Pro forlænger sikkerhedsvedligeholdelsen til 2032, hvis du har brug for det. Men hvis du installerer en ny server i midten af ​​2026, vælger du dit operativsystem for de næste fire til fem år. 22.04 har kun et års standardsupport tilbage. Start ikke der.

24.04 er det optimale tidspunkt for produktionsbaseret AI-arbejde i 2026. Der har været to års fejlrettelser og HWE-kernerevisioner, og alle NVIDIA-drivergrene fra R535 og fremefter har haft pakker i produktionskvalitet i NVIDIAs versioner. ubuntu2404 I repository angiver alle NGC-billeder 24.04 som en understøttet base, og du har indtil april 2029, før standardunderstøttelsen udløber. Dette er, hvad vi implementerer på nye Kentino-builds i dag.

26.04 er lige udkommet. Den leverer R595 som standarddriver i det officielle Ubuntu-repository, inkluderer CUDA i hovedrepositorierne for første gang og har gode forbedringer i Wayland/NVIDIA-historien, der er vigtige for desktops og slet ikke for headless inference-servere. Risikoen for en AI-server er timingen: i de første tre til fire måneder efter en .0 LTS-udgivelse, ubuntu-drivers Anbefalinger og DKMS-modulets adfærd flytter sig, og NVIDIAs eget repository bruger et par cyklusser på at validere hver drivergren fuldt ud mod den nye kerne. Mønsteret fra tidligere LTS-udgivelser (20.04, 22.04, 24.04) er, at den første punktudgivelse — 26.04.1 i august 2026 – det er på det tidspunkt, produktionsimplementeringer begynder at give mening. Hvis du kan vente, så vent. Hvis du ikke kan, så kør en soak-test i to uger, før du lægger noget vigtigt på den.

Stierne til driverinstallation

Der er tre måder at installere NVIDIA-driveren på en Ubuntu-boks. De er ikke lige gode.

ubuntu-drivers install er den nemme vej. Canonical vedligeholder et værktøj, der undersøger din hardware, vælger en drivergren, den anser for at være anbefalet, og installerer den matchende pakke fra Ubuntu-arkivet. Det håndterer Secure Boot-signering for dig (ved hjælp af Canonicals nøgle), det kender til HWE-kerner, og på en desktop med en enkelt forbruger-GPU fungerer det fint. På en AI-server er det den skrøbelige vej: den anbefalede gren kan ændres mellem udgivelser af ubuntu-drivers-common pakke, den version du får på apt update afhænger af, hvad Ubuntu har pakket denne uge, og du har mindre kontrol over præcis hvilken driverversion af den mindre version, der er på disken. Brug den til den bærbare computer. Brug den ikke til serveren.

apt fra NVIDIAs CUDA-arkiv er den manuelle, men kontrollerbare sti. Du tilføjer NVIDIAs cuda-keyring pakke, som etablerer den rigtige apt kildekoden til din Ubuntu-version, og installer derefter præcis de pakker, du ønsker — cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, ingen overraskelser. NVIDIA styrer pakken, du styrer versionen. Dette er Kentino-standarden.

.run installatør fra developer.nvidia.com skriver filer til /usr/local, administrerer sine egne genopbygninger af kernemoduler og integrerer ikke med apt overhovedet. Det er det rigtige svar i to snævre tilfælde: helt ny hardware, hvor den drivergren, du har brug for, ikke er kommet med i apt repository endnu, eller en arbejdsstation hvor du aktivt udvikler eller fejlfinder driveren. Ellers er det det forkerte svar. Det vil bekæmpe DKMS, det vil ikke blive opfanget af apt-mark hold, og den vil stille og roligt afbryde ved den næste kerneopdatering, fordi genopbygningsstien nu er manuel.

Konkret, på en 24.04-server med en frisk installation, er Kentino-standardsekvensen:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Install the driver branch you actually want, by number.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Efter genstart, nvidia-smi bør rapportere driver 580.x og den maksimale CUDA-version, som driveren understøtter (CUDA 13 til R580). Det er hele installationen. Bemærk, hvad der ikke er der: nej cuda meta-pakke, nr cuda-toolkit-13-0 (kun nødvendigt, hvis du kompilerer CUDA-kode på værten — se L02), nej ubuntu-driversDu valgte versionen, du installerede versionen, du ved hvad der er på disken.

De vigtigste brancher for førere i 2026

NVIDIA leverer sine Linux-drivere i filialer med specifikke supportvinduer. Fra midten af ​​2026:

R580 er den rigtige standard i 2026. Den understøtter alle GPU'er i Kentino-serien (5090, 4090, RTX Pro 6000 Blackwell begge udgaver, L40, L4) inklusive Blackwell-arkitekturens sm_120 beregningskapacitet, og den leveres med native CUDA 13-understøttelse — hvilket er, hvad alle nyere vLLM-, PyTorch 2.10/2.11- og TensorRT-LLM-udgivelser sigter mod. R570 er det konservative LTSB-valg, hvis du har en flåde af Ada (4090 / L40 / L4), der ikke har brug for de nyeste funktioner, og du ønsker at springe en driver-branch-overgang over i et år mere. R595 er, hvad Ubuntu 26.04 leverer som standard, og hvad du ønsker til den allernyeste hardware; på en server, der kun kører det, der er i Kentino-serien i dag, er R580 mere konservativ og har lige så mange funktioner.

Driveren / CUDA / PyTorch tri-version dansen

Tre uafhængige versioner skal stå på linje. De ligger oven på hinanden sådan her:

PyTorch wheel (e.g. torch==2.11.0+cu130)
        │  ships its own CUDA runtime, cuDNN, NCCL inside the wheel
        ▼
CUDA runtime version (here: 13.0)
        │  the driver must support this CUDA version or newer
        ▼
NVIDIA driver branch (here: R580 → supports CUDA 13.x)

Reglen er, at driveren understøtter en maksimal CUDA-runtime-version. Alt ældre end dette maksimum, på den samme overordnede version, vil køre. Så R580 (maks. CUDA 13.x) kører PyTorch-hjul bygget mod 13.0, 13.1, 13.2; den kører ikke hjul bygget mod den (hypotetiske) CUDA 14.0, før du opgraderer drivergrenen. Ældre drivere kan ikke køre nyere CUDA - der er fremadrettet kompatibilitet for nogle datacenterkort, men det er skrøbeligt og ikke sådan, du ønsker at fungere.

Praktisk kort over, hvad Kentino-servere kører i dag:

Dit job er at rette driveren og lade alt over den følge med. Du behøver slet ikke at installere CUDA på værten, hvis du serverer alt fra containere (og det bør du – se L02 ). Værten har brug for driveren og containerværktøjssættet. Det er det.

Fastgørelse — den absolut mest værdifulde kommando i denne artikel

Når chaufføren er inde og nvidia-smi er glad, så fastgør den. At fastgøre betyder at fortælle apt ikke at opgradere, nedgradere eller fjerne specifikke pakker, selvom en afhængighed eller en sikkerhedsopdatering ellers ville berøre dem. Kommandoen er apt-mark hold.

# Pin the driver branch.
sudo apt-mark hold \
  cuda-drivers \
  cuda-drivers-580 \
  nvidia-driver-580 \
  nvidia-driver-580-server \
  nvidia-dkms-580 \
  libnvidia-compute-580 \
  libnvidia-compute-580-server

# Pin the running kernel and its headers — DKMS needs both to rebuild,
# and a kernel jump that DKMS does not handle is exactly how you lose the GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# If you are on the Ubuntu HWE kernel meta-package, hold that too:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Verify.
apt-mark showhold

Det er omtrent halvdelen af ​​alle løste opkald med "min AI-server er holdt op med at virke". apt update && apt upgrade kører — manuelt, fra et konfigurationsstyringsværktøj eller under uovervågede opgraderinger — vil de tilbageholdte pakker ikke blive flyttet. Du vil se dem angivet under "gemt tilbage" i opgraderingsoutputtet, og du kan bevidst gennemgå og genindlæse dem i et vedligeholdelsesvindue, når du er klar.

Et par fælder. Folk holder nvidia-driver-580 og glemme cuda-drivers-580, som er den faktiske metapakke på CUDA-repoet. Hvis cuda-drivers-580 opgraderinger, fordi en transitiv afhængighed ønsker en nyere punktudgivelse, vil den hente en ny nvidia-dkms-580 med det, og du har mistet pinkoden. List begge. Folk har kernelbilledet, men ikke headerne, kernen opdateres alligevel på grund af en metapakke, og DKMS kan ikke finde headere, når den forsøger at genopbygge — nvidia-smi virker indtil genstart, så gør det ikke. Hold altid billede og headere sammen.

Kernen og DKMS-fejlene

DKMS (Dynamic Kernel Module Support) er det system, der genopbygger kernemoduler uden for træet, når kernen ændres. NVIDIA nvidia-dkms-XXX Pakken registrerer driveren som et DKMS-modul, så en apt-administreret kernelopgradering i teorien udløser en ren modulgenopbygning, og du genstarter i et fungerende system.

I praksis fejler DKMS-genopbygninger på tre måder, der gentages:

Kernelheaderne er ikke installeret til den nye kerne — almindeligt, når kernepakken blev installeret, men headerpakken blev filtreret fra af en apt-præference-pin eller et brugerdefineret valg. Den nye kerne starter, NVIDIA-modulet mangler. nvidia-smi returnerer "NVIDIA-SMI fejlede, fordi den ikke kunne kommunikere med NVIDIA-driveren."

Den nye kerne er for ny til drivergrenen. R570 bygger ikke rent mod den seneste 6.14-kerne; det gør R580. Hvis du lader en HWE-bump skubbe dig hen til en kerne, som drivergrenen aldrig er blevet testet mod, producerer DKMS en byggefejl i /var/lib/dkms/nvidia/.../make.log og du genstarter i et fungerende, men GPU-løst system.

Sikker opstart er aktiveret, og det genopbyggede modul er usigneret. Canonicals ubuntu-drivers-installerede pakker leveres med Canonicals signeringshåndtering. NVIDIAs CUDA-repo-pakker gør det ikke; de ​​kræver, at du tilmelder en Machine Owner Key (MOK) og signerer de genopbyggede moduler ved hver kerneændring. DKMS kan udføre signeringen automatisk med den korrekte konfiguration pr. modul, men det skal konfigureres før den første genopbygning, ikke efter at systemet ikke kan starte. Hvis du ikke har brug for Secure Boot - og på en headless inferenceserver i et låst rack har du det muligvis ikke - så deaktiver det i firmwaren, før du installerer driveren, og spring hele denne type problemer over.

Ved at fastlåse kernen undgår du alle tre ting. Kernen ændres ikke uden din indblanding, headerne forbliver matchede, og det genopbyggede modul fortsætter med at indlæses. Når du ønsker at tage en ny kerne – til en CVE eller en reel funktion – gør du det bevidst med et snapshot, der er klar til at blive rullet tilbage.

Bare-metal CUDA — når det (sjældent) stadig er rigtigt

L02 argumenterer for, at bare-metal CUDA stort set er det forkerte valg nu: containere skjuler CUDA-versionsdansen, afkobler værten fra arbejdsbyrden og påfører ubetydelige performanceomkostninger. Det er korrekt for ~95% af installationerne.

Undtagelserne er snævre. GPU-profilering på kernelniveau med Nsight Systems / Nsight Compute, hvor containerlaget skjuler de syscalls, du er interesseret i. Driverarbejde — kørsel af pre-release-drivere fra NVIDIA, fejlfinding af nedbrud, der involverer selve kernelmodulet. Miljøer med tætte luftgap, hvor det er sværere at hente og stole på OCI-billeder end at vedligeholde et frosset apt-spejl. En håndfuld HPC-sider, der har bygget alt op omkring module load og bare-metal MPI og er ikke interesserede i at ændre.

Til alle andre: installer driveren "bare metal", lad værten være ren for CUDA, og kør CUDA inde i containere. nvidia-container-toolkit (dækket af L02) bygger en ren bro mellem de to.

Uovervågede opgraderinger – hvad skal tillades, og hvad skal blokeres

Ubuntus unattended-upgrades Pakken er god, og du bør lade den være aktiveret. At springe sikkerhedsopdateringer helt over på en netværksforbundet server er værre end risikoen for, at en automatisk opgradering går galt. Det rigtige mønster er: sikkerhedsopdateringer ja, kerne- og NVIDIA-pakker nej.

Redigere /etc/apt/apt.conf.d/50unattended-upgrades og tilføj til sortlisteblokken:

Unattended-Upgrade::Package-Blacklist {
    "linux-image-";
    "linux-headers-";
    "linux-generic";
    "linux-modules-";
    "nvidia-";
    "libnvidia-";
    "cuda";
    "cuda-";
    "libcudnn";
};

apt-mark hold forhindrer allerede disse pakker i at blive opgraderet. Sortlisten er en leg – den gør intentionen eksplicit, den stopper unattended-upgrades fra overhovedet at logge et forsøg, og det overlever en uforsigtig apt-mark unhold fra en junioradministrator. Kør begge.

Bekræft ved at hale /var/log/unattended-upgrades/unattended-upgrades.log efter næste kørsel. Du bør se sikkerhedspakker blive gennemført, og de tilbageholdte/sortlistede pakker blive eksplicit sprunget over.

Gendannelseshåndbogen "Jeg har opgraderet til dist, og nu virker ingenting".

Nogen løb apt full-upgrade (eller dit CM-værktøj gjorde det), og ved næste genstart er GPU'erne væk. Rækkefølge af operationer:

1. Boot. Hvis systemet ikke starter, skal du holde shift/Esc nede ved GRUB-prompten og vælge den forrige kerne fra boot-menuen. Bekræft. nvidia-smi virker under den gamle kerne. Hvis den gør det, er den nye kerne problemet; fastgør den gamle (apt-mark hold linux-image-<old>) og fortsæt.
2. Hvis systemet startede, men nvidia-smi siger NVML-mismatch, du kører et nyt brugerområde mod et gammelt indlæst modul. Genstart. Det retter det næsten altid.
3. If nvidia-smi siger, at driveren ikke er indlæst, tjek /var/lib/dkms/nvidia/<version>/build/make.log og dmesg | grep -i nvidiaDe mest almindelige fejl: manglende kerneheadere (apt install linux-headers-$(uname -r) derefter dkms autoinstall); en kerne, der er for ny til driveren (nedgrader kernen eller opgrader drivergrenen bevidst); Sikker opstart afviser det usignerede modul (mokutil --sb-state, og deaktiver derefter enten SB eller tilmeld en MOK).
4. Hvis selve driverpakkerne blev dist-opgraderet til en tilstand, du ikke ønskede — for eksempel hvis metapakken trak R585 over din fastlåste R580, fordi nogen fjernede spærringen — så ryd og geninstaller: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, gentag derefter installationen fra CUDA-repoet med den version, du rent faktisk ønsker, og anvend derefter spærringerne igen.
5. Hvis du har et snapshot – og det burde du, se nedenfor – så gendan det. Det er tyve minutter tilbage til den oprindelige tilstand i modsætning til fire timers fejlfinding.

Øjebliksbillede før du rører driveren eller kernen

Uanset dit lagerlayout, tag et snapshot før enhver driver- eller kerneoperation. ZFS-brugere (/ på ZFS eller et separat datasæt) få dette gratis med zfs snapshot rpool@pre-driver-upgrade-2026-05-15LVM-brugere med tynde pools kan lvcreate --snapshotext4-brugere uden LVM sidder fast med fulde sikkerhedskopier; dette er en af ​​grundene til, at vi dækker filsystemlayout i L04.

Disciplinen der betaler sig: rør aldrig driveren, CUDA-pakkerne eller kernen uden at tage et snapshot inden for de foregående fem minutter. Prisen for et snapshot er sekunder. Prisen for ikke at have et, når en opgradering går galt, er en halv dags nedetid og en eller andens aften.

LTS-opgraderingssti

Ubuntu LTS-til-LTS-opgraderinger sker hvert andet år; for AI-servere anbefaler vi at springe hvert andet år over. Stien er:

22.04  ──(skip 23.x interim, skip 24.04 if production-stable)──▶  26.04
24.04  ──(skip 25.x interim, skip 26.04 if production-stable)──▶  28.04

Ræsonnementet: Omkostningerne ved en LTS-opgradering på en AI-server er høje (drivervalidering, container image-gentest, ofte en genkørsel af integrationsbenchmarks), fordelen ved at gå ét trin i stedet for to er lille, og Ubuntus LTS-til-LTS-opgraderingsværktøjer understøtter fuldt ud springet over. Planlæg opgraderingen, planlæg et vedligeholdelsesvindue, snapshot, kør do-release-upgrade, soak-test i en uge, og flyt derefter arbejdsbelastninger tilbage. Direkte overgang fra 22.04 til 26.04 understøttes, og det er, hvad de fleste Kentino-kunder vil ende med at gøre sent i 2026 eller i 2027.

Hvad skal man undgå: In-place opgraderinger under en udviklingssprint, opgradering uden et snapshot, opgradering og derefter øjeblikkelig distributionsopgradering af NVIDIA-stakken på samme tid. Ændr én ting ad gangen.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.