Pinning Ubuntu a správa ovladačů NVIDIA pro AI servery

Pokud zodpovídáte za AI server, na kterém závisí ostatní lidé, nejpravděpodobnější příčinou Vašeho příštího výpadku nebude selhání hardwaru, chyba modelu ani problém s napájením. Bude to apt-get upgrade, který jste Vy nebo Vaše distribuce spustili na pozadí. Stáhl nové jádro, proti kterému se modul NVIDIA DKMS čistě nesestavil, a po dalším restartu začne nvidia-smi vracet Failed to initialize NVML: Driver/library version mismatch. Je to vůbec nejčastější důvod volání na podporu Kentino poté, co server běží dva až tři měsíce.

Tento článek je o tom, jak tomu předejít. Popisuje, které Ubuntu LTS zvolit v polovině roku 2026, jak nainstalovat ovladač NVIDIA způsobem, kterému budete opravdu rozumět, jak zamknout ovladač i jádro tak, aby Vám bezobslužná aktualizace nemohla potichu rozbít celý stack, a jak se z toho dostat, když to někdo přesto udělá.

Článek je určen každému, kdo bude psát sudo na stroji se 4 nebo 8 GPU, který má spolehlivě běžet roky.

Proč vůbec Ubuntu LTS

Existují technicky zdatné linuxové distribuce, které nejsou Ubuntu — Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Žádná z nich není špatná a některé jsou nepochybně lépe navržené. Pro AI servery přesto doporučujeme Ubuntu LTS, a to ze čtyř důvodů, které s elegancí nemají nic společného.

NVIDIA testuje nejdřív proti Ubuntu LTS. Její repozitáře apt dodávají balíčky cuda-keyring výslovně pro ubuntu2204, ubuntu2404 a (od jara 2026) ubuntu2604. Instalační příručka ovladače jmenuje Ubuntu LTS podle čísla verze; ostatní distribuce zmiňuje až na konci dokumentu.

Ekosystém kontejnerů počítá s Ubuntu. Každý obraz NGC (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) stojí na základu Ubuntu LTS. Hostitelská distribuce se s kontejnerem shodovat nemusí, ale když se shoduje, předpoklady o jádře a uživatelském prostoru do sebe čistě zapadnou.

Většina nástrojů třetích stran pro AI počítá ve svém README s Ubuntu. vLLM, llama.cpp, SGLang, návody na sestavení FlashAttention, příklady Hugging Face Accelerate — všechno je psané a testované nejdřív na Ubuntu. RHEL funguje; ale hlášení chyb budete zakládat Vy.

Skupina lidí, kteří Váš problém už řešili, je největší právě na Ubuntu. Když nvidia-smi ve dvě ráno vrací nesmysly, první tři odkazy ze Stack Overflow budou specifické pro Ubuntu. To má větší váhu, než by mělo mít.

Debian a RHEL nejsou pro AI server špatná volba. Mají jen menší testovací základnu, pomalejší validační cykly NVIDIA a menší komunitu, když se něco pokazí. Pokud máte pro některou z nich silný firemní důvod — oddělené prostředí FedRAMP, stávající licenci RHEL na lokalitu, administrátorský tým zvyklý na Debian — použijte ji. Pokud ne, volte ve výchozím stavu Ubuntu LTS.

22.04 vs. 24.04 vs. 26.04 v květnu 2026

Aktivní podporu mají dnes tři vydání LTS. Upřímná matice:

Z té tabulky stojí za zdůraznění několik věcí.

22.04 má celosvětově stále největší instalovanou základnu a validační pipeline NVIDIA na ní má nejvíc historie. Pokud Vám flotila na 22.04 funguje, nepřecházejte panicky jinam. Se standardními aktualizacemi je plně podporovaná do dubna 2027 a Ubuntu Pro bezpečnostní údržbu prodlouží až do roku 2032, pokud to potřebujete. Když ale v polovině roku 2026 nasazujete nový server do racku, vybíráte si operační systém na další čtyři až pět let. 22.04 má před sebou poslední rok standardní podpory. Tam nezačínejte.

