Pinovanie Ubuntu a správa ovládačov NVIDIA pre AI servery

Ak zodpovedáte za AI server, od ktorého závisia iní ľudia, najpravdepodobnejšou príčinou Vášho ďalšieho výpadku nebude porucha hardvéru, chyba modelu ani problém s napájaním. Bude to apt-get upgrade, ktorý ste Vy alebo Vaša distribúcia spustili na pozadí, ktorý stiahol nové jadro, voči ktorému sa modul NVIDIA DKMS čisto neprebudoval, a po ktorom nvidia-smi pri ďalšom reštarte vracia Failed to initialize NVML: Driver/library version mismatch. Je to najčastejší hovor na podporu Kentino po tom, čo server beží dva alebo tri mesiace.

Tento článok je o tom, ako tomu predísť. Hovorí o tom, ktoré Ubuntu LTS si v polovici roka 2026 vybrať, ako nainštalovať ovládač NVIDIA spôsobom, ktorému sa dá naozaj porozumieť, ako pripnúť ovládač a jadro, aby ich bezobslužná aktualizácia nemohla potichu zničiť, a ako sa z toho dostať, keď to už niekto urobil.

Je určený každému, kto bude písať sudo na stroji so 4 alebo 8 GPU, ktorý má fungovať roky.

Prečo vôbec Ubuntu LTS

Existujú technicky schopné linuxové distribúcie, ktoré nie sú Ubuntu — Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Žiadna z nich nie je zlá a niektoré sú zrejme lepšie navrhnuté. Pre AI servery napriek tomu odporúčame Ubuntu LTS, a to zo štyroch dôvodov, ktoré s eleganciou nemajú nič spoločné.

NVIDIA testuje najskôr voči Ubuntu LTS. Jej apt repozitáre dodávajú balíky cuda-keyring výslovne pre ubuntu2204, ubuntu2404 a (od jari 2026) ubuntu2604. Príručka na inštaláciu ovládača menuje Ubuntu LTS podľa čísla verzie; ostatné distribúcie uvádza až v zadnej časti dokumentu.

Kontajnerový ekosystém predpokladá Ubuntu. Každý NGC image (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) je postavený na základe Ubuntu LTS. Distribúcia hostiteľa sa nemusí zhodovať s kontajnerom, ale keď sa zhoduje, predpoklady jadra a userspace do seba čisto zapadnú.

Väčšina AI nástrojov tretích strán predpokladá vo svojom README Ubuntu. vLLM, llama.cpp, SGLang, pokyny na zostavenie FlashAttention, príklady Hugging Face Accelerate — všetko napísané a testované najskôr voči Ubuntu. RHEL funguje; keď prestane, budete to Vy, kto bude zakladať issues.

Skupina ľudí, ktorí Váš problém riešili pred Vami, je najväčšia na Ubuntu. Keď nvidia-smi o 02:00 vracia nezmysly, prvé tri výsledky na Stack Overflow budú špecifické pre Ubuntu. Záleží na tom viac, než by malo.

Debian a RHEL nie sú pre AI server zlé voľby. Majú menšiu testovaciu plochu, pomalšie validačné cykly NVIDIA a menšiu komunitu, keď sa niečo pokazí. Ak máte pre niektorú z nich silný organizačný dôvod — izolovaný FedRAMP, existujúcu licenciu RHEL pre lokalitu, tím správcov zvyknutých na Debian — použite ju. Ak nie, predvolene siahnite po Ubuntu LTS.

22.04 vs 24.04 vs 26.04 v máji 2026

Tri vydania LTS sú dnes v aktívnej podpore. Úprimná matica:

Pár vecí z tej tabuľky stojí za zvýraznenie.

22.04 má stále najväčšiu inštalovanú základňu na svete a validačná linka NVIDIA s ňou má najdlhšiu históriu. Ak máte funkčnú flotilu na 22.04, nepanikárte s upgradom. So štandardnými aktualizáciami je plne podporovaná do apríla 2027 a Ubuntu Pro predlžuje bezpečnostnú údržbu do roku 2032, ak ju potrebujete. Ak však v polovici roka 2026 nasadzujete do racku nový server, vyberáte si OS na ďalšie štyri až päť rokov. 22.04 má pred sebou už len jeden rok štandardnej podpory. Nezačínajte pri nej.

