Ubuntu Pinning a správa ovladačů NVIDIA pro servery s umělou inteligencí

Pokud jste zodpovědní za server s umělou inteligencí, na kterém závisí ostatní lidé, nejpravděpodobnější příčinou vašeho dalšího výpadku není selhání hardwaru, chyba modelu ani výpadek napájení. Je to apt-get upgrade že vy nebo vaše distribuce běžela na pozadí, která načetla nové jádro, proti kterému modul NVIDIA DKMS nedokázal čistě znovu sestavit a které zanechalo nvidia-smi návratu Failed to initialize NVML: Driver/library version mismatch při dalším restartu. To je nejčastější volání na podporu Kentina po dvou nebo třech měsících provozu serveru.

Tento článek pojednává o tom, jak tomu zabránit. Zabývá se tím, který Ubuntu LTS si vybrat v polovině roku 2026, jak nainstalovat ovladač NVIDIA způsobem, o kterém si můžete skutečně myslet, jak „připnout“ ovladač a jádro tak, aby bezobslužný upgrade nemohl potichu zničit váš stack, a jak provést obnovu, když to někdo stejně udělal.

Publikum je ten, kdo bude psát sudo na 4GPU nebo 8GPU boxu, který má fungovat 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é z nich jsou pravděpodobně lépe navržené. Pro servery s umělou inteligencí stále doporučujeme Ubuntu LTS, a to ze čtyř důvodů, které nemají nic společného s elegancí.

NVIDIA nejprve testuje proti Ubuntu LTS. Jejich apt úložišť lodí cuda-keyring balíčky explicitně pro ubuntu2204, ubuntu2404a (od jara 2026) ubuntu2604Průvodce instalací ovladače uvádí Ubuntu LTS podle čísla verze; další distribuce jsou uvedeny v zadní části dokumentu.

Ekosystém kontejnerů předpokládá Ubuntu. Každý obraz NGC (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) je postaven na bázi Ubuntu LTS. Distribuce hostitele nemusí odpovídat kontejneru, ale pokud ano, předpoklady jádra a uživatelského prostoru se jasně shodují.

Většina nástrojů pro umělou inteligenci od třetích stran ve svých souborech README předpokládá Ubuntu. vLLM, llama.cpp, SGLang, instrukce k sestavení FlashAttention, příklady Hugging Face Accelerate – to vše je nejprve napsáno a otestováno v Ubuntu. RHEL funguje; pokud nefunguje, budete to vy, kdo bude hlásit chyby.

Skupina lidí, kteří se s vaším problémem setkali již dříve, je na Ubuntu největší. Kdy nvidia-smi vrátí nesmysl v 02:00, první tři zásahy Stack Overflow budou specifické pro Ubuntu. Na tom záleží víc, než by mělo.

Debian a RHEL nejsou špatnou volbou pro server s umělou inteligencí. Nabízejí menší testovací plochy, pomalejší validační cykly NVIDIA a menší komunitu pro případ, že se něco pokazí. Pokud máte pro jeden z nich silný organizační důvod – oddělený FedRAMP, existující licenci RHEL na webu nebo tým správců systémů Debian shopu – použijte ho. Pokud ne, použijte výchozí Ubuntu LTS.

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

Tři LTS verze jsou dnes aktivně podporovány. The Honest Matrix:

Pár věcí, které stojí za to z té tabulky vytáhnout.

Verze 22.04 je stále největší instalovanou základnou na světě a je to oblast, v níž má validační proces NVIDIA nejvíce zkušeností. Pokud máte funkční flotilu serverů s verzí 22.04, nepropadejte panice a upgradujte. Je plně podporována do dubna 2027 se standardními aktualizacemi a Ubuntu Pro prodlužuje bezpečnostní údržbu do roku 2032, pokud ji potřebujete. Pokud ale v polovině roku 2026 instalujete nový server, vybíráte si operační systém na další čtyři až pět let. Verze 22.04 má zbývající pouze jeden rok standardní podpory. Nezačínejte tam.

