Przypinanie Ubuntu i zarządzanie sterownikami NVIDIA w serwerach AI

Jeżeli odpowiadają Państwo za serwer AI, od którego zależą inni, najbardziej prawdopodobną przyczyną kolejnej awarii nie będzie usterka sprzętu, błąd modelu ani zdarzenie zasilania. Będzie nią apt-get upgrade, uruchomione w tle przez Państwa lub przez dystrybucję, które pociągnęło za sobą nowe jądro, względem którego moduł NVIDIA DKMS nie przebudował się czysto, przez co nvidia-smi zaczęło po kolejnym restarcie zwracać Failed to initialize NVML: Driver/library version mismatch. To zdecydowanie najczęstsze zgłoszenie do wsparcia Kentino po dwóch–trzech miesiącach pracy serwera.

Ten artykuł opisuje, jak do tego nie dopuścić. Omawiamy, którą wersję Ubuntu LTS wybrać w połowie 2026 roku, jak zainstalować sterownik NVIDIA w sposób, który da się później odtworzyć, jak przypiąć sterownik i jądro, aby nienadzorowana aktualizacja nie zniszczyła po cichu całego stosu, oraz jak się ratować, gdy ktoś już to zrobił.

Tekst adresujemy do każdego, kto będzie wpisywał sudo na maszynie z 4 lub 8 GPU, która ma działać bez przerwy przez lata.

Dlaczego w ogóle Ubuntu LTS

Istnieją technicznie sprawne dystrybucje Linuksa inne niż Ubuntu — Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Żadna z nich nie jest złym wyborem, a kilka jest wręcz lepiej zaprojektowanych. Mimo to do serwerów AI rekomendujemy Ubuntu LTS, z czterech powodów, które nie mają nic wspólnego z elegancją.

NVIDIA testuje w pierwszej kolejności pod Ubuntu LTS. Jej repozytoria apt udostępniają pakiety cuda-keyring przeznaczone wprost dla ubuntu2204, ubuntu2404 oraz (od wiosny 2026) ubuntu2604. Przewodnik instalacji sterownika wymienia Ubuntu LTS z numerem wersji; pozostałe dystrybucje trafiają na dalsze strony dokumentu.

Ekosystem kontenerów zakłada Ubuntu. Każdy obraz NGC (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) powstaje na bazie Ubuntu LTS. Dystrybucja hosta nie musi odpowiadać kontenerowi, ale gdy odpowiada, założenia jądra i przestrzeni użytkownika układają się bezkolizyjnie.

Większość zewnętrznych narzędzi AI zakłada Ubuntu już w pliku README. vLLM, llama.cpp, SGLang, instrukcje budowania FlashAttention, przykłady Hugging Face Accelerate — wszystko napisane i przetestowane najpierw pod Ubuntu. RHEL działa; to jednak Państwo będą zgłaszać błędy, gdy przestanie.

Grono osób, które zetknęły się z tym samym problemem wcześniej, jest największe na Ubuntu. Kiedy nvidia-smi zwraca bzdury o drugiej w nocy, trzy pierwsze trafienia na Stack Overflow będą dotyczyć Ubuntu. To liczy się bardziej, niż powinno.

Debian i RHEL nie są złym wyborem dla serwera AI. Mają jednak mniejszą powierzchnię testów, wolniejsze cykle walidacji po stronie NVIDII i mniejszą społeczność, gdy coś pójdzie nie tak. Jeżeli przemawia za nimi mocny powód organizacyjny — odizolowane środowisko FedRAMP, posiadana licencja RHEL, zespół administratorów pracujący na Debianie — proszę ich używać. W przeciwnym razie domyślnym wyborem pozostaje Ubuntu LTS.

22.04 vs 24.04 vs 26.04 w maju 2026

Trzy wydania LTS mają dziś aktywne wsparcie. Uczciwe zestawienie:

Kilka rzeczy wartych wyciągnięcia z tej tabeli.

