Start / Poradniki / Rozwiązywanie problemów / Linux

nvidia-smi przestało działać po aktualizacji jądra

Linux

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

Który to przypadek?

Jeśli widziszPrzyczyną jestPrzejdź do
dkms status wypisuje moduł wyłącznie przy STARYM jądrzeDKMS nigdy nie zbudował modułu dla jądra, które właśnie uruchomiłeśRozwiązanie 2: zainstaluj pasujące nagłówki i przebuduj
dkms status nie pokazuje dla nvidii zupełnie nicSterownik zainstalowano bez DKMS, więc nie podąża za jądramiRozwiązanie 4: przeinstaluj sterownik z obsługą DKMS
modprobe nvidia mówi „Key was rejected by service”Secure Boot odmawia przyjęcia świeżo zbudowanego, niepodpisanego modułuTo inna strona — zobacz Secure Boot poniżej
Log budowania kończy się na brakującym nagłówku albo błędzie kompilatoraBrakuje nagłówków albo sterownik jest starszy niż to jądroRozwiązanie 3: przeczytaj make.log — poda powód
Potrzebujesz działającej maszyny natychmiastPoprzednie jądro wciąż ma sprawny modułRozwiązanie 1: uruchom stare jądro z menu GRUB-a

Kiedy się pojawia

Nic w twojej konfiguracji się nie zmieniło. Wykonałeś rutynową aktualizację, zrestartowałeś komputer i GPU po prostu już go nie ma — dokładnie ten sam błąd, jaki dostałbyś na maszynie bez żadnej karty NVIDIA.

Co się właściwie dzieje

Moduł jądra NVIDII nie jest przenośny między jądrami: kompiluje się go pod dokładnie to jądro, do którego ma zostać załadowany. Od tego jest DKMS — gdy instalowane jest nowe jądro, DKMS ma automatycznie przebudować dla niego każdy zarejestrowany moduł. Przebudowa potrzebuje pakietu linux-headers pasującego do tego konkretnego jądra, a gdy nagłówków brakuje, budowanie zawodzi. Zwykle zawodzi po cichu, w środku długiej transakcji apta, której wyjścia nikt nie czyta — więc pierwszym sygnałem kłopotów jest restart do jądra bez modułu NVIDII. lspci nadal wypisuje kartę, bo czyta magistralę PCI bezpośrednio; nvidia-smi zawodzi, bo rozmawia ze sterownikiem, który nie jest załadowany. Karta jest sprawna. Moduł dla tego jądra nie istnieje.

Jak to naprawić

1. Uruchom poprzednie jądro, żeby od razu wrócić do pracy

Zanim cokolwiek naprawisz, wiedz, że stare jądro wciąż ma sprawny moduł i dzieli cię od niego jeden restart. Przytrzymaj Shift (BIOS) albo naciśnij Esc (UEFI) podczas startu, żeby wejść do menu GRUB-a, wybierz Advanced options for … i wskaż poprzednią wersję jądra. To natychmiast przywraca GPU i zdejmuje presję czasu. Zrób tak, jeśli akurat coś liczysz albo ktoś czeka na maszynę — a potem wróć i napraw sprawę porządnie.

bash
# bash — which kernel am I on, and which are installed?
uname -r
ls /boot/vmlinuz-*
Czy zadziałało? uname -r pokazuje starszą wersję, a nvidia-smi znów wypisuje normalną tabelę. Pracujesz na pożyczonym czasie, nie na naprawionej maszynie.
uname -r && nvidia-smi

2. Zainstaluj pasujące nagłówki i przebuduj moduł

To właściwe rozwiązanie i zwykle mieści się w trzech poleceniach. dkms status mówi, dla których jąder moduł został zbudowany — jeśli twojego działającego jądra na tej liście nie ma, prawdopodobnym powodem są nagłówki. Zainstaluj nagłówki konkretnie dla działającego jądra, a nie ogólny metapakiet, a potem pozwól DKMS-owi zbudować wszystko, co zalega.