Verze 24.04 je ideálním obdobím pro produkční práci s umělou inteligencí v roce 2026. Za sebou má dva roky oprav chyb a revizí jádra HWE, každá větev ovladačů NVIDIA od R535 dále obsahovala balíčky produkční kvality v produktech NVIDIA. ubuntu2404 V repozitáři každý obraz NGC uvádí jako podporovanou verzi 24.04 a máte čas do dubna 2029, než vyprší standardní podpora. Toto je to, co dnes nasazujeme na nových sestaveních Kentina.

Verze 26.04 je čerstvě vydána. Dodává R595 jako výchozí ovladač v oficiálním repozitáři Ubuntu, poprvé obsahuje CUDA v hlavních repozitářích a má dobrá vylepšení příběhu Wayland / NVIDIA, která jsou důležitá pro desktopy a vůbec ne pro servery s bezhlavou inferencí. Rizikem pro server s umělou inteligencí je načasování: v prvních třech až čtyřech měsících po .0 Vydání LTS, ubuntu-drivers Doporučení a chování modulů DKMS se neustále mění a repozitář NVIDIA potřebuje několik cyklů, aby plně ověřil každou větev ovladače vůči novému jádru. Vzor z minulých verzí LTS (20.04, 22.04, 24.04) je takový, že první bodové vydání — 26.04.1 v srpnu 2026 – tehdy začíná dávat smysl nasazení v produkčním prostředí. Pokud můžete počkat, počkejte. Pokud ne, spusťte dvoutýdenní test namáčení, než na něj nainstalujete cokoli důležitého.

Cesty instalace ovladače

Existují tři způsoby, jak nainstalovat ovladač NVIDIA na počítač s Ubuntu. Není to stejně dobré.

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. Zvládne za vás podepisování Secure Boot (pomocí klíče Canonicalu), zná jádra HWE a na desktopu s jednou spotřebitelskou GPU funguje dobře. Na serveru s umělou inteligencí je to cesta spíše křehká: doporučená větev se může mezi verzemi měnit. ubuntu-drivers-common balíček, verze, kterou dostanete apt update Záleží na tom, co Ubuntu tento týden zabalilo, a máte menší kontrolu nad tím, která vedlejší verze ovladače je na disku. Používejte ji pro notebook. Nepoužívejte ji pro server.

apt z repozitáře CUDA od NVIDIA je manuální, ale ovladatelná cesta. Přidáte grafické karty NVIDIA cuda-keyring balíček, který nastavuje správné apt zdrojový kód pro vaši verzi Ubuntu a poté nainstalujte přesně ty balíčky, které chcete – cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, žádná překvapení. NVIDIA kontroluje balení, vy kontrolujete verzi. Toto je výchozí nastavení Kentina.

Jedno .run Instalátor od developer.nvidia.com zapisuje soubory do /usr/local, spravuje si vlastní přestavby modulů jádra a neintegruje se s apt Vůbec. Je to správná odpověď ve dvou úzkých případech: zbrusu nový hardware, kde se potřebná větev ovladače nedostala do apt repozitář nebo pracovní stanici, kde aktivně vyvíjíte nebo ladíte ovladač. Jinak je to špatná odpověď. Bude bojovat s DKMS, nebude zachycen apt-mark holda při další aktualizaci jádra se tiše zhroutí, protože cesta k opětovnému sestavení je nyní ruční.

Konkrétně na serveru 24.04 s novou instalací je výchozí sekvence Kentina tato:

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

Po restartu, nvidia-smi by měl uvádět ovladač 580.x a maximální verzi CUDA, kterou ovladač podporuje (CUDA 13 pro R580). To je celá instalace. Všimněte si, co tam není: ne cuda meta-balíček, ne cuda-toolkit-13-0 (potřebné pouze v případě, že kompilujete kód CUDA na hostiteli — viz L02), Ne ubuntu-driversVybrali jste si verzi, nainstalovali jste ji a víte, co je na disku.