24.04 je pro produkční AI nasazení v roce 2026 zlatý střed. Má za sebou dva roky oprav a revizí HWE jader, každá větev ovladače NVIDIA od R535 výš má v repozitáři NVIDIA ubuntu2404 balíčky v produkční kvalitě, každý obraz NGC uvádí 24.04 jako podporovaný základ a do konce standardní podpory máte čas do dubna 2029. Právě to dnes nasazujeme na nové sestavy Kentino.

26.04 je čerstvě venku. Jako výchozí ovladač v oficiálním repozitáři Ubuntu dodává R595, poprvé obsahuje CUDA přímo v hlavních repozitářích a přináší zlepšení v součinnosti Wayland / NVIDIA, která jsou důležitá pro desktopy a vůbec ne pro bezhlavé inferenční servery. Rizikem je u AI serveru načasování: v prvních třech až čtyřech měsících po vydání LTS verze .0 se doporučení ubuntu-drivers a chování modulů DKMS mění a vlastní repozitář NVIDIA potřebuje několik cyklů, než proti novému jádru plně ověří všechny větve ovladačů. Ze starších vydání LTS (20.04, 22.04, 24.04) plyne vzorec, že produkční nasazení začínají dávat smysl až od prvního bodového vydání — 26.04.1 v srpnu 2026. Pokud můžete počkat, počkejte. Pokud ne, nechte systém dva týdny v zátěžovém testu, než na něj dáte cokoli důležitého.

Způsoby instalace ovladače

Ovladač NVIDIA lze na Ubuntu dostat třemi způsoby. Nejsou si rovny.

ubuntu-drivers install je snadná cesta. Canonical udržuje nástroj, který prozkoumá Váš hardware, vybere větev ovladače, kterou považuje za doporučenou, a nainstaluje odpovídající balíček z archivu Ubuntu. Postará se za Vás o podepsání pro Secure Boot (klíčem Canonicalu), zná jádra HWE a na desktopu s jednou spotřebitelskou grafikou funguje dobře. Na AI serveru je to ale křehká cesta: doporučená větev se může mezi vydáními balíčku ubuntu-drivers-common změnit, verze, kterou dostanete po apt update, závisí na tom, co Ubuntu tento týden zabalilo, a nad přesnou minoritní verzí ovladače na disku máte menší kontrolu. Použijte ji na notebook. Na server ne.

apt z repozitáře CUDA od NVIDIA je ruční, ale kontrolovatelná cesta. Přidáte balíček cuda-keyring od NVIDIA, který nastaví správný zdroj apt pro Vaši verzi Ubuntu, a pak nainstalujete přesně ty balíčky, které chcete — cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580 — žádná překvapení. Balení řídí NVIDIA, verzi řídíte Vy. Tohle je výchozí postup Kentino.

Instalátor .run z developer.nvidia.com zapisuje soubory do /usr/local, sám si řeší rebuildy jaderných modulů a s apt se vůbec neintegruje. Správná odpověď je jen ve dvou úzkých případech: zbrusu nový hardware, kde potřebná větev ovladače ještě není v repozitáři apt, nebo workstation, na které ovladač aktivně vyvíjíte či ladíte. Jinak je to odpověď špatná. Bude bojovat s DKMS, nezachytí ho apt-mark hold a při příští aktualizaci jádra se potichu rozbije, protože cesta k rebuildu je teď ruční.

Konkrétně na čerstvě nainstalovaném serveru s 24.04 vypadá výchozí postup 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

# Nainstalujte přesně tu větev ovladače, kterou chcete, podle čísla.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Po restartu by měl nvidia-smi hlásit ovladač 580.x a maximální verzi CUDA, kterou ovladač podporuje (pro R580 je to CUDA 13). To je celá instalace. Všimněte si, co v ní není: žádný metabalíček cuda, žádný cuda-toolkit-13-0 (ten je potřeba, jen když na hostiteli kompilujete kód v CUDA — viz L02), žádné ubuntu-drivers. Verzi jste vybrali, verzi jste nainstalovali, víte, co máte na disku.

Větve ovladačů, na kterých v roce 2026 záleží

NVIDIA dodává své linuxové ovladače ve větvích s danými okny podpory. K polovině roku 2026:

R580 je v roce 2026 správná výchozí volba. Podporuje každé GPU z nabídky Kentino (5090, 4090, RTX Pro 6000 Blackwell v obou edicích, L40, L4) včetně výpočetní schopnosti sm_120 architektury Blackwell a přináší nativní podporu CUDA 13 — na kterou cílí každé nedávné vydání vLLM, PyTorch 2.10/2.11 i TensorRT-LLM. R570 je konzervativní volba LTSB, pokud máte flotilu karet Ada (4090 / L40 / L4), které nejnovější funkce nepotřebují, a chcete si o rok odložit přechod na jinou větev ovladače. R595 dodává Ubuntu 26.04 ve výchozím stavu a budete ho chtít pro úplně nejnovější hardware; na serveru, který provozuje jen to, co je dnes v nabídce Kentino, je R580 konzervativnější a stejně vybavený.

Trojitý tanec verzí ovladač / CUDA / PyTorch

Tři nezávislé verze do sebe musí zapadnout. Sedí na sobě takto:

PyTorch wheel (např. torch==2.11.0+cu130)
        │  obsahuje vlastní CUDA runtime, cuDNN a NCCL uvnitř wheelu
        ▼
Verze CUDA runtime (zde: 13.0)
        │  ovladač musí tuto verzi CUDA podporovat, nebo novější
        ▼
Větev ovladače NVIDIA (zde: R580 → podporuje CUDA 13.x)

Pravidlo zní, že ovladač podporuje maximální verzi CUDA runtime. Cokoli staršího než toto maximum v rámci stejné hlavní verze poběží. R580 (maximálně CUDA 13.x) tedy spustí wheely PyTorch sestavené proti 13.0, 13.1 i 13.2; nespustí wheely sestavené proti (hypotetické) CUDA 14.0, dokud nepřejdete na novější větev ovladače. Starší ovladače novější CUDA spustit nedokážou — u některých datacentrových karet existuje dopředná kompatibilita, ale je křehká a takhle systém provozovat nechcete.

Praktická mapa toho, co dnes běží na serverech Kentino:

Vaším úkolem je zafixovat ovladač a nechat všechno nad ním, ať se přizpůsobí. CUDA na hostitele vůbec instalovat nemusíte, pokud vše obsluhujete z kontejnerů (a měli byste — viz L02). Hostitel potřebuje ovladač a container toolkit. A to je vše.

Zamykání verzí — nejcennější příkaz v tomto článku

Jakmile je ovladač nainstalovaný a nvidia-smi je spokojený, zamkněte ho. Zamknutí znamená, že apt řeknete, aby konkrétní balíčky neaktualizoval, nedegradoval ani neodebíral, i kdyby se jich jinak dotkla závislost nebo bezpečnostní aktualizace. Příkaz zní apt-mark hold.

# Zamkněte větev ovladače.
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

# Zamkněte běžící jádro a jeho hlavičky — DKMS potřebuje k rebuildu obojí
# a skok jádra, který DKMS nezvládne, je přesně to, jak přijdete o GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# Pokud používáte metabalíček jádra HWE od Ubuntu, zamkněte i ten:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Ověření.
apt-mark showhold

Tím je vyřešena zhruba polovina všech hlášení „můj AI server přestal fungovat“. Když se spustí apt update && apt upgrade — ručně, z nástroje pro správu konfigurace nebo pod unattended-upgrades — zamknuté balíčky se nepohnou. Uvidíte je ve výpisu aktualizace pod „kept back“ a můžete je vědomě projít a odemknout v servisním okně, až budete připraveni.

Pár pastí. Lidé zamknou nvidia-driver-580 a zapomenou na cuda-drivers-580, což je skutečný metabalíček v repozitáři CUDA. Pokud se cuda-drivers-580 aktualizuje, protože tranzitivní závislost chce novější bodové vydání, stáhne s sebou nový nvidia-dkms-580 a o zámek jste přišli. Uvádějte oba. Lidé zamknou obraz jádra, ale ne hlavičky; jádro se přesto aktualizuje kvůli metabalíčku a DKMS při rebuildu hlavičky nenajde — nvidia-smi funguje až do restartu, pak už ne. Zamykejte vždy obraz i hlavičky společně.

Záludnosti jádra a DKMS