bash
# bash — Ubuntu / Debian
uname -r
dkms status
sudo apt install -y linux-headers-$(uname -r)
sudo dkms autoinstall
sudo modprobe nvidia

# Fedora
sudo dnf install -y kernel-devel-$(uname -r)
sudo akmods --force && sudo dracut --force

# Arch
sudo pacman -S --needed linux-headers
sudo dkms autoinstall
Czy zadziałało? dkms status wypisuje teraz moduł jako installed przy twoim działającym jądrze, a nvidia-smi pokazuje tabelę GPU. Zrestartuj raz, żeby potwierdzić, że to przetrwa.
dkms status
nvidia-smi --query-gpu=name,driver_version --format=csv

3. Przeczytaj log budowania DKMS — poda prawdziwy powód

Jeśli dkms autoinstall nadal zawodzi, log budowania mówi dlaczego, a prawie nikt tam nie zagląda. Leży w /var/lib/dkms/nvidia/<wersja>/build/make.log. Ostatnie dwadzieścia linii niesie właściwy błąd kompilatora, a dwa najczęstsze są jednoznaczne: brakująca ścieżka nagłówka znaczy, że z nagłówkami wciąż coś nie tak, natomiast błąd o nieznanym API jądra znaczy, że sterownik jest starszy niż jądro — i żadna przebudowa tego nie naprawi; potrzebujesz nowszego sterownika.

bash
# bash — find the log and read the end of it
ls -d /var/lib/dkms/nvidia/*/
sudo tail -n 30 /var/lib/dkms/nvidia/*/build/make.log

# Retry a single module verbosely once you have addressed the cause
sudo dkms install -m nvidia -v $(ls /var/lib/dkms/nvidia | head -1) -k $(uname -r) --verbose
Czy zadziałało? Instalacja w trybie szczegółowym kończy się linią „DKMS: install completed”, a nie błędem, a modinfo nvidia zgłasza wersję.
modinfo nvidia | head -3

4. Przeinstaluj sterownik z DKMS, jeśli nigdy nie został zarejestrowany

Jeśli dkms status nic dla nvidii nie wypisuje, sterownik zainstalowano bez DKMS — zwykle instalatorem .run od NVIDII bez flagi --dkms — i od teraz będzie się psuł przy każdej aktualizacji jądra, nie tylko przy tej. Przeinstalowanie z pakietów twojej dystrybucji oddaje stery DKMS-owi i kończy nawroty. Na Ubuntu ubuntu-drivers devices wskazuje zalecany pakiet dla twojej karty.

⚠️ Czyszczenie pakietów sterownika usuwa działający moduł i zrzuci maszynę z pulpitem do konsoli tekstowej, dopóki nowy sterownik nie zostanie zainstalowany i załadowany. Zrób to z TTY, a nie z terminala wewnątrz sesji graficznej, i miej plan na dokończenie bez interfejsu graficznego.

bash
# bash — Ubuntu: see what is recommended, then install it
ubuntu-drivers devices
sudo apt install -y nvidia-driver-580   # substitute the recommended version

# If a .run installer was used previously, remove it first:
sudo /usr/bin/nvidia-uninstall
Czy zadziałało? dkms status wypisuje nvidię przy twoim działającym jądrze. To właśnie ta rzecz sprawia, że przyszłe aktualizacje jądra przestają być wydarzeniem.
dkms status | grep -i nvidia

5. Zdecyduj, czy wstrzymać aktualizacje jądra — i uczciwie policz koszt

Na maszynie, od której zależysz, możesz przypiąć jądro, żeby to nie mogło się zdarzyć bez twojej wiedzy. Naprawdę działa i oznacza, że przestajesz dostawać poprawki bezpieczeństwa dla jądra, dopóki go nie odepniesz i nie zajmiesz się przebudową świadomie. To realny kompromis, a nie darmowy zysk. Środkową drogą, z której większość osób jest zadowolona, jest zostawić aktualizacje i po prostu zawsze restartować wtedy, gdy masz dziesięć minut — dzięki temu nieudaną przebudowę odkryjesz ty, a nie zadanie o trzeciej nad ranem.