22.04 wciąż ma największą bazę instalacyjną na świecie i to na nim potok walidacyjny NVIDII ma najdłuższą historię. Jeżeli działa u Państwa flota na 22.04, nie ma powodu do paniki i pośpiesznej migracji. Standardowe aktualizacje są zapewnione do kwietnia 2027, a Ubuntu Pro przedłuża wsparcie bezpieczeństwa do 2032, gdyby było potrzebne. Jeżeli jednak w połowie 2026 montują Państwo w szafie nowy serwer, wybierają Państwo system na najbliższe cztery–pięć lat. 22.04 ma przed sobą tylko rok standardowego wsparcia. Nie warto od niego zaczynać.

24.04 to złoty środek dla produkcyjnych zastosowań AI w 2026 roku. Ma za sobą dwa lata poprawek i rewizji jądra HWE, każda gałąź sterownika NVIDIA od R535 wzwyż doczekała się pakietów produkcyjnej jakości w repozytorium NVIDII ubuntu2404, każdy obraz NGC wskazuje 24.04 jako wspieraną bazę, a standardowe wsparcie kończy się dopiero w kwietniu 2029. To właśnie wdrażamy dziś na nowych konfiguracjach Kentino.

26.04 dopiero co się ukazało. Jako domyślny sterownik w oficjalnym repozytorium Ubuntu dostarcza R595, po raz pierwszy zawiera CUDA w repozytoriach głównych i przynosi dobre usprawnienia współpracy Wayland / NVIDIA, które mają znaczenie na desktopach i żadnego na bezgłowych serwerach inferencyjnych. Dla serwera AI ryzykiem jest moment: przez pierwsze trzy–cztery miesiące po wydaniu .0 LTS rekomendacje ubuntu-drivers i zachowanie modułów DKMS jeszcze się zmieniają, a własne repozytorium NVIDII potrzebuje kilku cykli, by w pełni zwalidować każdą gałąź sterownika względem nowego jądra. Z poprzednich wydań LTS (20.04, 22.04, 24.04) wynika, że dopiero pierwsze wydanie punktowe — 26.04.1 w sierpniu 2026 — otwiera sensowną drogę do wdrożeń produkcyjnych. Jeżeli można poczekać, warto poczekać. Jeżeli nie, prosimy przeprowadzić dwutygodniowy test wygrzewający, zanim trafi tam cokolwiek ważnego.

Ścieżki instalacji sterownika

Sterownik NVIDIA można zainstalować na Ubuntu na trzy sposoby. Nie są one równie dobre.

ubuntu-drivers install to droga najprostsza. Canonical utrzymuje narzędzie, które rozpoznaje sprzęt, wybiera gałąź sterownika uznaną za zalecaną i instaluje odpowiedni pakiet z archiwum Ubuntu. Samo obsługuje podpisywanie dla Secure Boot (kluczem Canonical), zna jądra HWE i na desktopie z jedną konsumencką kartą działa bez zarzutu. Na serwerze AI jest to droga krucha: zalecana gałąź potrafi zmienić się między wydaniami pakietu ubuntu-drivers-common, wersja otrzymana po apt update zależy od tego, co Ubuntu spakowało w danym tygodniu, a kontrola nad tym, która dokładnie wersja pomocnicza sterownika leży na dysku, jest mniejsza. Nadaje się do laptopa. Nie na serwer.

apt z repozytorium CUDA firmy NVIDIA to droga ręczna, ale kontrolowana. Dodają Państwo pakiet cuda-keyring firmy NVIDIA, który konfiguruje właściwe źródło apt dla posiadanej wersji Ubuntu, a następnie instalują dokładnie te pakiety, które mają być zainstalowane — cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, bez niespodzianek. NVIDIA kontroluje pakiety, Państwo kontrolują wersję. To domyślne podejście Kentino.