DKMS (Dynamic Kernel Module Support) je systém, který při každé změně jádra znovu sestaví moduly mimo strom jádra. Balíček NVIDIA nvidia-dkms-XXX registruje ovladač jako modul DKMS, takže teoreticky aktualizace jádra přes apt spustí čistý rebuild modulu a Vy nabootujete do funkčního systému.

V praxi rebuildy DKMS selhávají třemi opakujícími se způsoby:

Pro nové jádro nejsou nainstalované hlavičky — to je běžné, když se balíček jádra nainstaloval, ale balíček hlaviček odfiltroval pin v apt preferences nebo vlastní výběr. Nové jádro nabootuje, modul NVIDIA chybí a nvidia-smi vrací „NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.“

Nové jádro je pro danou větev ovladače příliš nové. R570 se proti nejnovějšímu jádru 6.14 čistě nesestaví; R580 ano. Pokud necháte skok HWE přenést systém na jádro, proti kterému se větev ovladače nikdy netestovala, DKMS vypíše chybu sestavení do /var/lib/dkms/nvidia/.../make.log a Vy nabootujete do funkčního systému bez GPU.

Secure Boot je zapnutý a znovu sestavený modul není podepsaný. Balíčky nainstalované přes ubuntu-drivers od Canonicalu mají podepisování vyřešené. Balíčky z repozitáře CUDA od NVIDIA ne; vyžadují, abyste zaregistrovali Machine Owner Key (MOK) a při každé změně jádra znovu sestavené moduly podepsali. DKMS umí podepisovat automaticky se správnou konfigurací pro daný modul, ale musí se to nastavit před prvním rebuildem, ne až když systém nenabootuje. Pokud Secure Boot nepotřebujete — a na bezhlavém inferenčním serveru v zamčeném racku ho nejspíš nepotřebujete — vypněte ho ve firmwaru ještě před instalací ovladače a celou tuto třídu problémů přeskočte.

Zamknutí jádra obchází všechny tři. Jádro se bez Vašeho přičinění nezmění, hlavičky zůstanou spárované a znovu sestavený modul se dál načítá. Až budete chtít nové jádro skutečně nasadit — kvůli CVE nebo reálné funkci — uděláte to vědomě, se snapshotem a připraveni vrátit se zpět.

CUDA na holém železe — kdy (vzácně) je to pořád správně

L02 vysvětluje, že CUDA na holém železe je dnes většinou špatná volba: kontejnery skryjí tanec verzí CUDA, oddělí hostitele od workloadu a jejich výkonová režie je zanedbatelná. Pro zhruba 95 % instalací to platí.

Výjimky jsou úzké. Profilování GPU na úrovni jádra pomocí Nsight Systems / Nsight Compute, kde vrstva kontejneru skryje právě ta systémová volání, která Vás zajímají. Práce na ovladači — provoz předběžných ovladačů od NVIDIA, ladění pádů, které se týkají samotného jaderného modulu. Striktně oddělená prostředí, kde je stahování a důvěřování obrazům OCI složitější než udržování zmrazeného zrcadla apt. A hrstka HPC pracovišť, která si všechno postavila kolem module load a MPI na holém železe a nemají zájem to měnit.

Pro všechny ostatní: nainstalujte ovladač na holé železo, hostitele nechte bez CUDA a CUDA provozujte uvnitř kontejnerů. nvidia-container-toolkit (popsaný v L02) obojí čistě propojí.

Bezobslužné aktualizace — co povolit a co blokovat

Balíček unattended-upgrades od Ubuntu je dobrý a měli byste ho nechat zapnutý. Úplně vynechat bezpečnostní aktualizace na serveru připojeném k síti je horší než riziko, že se automatická aktualizace pokazí. Správný vzorec zní: bezpečnostní aktualizace ano, jádro a balíčky NVIDIA ne.

Upravte /etc/apt/apt.conf.d/50unattended-upgrades a do bloku s blacklistem přidejte:

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

apt-mark hold už těmto balíčkům v aktualizaci brání. Blacklist je pojistka navíc — dělá záměr explicitním, zabrání unattended-upgrades i jen v zalogování pokusu a přežije neopatrné apt-mark unhold od juniorního administrátora. Používejte obojí.

Ověřte si to sledováním /var/log/unattended-upgrades/unattended-upgrades.log po dalším běhu. Měli byste vidět, že bezpečnostní balíčky procházejí a zamknuté či blacklistované se výslovně přeskakují.