⚠️ Przypięcie jądra zamraża jego poprawki bezpieczeństwa. Rób to tylko na maszynie, której ekspozycję rozumiesz, i ustaw sobie przypomnienie, żeby odpiąć je i zaktualizować świadomie.

bash
# bash — Ubuntu / Debian
sudo apt-mark hold linux-image-generic linux-headers-generic
apt-mark showhold

# Release it later
sudo apt-mark unhold linux-image-generic linux-headers-generic

6. W międzyczasie pracuj dalej na CPU z mniejszym modelem Najczęstsze rozwiązanie

Jeśli przebudowa trochę potrwa — aktualizacja sterownika, wpisanie klucza do Secure Boot, restart poza godzinami pracy — nie utknąłeś. Mały model w Q4 jest na nowoczesnym procesorze naprawdę używalny do czatu i lekkiej redakcji, w tempie kilku tokenów na sekundę zamiast kilkudziesięciu. Sprawdzenie, który rozmiar zostaje wygodny na twoim CPU, zajmuje dziesięć sekund i ratuje popołudnie.

bash
# bash — a 1-3B model runs acceptably on CPU while the GPU is out
ollama run gemma3:1b
ollama ps   # Processor column will read 100% CPU, as expected here
Sprawdź, co zmieści się na twoim sprzęcie — znajdź model, który zostaje używalny na CPU, dopóki sterownik nie wróci
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli moduł już się buduje, ale wciąż nie chce się załadować, jądro go odrzuca, a nie mu go brakuje — to Secure Boot i ma własną stronę. Jeśli nvidia-smi zawodzi, choć żadnej aktualizacji jądra nie było, właściwa jest strona o niezgodności wersji.

Dołącz to, zgłaszając problem

Powiązane

Model, który mieści się na większości zestawów:
Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego aktualizacja jądra psuje sterownik NVIDII?

Bo sterownik zawiera moduł jądra skompilowany pod jedno konkretne jądro. Nowe jądro wymaga przebudowania modułu, co DKMS zwykle robi automatycznie — ale przebudowa potrzebuje pasujących pakietów linux-headers i zawodzi po cichu, gdy ich brakuje.

lspci nadal pokazuje moje GPU. Czy to znaczy, że karta jest sprawna?

Tak. lspci czyta magistralę PCI bezpośrednio i nie potrzebuje sterownika, więc wypisze kartę tak czy inaczej. nvidia-smi rozmawia z załadowanym modułem jądra, więc zawodzi, gdy modułu nie ma. Rozbieżność między tymi dwoma wynikami to dokładnie ten problem.

Jak wrócić do pracy natychmiast?

Zrestartuj system do poprzedniego jądra z menu opcji zaawansowanych GRUB-a. Stare jądro wciąż ma zbudowany dla siebie sprawny moduł, więc GPU wraca od ręki. To prowizorka, nie naprawa — nowe jądro nadal nie ma modułu.

dkms autoinstall działa, a moduł i tak się nie ładuje. Co teraz?

Przeczytaj /var/lib/dkms/nvidia/*/build/make.log. Brakująca ścieżka nagłówka znaczy, że nagłówki wciąż są złe; błąd o nieznanym API jądra znaczy, że sterownik jest starszy niż jądro i wymaga aktualizacji. Jeśli budowanie się udało, a modprobe nadal odmawia, podejrzewaj Secure Boot.

Czy powstrzymać jądro przed aktualizacjami?

Tylko z otwartymi oczami. apt-mark hold zapobiega niespodziance, a zarazem wstrzymuje poprawki bezpieczeństwa jądra, dopóki go nie odepniesz. Na większości stacji roboczych lepszym nawykiem jest zostawić aktualizacje i restartować wtedy, gdy masz czas samodzielnie zauważyć nieudaną przebudowę.