24.04 je pre produkčnú AI prácu v roku 2026 zlatá stredná cesta. Má za sebou dva roky opráv chýb a revízií HWE jadier, každá vetva ovládača NVIDIA od R535 ďalej má balíky v produkčnej kvalite v repozitári NVIDIA ubuntu2404, každý NGC image uvádza 24.04 ako podporovaný základ a do konca štandardnej podpory máte čas do apríla 2029. Práve toto dnes nasadzujeme na nové zostavy Kentino.

26.04 je čerstvo vonku. Ako predvolený ovládač v oficiálnom repozitári Ubuntu dodáva R595, prvýkrát obsahuje CUDA v hlavných repozitároch a prináša dobré zlepšenia v súhre Waylandu a NVIDIA, ktoré majú význam pre desktopy a vôbec žiadny pre bezhlavé inferenčné servery. Rizikom pre AI server je načasovanie: v prvých troch až štyroch mesiacoch po vydaní .0 LTS sa odporúčania ubuntu-drivers a správanie modulov DKMS menia a vlastný repozitár NVIDIA potrebuje pár cyklov, kým plne overí každú vetvu ovládača voči novému jadru. Vzorec z minulých vydaní LTS (20.04, 22.04, 24.04) hovorí, že produkčné nasadenia začínajú dávať zmysel až pri prvom bodovom vydaní — 26.04.1 v auguste 2026. Ak môžete počkať, počkajte. Ak nie, nechajte ho dva týždne bežať v záťažovom teste, než naň dáte čokoľvek dôležité.

Cesty inštalácie ovládača

Ovládač NVIDIA sa dá na Ubuntu stroj dostať tromi spôsobmi. Nie sú rovnako dobré.

ubuntu-drivers install je jednoduchá cesta. Canonical udržiava nástroj, ktorý preskúma Váš hardvér, vyberie vetvu ovládača, ktorú považuje za odporúčanú, a nainštaluje zodpovedajúci balík z archívu Ubuntu. Postará sa za Vás o podpisovanie pre Secure Boot (kľúčom Canonical), vie o HWE jadrách a na desktope s jedinou spotrebiteľskou GPU funguje dobre. Na AI serveri je to krehká cesta: odporúčaná vetva sa môže meniť medzi vydaniami balíka ubuntu-drivers-common, verzia, ktorú dostanete pri apt update, závisí od toho, čo Ubuntu tento týždeň zabalilo, a máte menšiu kontrolu nad tým, ktorá presná minoritná verzia ovládača je na disku. Použite to na notebooku. Nepoužívajte to na serveri.

apt z CUDA repozitára NVIDIA je manuálna, ale kontrolovateľná cesta. Pridáte balík cuda-keyring od NVIDIA, ktorý nastaví správny zdroj apt pre Vašu verziu Ubuntu, a potom nainštalujete presne tie balíky, ktoré chcete — cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, žiadne prekvapenia. Balenie riadi NVIDIA, verziu riadite Vy. Toto je predvoľba Kentino.

Inštalátor .run z developer.nvidia.com zapisuje súbory do /usr/local, spravuje si vlastné prebudovanie modulov jadra a vôbec sa neintegruje s apt. Je správnou odpoveďou v dvoch úzkych prípadoch: úplne nový hardvér, kde sa potrebná vetva ovládača ešte nedostala do repozitára apt, alebo workstation, na ktorom ovládač aktívne vyvíjate či ladíte. Inak je to nesprávna odpoveď. Bude bojovať s DKMS, nezachytí ho apt-mark hold a pri ďalšej aktualizácii jadra sa potichu rozbije, pretože cesta prebudovania je odteraz manuálna.

Konkrétne, na serveri s 24.04 a čerstvou inštaláciou vyzerá predvolená postupnosť Kentino takto:

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

# Nainštalujte vetvu ovládača, ktorú naozaj chcete, podľa čísla.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Po reštarte by mal nvidia-smi hlásiť ovládač 580.x a maximálnu verziu CUDA, ktorú ovládač podporuje (CUDA 13 pri R580). To je celá inštalácia. Všimnite si, čo v nej nie je: žiadny meta-balík cuda, žiadny cuda-toolkit-13-0 (ten je potrebný, len ak na hostiteľovi kompilujete CUDA kód — pozri L02), žiadne ubuntu-drivers. Vybrali ste verziu, nainštalovali ste verziu, viete, čo máte na disku.

Vetvy ovládačov, na ktorých v roku 2026 záleží

NVIDIA dodáva svoje linuxové ovládače vo vetvách s konkrétnymi obdobiami podpory. K polovici roka 2026:

R580 je v roku 2026 správna predvoľba. Podporuje každú GPU v ponuke Kentino (5090, 4090, RTX Pro 6000 Blackwell v oboch edíciách, L40, L4) vrátane výpočtovej schopnosti sm_120 architektúry Blackwell a prináša natívnu podporu CUDA 13 — presne to, na čo cieli každé nedávne vydanie vLLM, PyTorch 2.10/2.11 a TensorRT-LLM. R570 je konzervatívna voľba LTSB, ak máte flotilu Ada (4090 / L40 / L4), ktorá najnovšie funkcie nepotrebuje, a chcete si prechod na inú vetvu ovládača odložiť o ďalší rok. R595 je to, čo predvolene dodáva Ubuntu 26.04 a čo chcete pre úplne najnovší hardvér; na serveri, ktorý beží len na tom, čo je dnes v ponuke Kentino, je R580 konzervatívnejšie a rovnako vybavené.

Trojitý tanec verzií ovládač / CUDA / PyTorch

Tri nezávislé verzie si musia sadnúť. Sedia na sebe takto:

PyTorch wheel (napr. torch==2.11.0+cu130)
        │  vo wheele si nesie vlastný CUDA runtime, cuDNN a NCCL
        ▼
Verzia CUDA runtime (tu: 13.0)
        │  ovládač musí podporovať túto verziu CUDA alebo novšiu
        ▼
Vetva ovládača NVIDIA (tu: R580 → podporuje CUDA 13.x)

Pravidlo znie, že ovládač podporuje maximálnu verziu behového prostredia CUDA. Čokoľvek staršie než toto maximum v rámci tej istej hlavnej verzie pobeží. Takže R580 (max. CUDA 13.x) spustí PyTorch wheels zostavené voči 13.0, 13.1 aj 13.2; nespustí wheels zostavené voči (hypotetickej) CUDA 14.0, kým neprejdete na novšiu vetvu ovládača. Staršie ovládače novšiu CUDA spustiť nedokážu — pre niektoré datacentrové karty existuje dopredná kompatibilita, ale je krehká a nie je to spôsob, akým chcete server prevádzkovať.

Praktická mapa toho, čo dnes bežia servery Kentino:

Vašou úlohou je zafixovať ovládač a nechať všetko nad ním, nech sa prispôsobí. CUDA na hostiteľa vôbec inštalovať nemusíte, ak všetko obsluhujete z kontajnerov (a mali by ste — pozri L02). Hostiteľ potrebuje ovládač a container toolkit. To je všetko.

Pinning — najhodnotnejší príkaz v tomto článku

Keď je ovládač nainštalovaný a nvidia-smi je spokojný, pripnite ho. Pinning znamená povedať nástroju apt, aby konkrétne balíky neaktualizoval, nedegradoval ani neodstraňoval, aj keby sa ich inak dotkla závislosť alebo bezpečnostná aktualizácia. Príkaz je apt-mark hold.

# Pripnite vetvu ovládača.
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

# Pripnite bežiace jadro a jeho hlavičky — DKMS potrebuje oboje na prebudovanie,
# a skok jadra, ktorý DKMS nezvládne, je presne to, čím prídete o GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# Ak používate meta-balík HWE jadra Ubuntu, pripnite aj ten:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Overte.
apt-mark showhold

Tým sa vyrieši zhruba polovica všetkých hovorov v štýle „môj AI server prestal fungovať“. Keď apt update && apt upgrade beží — manuálne, z nástroja na správu konfigurácie alebo pod unattended-upgrades — tie pripnuté balíky sa nepohnú. Uvidíte ich vo výpise aktualizácie pod „kept back“ a môžete ich vedome prejsť a odopnúť počas servisného okna, keď na to budete pripravení.

Pár pascí. Ľudia pripnú nvidia-driver-580 a zabudnú na cuda-drivers-580, čo je skutočný meta-balík v CUDA repozitári. Ak sa cuda-drivers-580 aktualizuje, pretože tranzitívna závislosť chce novšie bodové vydanie, stiahne so sebou nový nvidia-dkms-580 a pin je preč. Uveďte oba. Ľudia pripnú image jadra, ale nie hlavičky, jadro sa aj tak aktualizuje kvôli meta-balíku a DKMS pri pokuse o prebudovanie hlavičky nenájde — nvidia-smi funguje až do reštartu, potom už nie. Vždy pripínajte image aj hlavičky spolu.

Pasce jadra a DKMS