Instalator .run z witryny developer.nvidia.com zapisuje pliki do /usr/local, samodzielnie zarządza przebudową modułów jądra i w ogóle nie integruje się z apt. Jest właściwym rozwiązaniem w dwóch wąskich przypadkach: zupełnie nowy sprzęt, dla którego potrzebna gałąź sterownika nie trafiła jeszcze do repozytorium apt, albo stacja robocza, na której sterownik jest aktywnie rozwijany lub debugowany. Poza tym jest rozwiązaniem błędnym. Będzie walczył z DKMS, nie zostanie objęty przez apt-mark hold i po cichu przestanie działać przy kolejnej aktualizacji jądra, bo ścieżka przebudowy staje się ręczna.

Konkretnie: na serwerze 24.04 ze świeżą instalacją domyślna sekwencja Kentino wygląda tak:

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

# Instalujemy dokładnie tę gałąź sterownika, której potrzebujemy — po numerze.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Po restarcie nvidia-smi powinno raportować sterownik 580.x oraz maksymalną wersję CUDA obsługiwaną przez sterownik (CUDA 13 dla R580). To cała instalacja. Warto zauważyć, czego tu nie ma: żadnego meta-pakietu cuda, żadnego cuda-toolkit-13-0 (potrzebnego wyłącznie przy kompilacji kodu CUDA na hoście — patrz L02), żadnego ubuntu-drivers. Wersja wybrana, wersja zainstalowana, wiadomo, co leży na dysku.

Gałęzie sterowników, które liczą się w 2026 roku

NVIDIA dostarcza sterowniki dla Linuksa w gałęziach o określonych oknach wsparcia. Stan na połowę 2026 roku:

R580 to właściwy wybór domyślny w 2026 roku. Obsługuje każde GPU z oferty Kentino (5090, 4090, RTX Pro 6000 Blackwell w obu edycjach, L40, L4), w tym zdolność obliczeniową sm_120 architektury Blackwell, i przynosi natywne wsparcie CUDA 13 — a to właśnie cel każdego świeżego wydania vLLM, PyTorch 2.10/2.11 i TensorRT-LLM. R570 to zachowawczy wybór LTSB dla floty Ada (4090 / L40 / L4), która nie potrzebuje najnowszych funkcji, a przejście między gałęziami sterownika można odłożyć o kolejny rok. R595 jest domyślne w Ubuntu 26.04 i to ono sprawdzi się przy najnowszym sprzęcie; na serwerze, który pracuje wyłącznie na obecnej ofercie Kentino, R580 jest bardziej zachowawcze i równie bogate w funkcje.

Taniec trzech wersji: sterownik / CUDA / PyTorch

Trzy niezależne wersje muszą do siebie pasować. Układają się jedna na drugiej tak:

Wheel PyTorch (np. torch==2.11.0+cu130)
        │  zawiera własny runtime CUDA, cuDNN i NCCL w środku wheela
        ▼
Wersja runtime CUDA (tutaj: 13.0)
        │  sterownik musi obsługiwać tę wersję CUDA lub nowszą
        ▼
Gałąź sterownika NVIDIA (tutaj: R580 → obsługuje CUDA 13.x)

Zasada jest taka, że sterownik obsługuje maksymalną wersję runtime CUDA. Wszystko starsze od tego maksimum, w obrębie tej samej wersji głównej, zadziała. R580 (maks. CUDA 13.x) uruchomi więc wheele PyTorch zbudowane pod 13.0, 13.1 i 13.2; nie uruchomi wheeli zbudowanych pod (hipotetyczne) CUDA 14.0, dopóki gałąź sterownika nie zostanie podniesiona. Starsze sterowniki nie obsłużą nowszego CUDA — dla części kart datacenter istnieje zgodność w przód, ale jest krucha i nie na niej warto opierać pracę.

Praktyczna mapa tego, na czym pracują dziś serwery Kentino:

Zadaniem administratora jest ustalić sterownik i pozwolić, by wszystko powyżej za nim podążyło. CUDA nie trzeba w ogóle instalować na hoście, jeżeli wszystko serwowane jest z kontenerów (a tak właśnie powinno być — patrz L02). Host potrzebuje sterownika i container toolkitu. Tyle.

Przypinanie — najcenniejsze polecenie w tym artykule

Gdy sterownik jest już zainstalowany, a nvidia-smi nie zgłasza problemów, należy go przypiąć. Przypięcie to polecenie dla apt, by nie aktualizował, nie cofał ani nie usuwał wskazanych pakietów, nawet gdyby zażądała tego zależność lub aktualizacja bezpieczeństwa. Służy do tego apt-mark hold.

# Przypięcie gałęzi sterownika.
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

# Przypięcie działającego jądra i jego nagłówków — DKMS potrzebuje obu do przebudowy,
# a skok wersji jądra, którego DKMS nie obsłuży, to prosta droga do utraty GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# Przy meta-pakiecie jądra HWE Ubuntu przypinamy także jego:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Weryfikacja.
apt-mark showhold

To rozwiązuje mniej więcej połowę zgłoszeń „serwer AI przestał działać”. Gdy apt update && apt upgrade zostanie uruchomione — ręcznie, z narzędzia zarządzania konfiguracją albo w ramach unattended-upgrades — przypięte pakiety nie drgną. Pojawią się na liście „wstrzymane” w wyniku aktualizacji i można je świadomie przejrzeć oraz odpiąć w oknie serwisowym, gdy przyjdzie na to pora.

Kilka pułapek. Zdarza się przypiąć nvidia-driver-580 i zapomnieć o cuda-drivers-580, który jest właściwym meta-pakietem w repozytorium CUDA. Jeżeli cuda-drivers-580 zaktualizuje się, bo zależność przechodnia zażąda nowszego wydania punktowego, pociągnie za sobą nowy nvidia-dkms-580, a przypięcie przepada. Należy wymienić oba. Zdarza się też przypiąć obraz jądra bez nagłówków — jądro i tak się aktualizuje przez meta-pakiet, a DKMS nie znajduje nagłówków przy próbie przebudowy; nvidia-smi działa do restartu, a potem już nie. Obraz i nagłówki zawsze przypinamy razem.

Pułapki jądra i DKMS

DKMS (Dynamic Kernel Module Support) to mechanizm, który przebudowuje moduły jądra spoza drzewa przy każdej zmianie jądra. Pakiet NVIDII nvidia-dkms-XXX rejestruje sterownik jako moduł DKMS, dzięki czemu — w teorii — aktualizacja jądra zarządzana przez apt wyzwala czystą przebudowę modułu, a po restarcie system działa.

W praktyce przebudowy DKMS zawodzą na trzy powtarzalne sposoby:

Nagłówki jądra nie są zainstalowane dla nowego jądra — częste, gdy pakiet jądra został zainstalowany, a pakiet nagłówków odfiltrowało przypięcie w preferencjach apt lub ręczny wybór. Nowe jądro startuje, modułu NVIDIA brak, a nvidia-smi zwraca „NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver”.

Nowe jądro jest zbyt nowe dla danej gałęzi sterownika. R570 nie buduje się czysto względem najnowszego jądra 6.14; R580 tak. Jeżeli skok HWE przeniesie system na jądro, względem którego gałęzi nigdy nie testowano, DKMS zgłosi błąd budowania w /var/lib/dkms/nvidia/.../make.log, a po restarcie system działa, tyle że bez GPU.

Secure Boot jest włączony, a przebudowany moduł nie jest podpisany. Pakiety instalowane przez ubuntu-drivers Canonical mają podpisywanie załatwione. Pakiety z repozytorium CUDA firmy NVIDIA już nie; wymagają zarejestrowania klucza Machine Owner Key (MOK) i podpisywania przebudowanych modułów przy każdej zmianie jądra. DKMS potrafi podpisywać automatycznie przy odpowiedniej konfiguracji per moduł, ale trzeba to ustawić przed pierwszą przebudową, a nie po tym, jak system przestanie się uruchamiać. Jeżeli Secure Boot nie jest potrzebny — a na bezgłowym serwerze inferencyjnym w zamkniętej szafie raczej nie jest — warto wyłączyć go w firmware przed instalacją sterownika i pominąć całą tę klasę problemów.