Plán obnovy „udělal jsem dist-upgrade a teď nic nefunguje“

Někdo spustil apt full-upgrade (nebo to udělal Váš nástroj pro správu konfigurace) a po dalším restartu jsou GPU pryč. Pořadí kroků:

1. Nabootujte. Pokud systém nenabootuje, podržte shift / Esc u výzvy GRUB a vyberte v nabídce předchozí jádro. Ověřte, že nvidia-smi pod starým jádrem funguje. Pokud ano, problém je v novém jádře; zamkněte to staré (apt-mark hold linux-image-<old>) a pokračujte.
2. Pokud systém nabootoval, ale nvidia-smi hlásí nesoulad NVML, běží Vám nový uživatelský prostor proti staršímu načtenému modulu. Restartujte. Téměř vždy to pomůže.
3. Pokud nvidia-smi hlásí, že ovladač není načtený, zkontrolujte /var/lib/dkms/nvidia/<version>/build/make.log a dmesg | grep -i nvidia. Nejčastější příčiny: chybějící hlavičky jádra (apt install linux-headers-$(uname -r) a pak dkms autoinstall); jádro příliš nové pro ovladač (vědomě degradujte jádro nebo povyšte větev ovladače); Secure Boot odmítající nepodepsaný modul (mokutil --sb-state, pak buď vypněte SB, nebo zaregistrujte MOK).
4. Pokud se samotné balíčky ovladače dist-upgradem dostaly do stavu, který jste nechtěli — třeba metabalíček přetáhl R585 přes Váš zamknutý R580, protože někdo zámek odstranil — vyčistěte a přeinstalujte: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, pak zopakujte instalaci z repozitáře CUDA ve verzi, kterou skutečně chcete, a znovu nasaďte zámky.
5. Pokud máte snapshot — a měli byste, viz níže — obnovte ho. To je dvacet minut do známého funkčního stavu oproti čtyřem hodinám ladění.

Snapshot dřív, než sáhnete na ovladač nebo jádro

Ať máte úložiště uspořádané jakkoli, před každým zásahem do ovladače nebo jádra si udělejte snapshot. Uživatelé ZFS (/ na ZFS nebo samostatný dataset) to mají zdarma příkazem zfs snapshot rpool@pre-driver-upgrade-2026-05-15. Uživatelé LVM s thin pooly mohou použít lvcreate --snapshot. Uživatelé ext4 bez LVM jsou odkázáni na plné zálohy; i proto se rozvržení souborového systému věnujeme v L04.

Disciplína, která se vyplatí: nikdy nesahejte na ovladač, balíčky CUDA ani jádro, aniž byste si v předchozích pěti minutách udělali snapshot. Snapshot stojí vteřiny. Jeho absence, když se aktualizace pokazí, stojí půl dne výpadku a něčí večer.

Cesta aktualizací LTS

Aktualizace Ubuntu z LTS na LTS vycházejí jednou za dva roky; u AI serverů doporučujeme každou druhou vynechat. Cesta vypadá takto:

22.04  ──(vynechat mezivydání 23.x, vynechat 24.04, pokud je produkce stabilní)──▶  26.04
24.04  ──(vynechat mezivydání 25.x, vynechat 26.04, pokud je produkce stabilní)──▶  28.04

Důvod: aktualizace LTS na AI serveru je drahá (revalidace ovladače, přetestování obrazů kontejnerů, často i zopakování integračních benchmarků), přínos jednoho kroku oproti dvěma je malý a nástroje Ubuntu pro přechod mezi LTS přeskočení plně podporují. Naplánujte aktualizaci, domluvte servisní okno, udělejte snapshot, spusťte do-release-upgrade, týden systém zatěžujte a pak workloady vraťte zpět. Přechod 22.04 → 26.04 přímo je podporovaný a většina zákazníků Kentino ho nakonec provede na konci roku 2026 nebo v roce 2027.

Čemu se vyhnout: aktualizacím na místě uprostřed vývojového sprintu, aktualizaci bez snapshotu a aktualizaci se současným dist-upgradem celého stacku NVIDIA. Měňte vždy jen jednu věc.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.