DKMS (Dynamic Kernel Module Support) je systém, ktorý pri každej zmene jadra prebuduje moduly mimo stromu jadra. Balík NVIDIA nvidia-dkms-XXX registruje ovládač ako modul DKMS, takže teoreticky aktualizácia jadra cez apt spustí čisté prebudovanie modulu a Vy reštartujete do funkčného systému.

V praxi prebudovanie DKMS zlyháva tromi opakujúcimi sa spôsobmi:

Pre nové jadro nie sú nainštalované hlavičky — bežné vtedy, keď sa balík jadra nainštaloval, ale balík hlavičiek odfiltroval pin v apt preferences alebo vlastný výber. Nové jadro nabehne, modul NVIDIA chýba a nvidia-smi vracia „NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.“

Nové jadro je pre danú vetvu ovládača príliš nové. R570 sa voči najnovšiemu jadru 6.14 čisto nezostaví; R580 áno. Ak necháte skok HWE posunúť sa na jadro, voči ktorému vetva ovládača nikdy nebola testovaná, DKMS vyprodukuje chybu zostavenia v /var/lib/dkms/nvidia/.../make.log a Vy reštartujete do funkčného systému, ale bez GPU.

Secure Boot je zapnutý a prebudovaný modul je nepodpísaný. Balíky nainštalované cez ubuntu-drivers od Canonical majú podpisovanie vyriešené. Balíky z CUDA repozitára NVIDIA nie; vyžadujú, aby ste zaregistrovali Machine Owner Key (MOK) a prebudované moduly podpisovali pri každej zmene jadra. DKMS to pri správnej konfigurácii pre každý modul zvládne podpisovať automaticky, ale musí byť nastavený pred prvým prebudovaním, nie až keď systém nenabehne. Ak Secure Boot nepotrebujete — a na bezhlavom inferenčnom serveri v zamknutom racku ho pravdepodobne naozaj nepotrebujete — vypnite ho vo firmware ešte pred inštaláciou ovládača a vyhnete sa celej tejto triede problémov.

Pripnutie jadra obchádza všetky tri. Jadro sa nezmení bez Vášho pričinenia, hlavičky zostanú zosúladené a prebudovaný modul sa naďalej načíta. Keď nové jadro naozaj chcete — kvôli CVE alebo skutočnej funkcii — urobíte to vedome, so snapshotom a pripravení vrátiť sa späť.

CUDA na holom železe — kedy (zriedka) má stále zmysel

L02 vysvetľuje, že CUDA na holom železe je dnes väčšinou nesprávna voľba: kontajnery skrývajú tanec verzií CUDA, oddeľujú hostiteľa od workloadu a majú zanedbateľnú výkonnostnú daň. Pre ~95 % inštalácií to platí.

Výnimky sú úzke. Profilovanie GPU na úrovni jadra pomocou Nsight Systems / Nsight Compute, kde vrstva kontajnera skrýva syscally, na ktorých Vám záleží. Práca na ovládačoch — prevádzka predbežných ovládačov od NVIDIA, ladenie pádov, ktoré sa týkajú samotného modulu jadra. Prísne izolované prostredia, kde je sťahovanie a dôverovanie OCI obrazom náročnejšie než údržba zamrazeného apt mirroru. Hŕstka HPC pracovísk, ktoré všetko postavili okolo module load a MPI na holom železe a nemajú záujem to meniť.

Pre všetkých ostatných: nainštalujte ovládač na holé železo, nechajte hostiteľa bez CUDA a CUDA spúšťajte v kontajneroch. nvidia-container-toolkit (opisujeme ho v L02) obe strany čisto prepája.

Bezobslužné aktualizácie — čo povoliť a čo zablokovať

Balík unattended-upgrades od Ubuntu je dobrý a mali by ste ho nechať zapnutý. Úplne vynechať bezpečnostné aktualizácie na serveri pripojenom do siete je horšie než riziko, že automatická aktualizácia dopadne zle. Správny vzorec je: bezpečnostné aktualizácie áno, jadro a balíky NVIDIA nie.

Upravte /etc/apt/apt.conf.d/50unattended-upgrades a do bloku blacklist pridajte:

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

apt-mark hold už týmto balíkom bráni v aktualizácii. Blacklist je pás aj traky — robí zámer explicitným, zabráni nástroju unattended-upgrades čo i len zalogovať pokus a prežije aj neopatrné apt-mark unhold od juniorného administrátora. Použite oboje.