Důležité větve pro řízení v roce 2026

NVIDIA dodává ovladače pro Linux v pobočkách se specifickými podpůrnými obdobími. Od poloviny roku 2026:

R580 je v roce 2026 správnou výchozí volbou. Podporuje všechny grafické karty z řady Kentino (5090, 4090, RTX Pro 6000 Blackwell obě edice, L40, L4) včetně grafických karet s architekturou Blackwell. sm_120 výpočetní kapacitu a dodává nativní podporu CUDA 13 – což je cíl každé nedávné vydání vLLM, PyTorch 2.10/2.11 a TensorRT-LLM. R570 je konzervativní volbou LTSB, pokud máte flotilu Ada (4090 / L40 / L4), která nepotřebuje nejnovější funkce a chcete se na další rok vyhnout přechodu na větve ovladačů. R595 je to, co Ubuntu 26.04 standardně dodává a co chcete pro nejnovější hardware; na serveru, který běží pouze na tom, co je dnes v sestavě Kentino, je R580 konzervativnější a má stejně funkce.

Tanec tří verzí Řidiče / CUDA / PyTorchu

Tři nezávislé verze se musí seřadit. Jsou umístěny na sobě takto:

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)

Pravidlem je, že ovladač podporuje maximální běhovou verzi CUDA. Cokoli staršího než toto maximum, na stejné hlavní verzi, poběží. Takže R580 (max. CUDA 13.x) spouští kola PyTorch postavená na verzích 13.0, 13.1, 13.2; kola postavená na (hypotetické) CUDA 14.0 nespustí, dokud neupgradujete větev ovladače. Starší ovladače nemohou spustit novější CUDA – pro některé karty pro datová centra existuje dopředná kompatibilita, ale je křehká a není to způsob, jakým chcete fungovat.

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

Vaším úkolem je opravit ovladač a nechat vše nad ním fungovat. Pokud vše poskytujete z kontejnerů, nemusíte CUDA na hostitele vůbec instalovat (a měli byste – viz L02). Hostitel potřebuje ovladač a sadu nástrojů pro kontejner. To je vše.

Připnutí – nejužitečnější příkaz v tomto článku

Jakmile řidič nastoupí a nvidia-smi je šťastný, připněte si to. Připnout znamená říct to apt neupgradovat, downgradovat ani odstraňovat konkrétní balíčky, a to ani v případě, že by se jich závislost nebo aktualizace zabezpečení dotkla. Příkaz je 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

To je zhruba polovina každého vyřešeného hovoru typu „můj server s umělou inteligencí přestal fungovat“. Kdy apt update && apt upgrade spuštěny – ručně, z nástroje pro správu konfigurace nebo v části unattended-upgrades – tyto pozastavené balíčky nebudou přesunuty. Ve výstupu aktualizace je uvidíte uvedeny v části „pozastavené“ a můžete je záměrně zkontrolovat a pozastavení zrušit v okně údržby, až budete připraveni.

Pár pastí. Lidé drží nvidia-driver-580 a zapomenout cuda-drivers-580, což je skutečný metabalíček v repozitáři CUDA. Pokud cuda-drivers-580 upgrady, protože tranzitivní závislost chce novější bodovou verzi, stáhne si novou nvidia-dkms-580 s ním a ztratili jste PIN. Uveďte oba. Lidé mají obraz jádra, ale ne hlavičkové soubory, jádro se stejně aktualizuje kvůli metabalíčku a DKMS se při pokusu o obnovu nepodaří najít hlavičkové soubory — nvidia-smi Funguje do restartu, pak ne. Vždy držte obrázek a hlavičky pohromadě.

Problémy s jádrem a DKMS

DKMS (Dynamic Kernel Module Support) je systém, který znovu sestavuje moduly jádra mimo stromovou strukturu při každé změně jádra. NVIDIA nvidia-dkms-XXX Balíček registruje ovladač jako modul DKMS, takže teoreticky aktualizace jádra spravovaná pomocí apt spustí čistou obnovu modulu a vy restartujete systém do funkčního systému.