Przypięcie jądra omija wszystkie trzy. Jądro nie zmienia się bez udziału administratora, nagłówki pozostają dopasowane, przebudowany moduł nadal się ładuje. A gdy nowe jądro rzeczywiście ma zostać wdrożone — z powodu CVE albo realnej funkcji — robi się to świadomie, ze snapshotem i gotowością do wycofania zmian.

CUDA na gołym systemie — kiedy (rzadko) wciąż ma sens

L02 uzasadnia, że CUDA na gołym systemie to dziś najczęściej zły wybór: kontenery ukrywają taniec wersji CUDA, odłączają hosta od obciążenia i kosztują pomijalnie mało wydajności. Dotyczy to około 95% instalacji.

Wyjątki są wąskie. Profilowanie GPU na poziomie jądra przy użyciu Nsight Systems / Nsight Compute, gdzie warstwa kontenera ukrywa istotne wywołania systemowe. Praca nad samym sterownikiem — uruchamianie wersji przedpremierowych od NVIDII, debugowanie awarii dotyczących modułu jądra. Ściśle odizolowane środowiska, w których pobieranie obrazów OCI i zaufanie do nich jest trudniejsze niż utrzymanie zamrożonego mirrora apt. Garstka ośrodków HPC, które zbudowały wszystko wokół module load i MPI na gołym systemie i nie zamierzają tego zmieniać.

Dla wszystkich pozostałych: sterownik instalujemy na gołym systemie, host zostawiamy bez CUDA, a CUDA uruchamiamy w kontenerach. Pakiet nvidia-container-toolkit (opisany w L02) czysto łączy oba światy.

Nienadzorowane aktualizacje — co dopuścić, a co zablokować

Pakiet unattended-upgrades w Ubuntu jest dobry i warto zostawić go włączonego. Całkowite pomijanie aktualizacji bezpieczeństwa na serwerze podłączonym do sieci jest gorsze niż ryzyko nieudanej aktualizacji automatycznej. Właściwy wzorzec brzmi: aktualizacje bezpieczeństwa tak, jądro i pakiety NVIDIA nie.

W pliku /etc/apt/apt.conf.d/50unattended-upgrades należy dopisać do bloku czarnej listy:

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

apt-mark hold już zapobiega aktualizacji tych pakietów. Czarna lista to pas i szelki — czyni intencję jawną, powstrzymuje unattended-upgrades nawet przed zalogowaniem próby i przetrwa nieuważne apt-mark unhold ze strony młodszego administratora. Warto stosować oba rozwiązania.

Potwierdzenie znajdą Państwo, śledząc /var/log/unattended-upgrades/unattended-upgrades.log po kolejnym przebiegu. Powinny przejść pakiety bezpieczeństwa, a te przypięte i wpisane na czarną listę zostać jawnie pominięte.

Scenariusz ratunkowy: „zrobiłem dist-upgrade i nic nie działa”

Ktoś uruchomił apt full-upgrade (albo zrobiło to narzędzie CM) i po kolejnym restarcie GPU zniknęły. Kolejność działań:

1. Uruchomienie systemu. Jeżeli system nie startuje, należy przytrzymać Shift / Esc przy GRUB-ie i wybrać poprzednie jądro z menu startowego. Następnie sprawdzić, czy nvidia-smi działa pod starym jądrem. Jeżeli tak, problemem jest nowe jądro; należy przypiąć stare (apt-mark hold linux-image-<old>) i kontynuować.
2. Jeżeli system wystartował, ale nvidia-smi zgłasza niezgodność NVML, nowa przestrzeń użytkownika pracuje ze starym załadowanym modułem. Restart. Prawie zawsze rozwiązuje sprawę.
3. Jeżeli nvidia-smi zgłasza, że sterownik nie jest załadowany, należy sprawdzić /var/lib/dkms/nvidia/<version>/build/make.log oraz dmesg | grep -i nvidia. Najczęstsze awarie: brakujące nagłówki jądra (apt install linux-headers-$(uname -r), a następnie dkms autoinstall); jądro zbyt nowe dla sterownika (świadome cofnięcie jądra albo podniesienie gałęzi sterownika); Secure Boot odrzucający niepodpisany moduł (mokutil --sb-state, a potem albo wyłączenie SB, albo rejestracja MOK).
4. Jeżeli same pakiety sterownika zostały podniesione do stanu niepożądanego — na przykład meta-pakiet wciągnął R585 na miejsce przypiętego R580, bo ktoś zdjął przypięcie — należy je wyczyścić i zainstalować ponownie: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, następnie powtórzyć instalację z repozytorium CUDA w pożądanej wersji i na końcu ponownie nałożyć przypięcia.
5. Jeżeli dostępny jest snapshot — a powinien być, patrz niżej — należy go przywrócić. To dwadzieścia minut powrotu do stanu znanego jako dobry zamiast czterech godzin debugowania.

Snapshot przed każdą zmianą sterownika lub jądra

Niezależnie od układu pamięci masowej, przed każdą operacją na sterowniku lub jądrze warto wykonać snapshot. Użytkownicy ZFS (/ na ZFS albo osobny dataset) dostają to za darmo poleceniem zfs snapshot rpool@pre-driver-upgrade-2026-05-15. Użytkownicy LVM z pulami thin mogą skorzystać z lvcreate --snapshot. Użytkownicy ext4 bez LVM skazani są na pełne kopie zapasowe; to jeden z powodów, dla których układ systemu plików omawiamy w L04.

Dyscyplina, która się opłaca: nigdy nie ruszać sterownika, pakietów CUDA ani jądra bez snapshotu wykonanego w ciągu poprzednich pięciu minut. Snapshot kosztuje sekundy. Jego brak, gdy aktualizacja pójdzie nie tak, kosztuje pół dnia przestoju i czyjś wieczór.

Ścieżka aktualizacji LTS

Aktualizacje Ubuntu z LTS na LTS pojawiają się co dwa lata; przy serwerach AI zalecamy pomijanie co drugiej. Ścieżka wygląda tak:

22.04  ──(pomijamy wydania 23.x, pomijamy 24.04 przy stabilnej produkcji)──▶  26.04
24.04  ──(pomijamy wydania 25.x, pomijamy 26.04 przy stabilnej produkcji)──▶  28.04

Uzasadnienie: koszt aktualizacji LTS na serwerze AI jest wysoki (ponowna walidacja sterownika, ponowne testy obrazów kontenerów, często powtórzenie benchmarków integracyjnych), korzyść z jednego kroku zamiast dwóch jest niewielka, a narzędzia Ubuntu w pełni wspierają przeskok. Należy zaplanować aktualizację, wyznaczyć okno serwisowe, wykonać snapshot, uruchomić do-release-upgrade, przez tydzień prowadzić test wygrzewający, a potem przenieść obciążenia z powrotem. Przejście 22.04 → 26.04 bezpośrednio jest wspierane i to właśnie zrobi większość klientów Kentino pod koniec 2026 lub w 2027 roku.

Czego unikać: aktualizacji w miejscu w trakcie sprintu deweloperskiego, aktualizacji bez snapshotu oraz aktualizacji połączonej z jednoczesnym podniesieniem całego stosu NVIDIA. Jedna zmiana naraz.

---

To część Kentino Wiki, serii referencyjnej o obliczeniach AI, robotyce i systemach, które je łączą. Uwagi i poprawki prosimy kierować na adres info@kentino.com.