Overte si to sledovaním /var/log/unattended-upgrades/unattended-upgrades.log po ďalšom behu. Mali by ste vidieť, ako bezpečnostné balíky prechádzajú a pripnuté či blacklistované sa výslovne preskakujú.

Playbook na obnovu „urobil som dist-upgrade a teraz nič nefunguje“

Niekto spustil apt full-upgrade (alebo to urobil Váš CM nástroj) a po ďalšom reštarte sú GPU preč. Poradie krokov:

1. Naštartujte. Ak systém nenabehne, podržte pri GRUB prompte shift / Esc a vyberte z ponuky predchádzajúce jadro. Overte, že nvidia-smi pod starým jadrom funguje. Ak áno, problémom je nové jadro; pripnite to staré (apt-mark hold linux-image-<old>) a pokračujte.
2. Ak systém nabehol, ale nvidia-smi hlási nesúlad NVML, beží Vám nový userspace voči staro načítanému modulu. Reštartujte. Takmer vždy to pomôže.
3. Ak nvidia-smi hlási, že ovládač nie je načítaný, pozrite /var/lib/dkms/nvidia/<version>/build/make.log a dmesg | grep -i nvidia. Najčastejšie zlyhania: chýbajúce hlavičky jadra (apt install linux-headers-$(uname -r) a potom dkms autoinstall); jadro príliš nové pre ovládač (zámerne degradujte jadro alebo vedome prejdite na novšiu vetvu ovládača); Secure Boot odmieta nepodpísaný modul (mokutil --sb-state, potom buď vypnite SB, alebo zaregistrujte MOK).
4. Ak samotné balíky ovládača prešli dist-upgradom do stavu, aký ste nechceli — napríklad meta-balík pretlačil R585 cez Váš pripnutý R580, lebo niekto odstránil hold — vyčistite ich a nainštalujte nanovo: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, potom zopakujte inštaláciu z CUDA repozitára vo verzii, ktorú naozaj chcete, a znova nasaďte holdy.
5. Ak máte snapshot — a mať by ste ho mali, pozri nižšie — obnovte ho. Je to dvadsať minút späť do známeho dobrého stavu oproti štyrom hodinám ladenia.

Pred každým zásahom do ovládača alebo jadra urobte snapshot

Nech už máte akékoľvek usporiadanie úložiska, pred každou operáciou s ovládačom alebo jadrom urobte snapshot. Používatelia ZFS (/ na ZFS alebo samostatný dataset) ho majú zadarmo cez zfs snapshot rpool@pre-driver-upgrade-2026-05-15. Používatelia LVM s thin poolmi môžu použiť lvcreate --snapshot. Používatelia ext4 bez LVM sú odkázaní na plné zálohy; aj preto sa rozloženiu súborového systému venujeme v L04.

Disciplína, ktorá sa vyplatí: nikdy sa nedotýkajte ovládača, balíkov CUDA ani jadra bez toho, aby ste v predchádzajúcich piatich minútach urobili snapshot. Snapshot stojí sekundy. To, že ho nemáte, keď sa aktualizácia pokazí, stojí pol dňa výpadku a niekomu celý večer.

Cesta upgradu LTS

Upgrady z LTS na LTS prichádzajú každé dva roky; pri AI serveroch odporúčame každý druhý vynechať. Cesta vyzerá takto:

22.04  ──(preskočte 23.x interim aj 24.04, ak je produkčne stabilné)──▶  26.04
24.04  ──(preskočte 25.x interim aj 26.04, ak je produkčne stabilné)──▶  28.04

Dôvod: upgrade LTS na AI serveri je drahý (opätovná validácia ovládačov, nové testy obrazov kontajnerov, často aj zopakovanie integračných benchmarkov), prínos jedného kroku oproti dvom je malý a nástroje Ubuntu na upgrade medzi LTS preskočenie plne podporujú. Naplánujte upgrade, vyhraďte servisné okno, urobte snapshot, spustite do-release-upgrade, týždeň nechajte systém v záťažovom teste a potom vráťte workloady späť. Prechod 22.04 → 26.04 priamo je podporovaný a práve to väčšina zákazníkov Kentino nakoniec urobí koncom roka 2026 alebo v roku 2027.

Čomu sa vyhnúť: upgradom počas vývojového šprintu, upgradu bez snapshotu a upgradu s okamžitým dist-upgradom celého NVIDIA stacku naraz. Meňte vždy len jednu vec.

---

Toto je súčasť Kentino Wiki, referenčnej série o AI výpočtoch, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy uvítame na info@kentino.com.