V praxi selhávají rekonstrukce DKMS třemi způsoby, které se opakují:

Pro nové jádro nejsou nainstalovány hlavičkové soubory jádra – což je běžné, když byl balíček jádra nainstalován, ale balíček hlavičkových souborů byl odfiltrován pomocí pinu nastavení apt nebo vlastního výběru. Nové jádro se spustí, chybí modul NVIDIA. nvidia-smi vrací chybu „NVIDIA-SMI selhala, protože nemohla komunikovat s ovladačem NVIDIA.“

Nové jádro je pro větev driver příliš nové. R570 se nebudou čistě kompilovat s nejnovějším jádrem 6.14; R580 ano. Pokud necháte HWE bump přejít na jádro, se kterým větev driver nebyla nikdy testována, DKMS vygeneruje chybu sestavení v /var/lib/dkms/nvidia/.../make.log a restartujete systém do funkčního, ale bez GPU.

Zabezpečené spouštění je povoleno a znovu sestavený modul je nepodepsaný. Canonical ubuntu-driversBalíčky s `-instalovaným` jsou dodávány s podporou podepisování od Canonicalu. Balíčky CUDA-repo od NVIDIA nikoli; vyžadují registraci klíče vlastníka počítače (MOK) a podepisování přestavěných modulů při každé změně jádra. DKMS může podepisování provádět automaticky se správnou konfigurací pro každý modul, ale musí být nastaveno před první přestavbou, nikoli po neúspěšném spuštění systému. Pokud nepotřebujete Secure Boot – a na serveru s headless inferencí v uzamčeném racku ho pravděpodobně nepotřebujete – před instalací ovladače jej ve firmwaru deaktivujte a celý tento problém přeskočte.

Připnutí jádra obchází všechny tři kroky. Jádro se nezmění bez vašeho přičinění, hlavičkové soubory zůstávají shodné a přestavěný modul se nadále načítá. Když chcete vzít nové jádro – pro CVE nebo skutečnou funkci – uděláte to záměrně, se snapshotem, připraveným k vrácení zpět.

CUDA na holém kovu — když (vzácně) je stále v pořádku

L02 tvrdí, že CUDA na holém kovu je v současnosti většinou špatnou volbou: kontejnery skrývají fungování verzí CUDA, oddělují hostitele od pracovní zátěže a zanedbatelně snižují výkon. To platí pro ~95 % instalací.

Výjimky jsou omezené. Profilování GPU na úrovni jádra pomocí Nsight Systems / Nsight Compute, kde kontejnerová vrstva skrývá systémová volání, na kterých vám záleží. Práce s ovladači – spouštění předběžných ovladačů od NVIDIA, ladění pádů, které se týkají samotného modulu jádra. Prostředí s pevně oddělenými mezerami, kde je stahování a důvěřování obrazům OCI těžší než udržování zamrzlého zrcadla apt. Hrstka HPC webů, které postavily vše kolem. module load a MPI na holém kovu a nemají zájem o změnu.

Pro všechny ostatní: nainstalujte ovladač na holé železo, nechte hostitelský server čistý od CUDA a spusťte CUDA uvnitř kontejnerů. nvidia-container-toolkit (zahrnuté v L02) čistě propojuje oba.

Neobsluhované aktualizace – co povolit a co blokovat

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

Změnit /etc/apt/apt.conf.d/50unattended-upgrades a přidat do bloku černé listiny:

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

apt-mark hold již brání aktualizaci těchto balíčků. Blacklist je striktní – explicitně vyjadřuje záměr, zastavuje unattended-upgrades od i pokusu o zaznamenání a přežije neopatrný apt-mark unhold od juniorního administrátora. Spusťte obojí.

Potvrďte sledováním /var/log/unattended-upgrades/unattended-upgrades.log po dalším spuštění. Měli byste vidět, jak procházejí bezpečnostní balíčky a jak se blokované / zakázané balíčky explicitně přeskakují.

Příručka pro obnovu „Provedl jsem upgrade distribuce a teď nic nefunguje“

Někdo utekl apt full-upgrade (nebo to udělal váš nástroj CM) a při dalším restartu jsou grafické karty pryč. Pořadí operací:

1. Spuštění. Pokud se systém nespustí, podržte klávesu Shift / Esc v příkazovém řádku GRUB a z nabídky spouštění vyberte předchozí jádro. Potvrďte. nvidia-smi funguje pod starým jádrem. Pokud ano, problém je v novém jádru; připněte staré (apt-mark hold linux-image-<old>) a pokračujte.
2. Pokud se systém spustil, ale nvidia-smi píše nesoulad NVML, spouštíte nový uživatelský prostor se starým načteným modulem. Restartujte. Téměř vždy to opraví.
3. If nvidia-smi píše, že ovladač není načten, zkontrolujte /var/lib/dkms/nvidia/<version>/build/make.log a dmesg | grep -i nvidiaNejčastější chyby: chybějící hlavičkové soubory jádra (apt install linux-headers-$(uname -r) pak dkms autoinstall); jádro příliš nové pro ovladač (úmyslné snížení verze jádra nebo upgrade větve ovladače); Secure Boot odmítá nepodepsaný modul (mokutil --sb-state, pak buď deaktivujte SB, nebo zaregistrujte MOK).
4. Pokud byly samotné balíčky ovladačů aktualizovány do stavu, který jste nechtěli – například metabalíček přetáhl R585 přes váš připnutý R580, protože někdo odstranil blokování – vymažte je a znovu nainstalujte: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, poté znovu proveďte instalaci z repozitáře CUDA ve verzi, kterou skutečně chcete, a poté znovu použijte blokování.
5. Pokud máte snímek systému – a měli byste, viz níže – obnovte ho. To je dvacet minut zpět do známého dobrého stavu oproti čtyřem hodinám ladění.

Snímek předtím, než se dotknete ovladače nebo jádra

Ať už je vaše rozvržení úložiště jakékoli, před jakoukoli operací s ovladačem nebo jádrem si pořiďte snímek. Uživatelé ZFS (/ na ZFS nebo samostatné datové sadě) získejte to zdarma s zfs snapshot rpool@pre-driver-upgrade-2026-05-15Uživatelé LVM s tenkými pooly mohou lvcreate --snapshotUživatelé ext4 bez LVM jsou vázáni na plné zálohy; to je jeden z důvodů, proč se v této části zabýváme rozložením souborového systému. L04.

Disciplína, která se vyplácí: nikdy se nedotýkejte ovladače, balíčků CUDA ani jádra, aniž byste v předchozích pěti minutách pořídili snímek. Snímek stojí jen několik sekund. Cena za jeho neprovedení při neúspěšném upgradu je půldenní prostoj a něčí večer.

Cesta k upgradu LTS

Aktualizace Ubuntu z LTS na LTS probíhají každé dva roky; u serverů s umělou inteligencí doporučujeme každý druhý rok vynechat. Postup je následující:

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

Zdůvodnění: náklady na upgrade LTS na serveru s umělou inteligencí jsou vysoké (opětovné ověření ovladačů, opětovné testování obrazu kontejneru, často opakované spuštění integračních benchmarků), výhoda jednoho kroku namísto dvou je malá a nástroje pro upgrade z LTS na LTS v Ubuntu plně podporují toto přeskočení. Naplánujte upgrade, naplánujte okno údržby, pořiďte snímek, spusťte. do-release-upgrade, provést týdenní testování a poté přesunout úlohy zpět. Přechod z verze 22.04 na verzi 26.04 je podporován a většina zákazníků Kentina ho nakonec udělá koncem roku 2026 nebo v roce 2027.

Čemu se vyhnout: upgradům na místě během vývojového sprintu, upgradu bez snapshotu, upgradu a následnému okamžitému dist-upgradu stacku NVIDIA. Měňte jednu věc najednou.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.