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

Secure Boot blokuje moduł sterownika GPU

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

modprobe: ERROR: could not insert 'nvidia': Key was rejected by service

[  4.512901] Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
[  4.513002] nvidia: module verification failed: signature and/or required key missing - tainting kernel

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
`modprobe` zgłasza „Key was rejected by service”	Moduł jest niepodpisany, a Secure Boot go nie załaduje	Rozwiązanie 2: wpisz klucz Machine Owner Key
`mokutil --sb-state` wypisuje „SecureBoot enabled”	Potwierdza mechanizm — podpisywanie modułów jest egzekwowane	Rozwiązanie 1: jesteś we właściwym miejscu
Wpisałeś klucz i po restarcie nic się nie zmieniło	Niebieski ekran MOK Managera został przy starcie przeoczony albo wygasł	Rozwiązanie 3: zaimportuj ponownie i zostań przy maszynie
`dkms status` pokazuje moduł jako zbudowany i zainstalowany	Problemem nie jest budowanie, tylko ładowanie	Rozwiązanie 2, a nie strona o aktualizacji jądra
Podczas instalacji sterownika nie wygenerowano żadnego klucza MOK	Dystrybucja go nie utworzyła, więc nie ma czego wpisywać	Rozwiązanie 4: podpisz moduł ręcznie

Kiedy się pojawia

Ten przypadek jest zwodniczy, bo każdy krok raportuje sukces. Pakiet sterownika instaluje się czysto. DKMS buduje moduł dla twojego jądra i to potwierdza. A potem moduł nie chce się załadować, z błędem o kluczach brzmiącym tak, jakby coś było uszkodzone.

Zainstalowałeś sterownik NVIDII na maszynie, która przyszła z włączonym Secure Boot — dotyczy to większości laptopów i gotowych desktopów ze sklepu.
Sam włączyłeś Secure Boot, żeby uruchamiać obok Windowsa 11, i GPU przestało działać po stronie Linuksa.
dkms status pokazuje moduł zbudowany dla twojego działającego jądra, a nvidia-smi mimo to zawodzi.
Jesteś na Fedorze, gdzie Secure Boot jest domyślnie włączony na większości sprzętu.
Zbudowałeś moduł amdgpu-dkms spoza drzewa jądra i trafiłeś dokładnie na tę samą ścianę.

Co się właściwie dzieje

Przy włączonym UEFI Secure Boot jądro odmawia załadowania każdego modułu, który nie jest podpisany kluczem zaufanym przez firmware. Moduły dostarczane w samym jądrze podpisuje dystrybucja; modułu zbudowanego na twojej maszynie przez DKMS nie podpisuje nikt, dopóki nie zrobisz tego sam. Budowanie kończy się więc sukcesem — kompilacja nigdy nie była problemem — a ładowanie zawodzi. dmesg mówi to precyzyjnie: *module verification failed: signature and/or required key missing*. Mechanizmem, który to rozwiązuje, jest Machine Owner Key (MOK): generujesz klucz, wpisujesz go do magazynu zaufania firmware'u przez jednorazowe potwierdzenie przy starcie, a moduł zostaje nim podpisany. Dotyczy to tak samo budowanych spoza drzewa modułów amdgpu-dkms od AMD — dlatego ta strona jest oznaczona dla obu producentów.

Jak to naprawić

1. Potwierdź, że to naprawdę Secure Boot cię blokuje

Dwa polecenia oddzielają ten przypadek od wszystkich innych powodów, dla których moduł się nie ładuje. mokutil --sb-state mówi, czy Secure Boot jest w ogóle włączony, a dmesg będzie zawierał komunikat o nieudanej weryfikacji, jeśli to on jest przyczyną. Jeśli Secure Boot jest wyłączony, to nie ta strona — właściwa jest ta o aktualizacji jądra.

bash

# bash
mokutil --sb-state
dmesg | grep -iE 'lockdown|module verif|key was rejected'
dkms status

Czy zadziałało? SecureBoot enabled plus linia o nieudanej weryfikacji w dmesg potwierdzają diagnozę. Moduł, który DKMS zgłasza jako installed, a który mimo to się nie ładuje, to charakterystyczny podpis tego problemu.

2. Wpisz klucz Machine Owner Key — to rozwiązanie polecamy

Na Ubuntu i Debianie instalacja sterownika generuje klucz w /var/lib/shim-signed/mok/MOK.der i proponuje jego wpisanie. Jeśli pominąłeś ten monit, zaimportuj klucz teraz. mokutil --import poprosi cię o ustawienie hasła jednorazowego, o które zostaniesz zapytany przy następnym starcie — wybierz coś, co da się wpisać na układzie klawiatury US, bo ekran MOK Managera nie korzysta z twojego skonfigurowanego układu.

bash

# bash — Ubuntu / Debian
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
# set a one-time password when prompted, then:
sudo reboot

Czy zadziałało? Po zakończeniu wpisywania przy starcie klucz figuruje jako wpisany, a moduł się ładuje.

mokutil --list-enrolled | grep -i -A2 "Subject:"
sudo modprobe nvidia && nvidia-smi

3. Dokończ wpisywanie przy starcie — krok, który wszyscy pomijają

Przy następnym starcie, przed bootloaderem, pojawia się niebieski ekran MOK Managera. Wybierz Enroll MOK → Continue → Yes, wpisz ustawione hasło jednorazowe, a potem Reboot. Ten ekran pojawia się wyłącznie przy starcie i wygasa, a jeśli go przegapisz — odszedłeś od komputera, maszyna nie ma monitora, uznałeś to za zwykłe opóźnienie rozruchu — wpis zostaje po cichu odrzucony i wracasz do punktu wyjścia, bez żadnego błędu, który by to wyjaśnił. Jeśli przegapiłeś, po prostu uruchom mokutil --import jeszcze raz i zostań przy maszynie.

⚠️ Maszyna bez monitora albo obsługiwana zdalnie nie zaliczy tego kroku: MOK Manager wymaga fizycznej konsoli i klawiatury. Zanim zaczniesz na serwerze, zaplanuj monitor, IPMI albo przełącznik KVM.

bash

# bash — after the reboot, did it take?
mokutil --list-enrolled | grep -ci "subject"
sudo modprobe nvidia
nvidia-smi

Czy zadziałało? modprobe nvidia kończy się bez żadnego komunikatu — cisza oznacza sukces — a nvidia-smi wypisuje tabelę GPU.

nvidia-smi --query-gpu=name,driver_version --format=csv

4. Podpisz moduł ręcznie, gdy żaden klucz MOK nie powstał

Część dystrybucji i część ścieżek instalacji nigdy nie tworzy klucza. Wygeneruj go, wpisz jak w rozwiązaniu 2 i podpisz zbudowany moduł narzędziem sign-file z jądra. Musisz podpisywać ponownie po każdej przebudowie DKMS — czyli po każdej aktualizacji jądra — chyba że skonfigurujesz DKMS do automatycznego podpisywania, co jest trwałą wersją tego rozwiązania. Na Fedorze koncepcja jest identyczna, tylko przez jej mechanizm podpisywania akmods z kmodsign.

⚠️ Trzymaj MOK.priv czytelny wyłącznie dla roota. Każdy, kto odczyta ten klucz prywatny, może podpisać moduł jądra, któremu twoja maszyna następnie zaufa — a to dokładnie ta własność, której Secure Boot ma strzec.

bash

# bash — generate a key, then sign the built module
sudo openssl req -new -x509 -newkey rsa:2048 -nodes -days 36500 \
  -keyout /root/MOK.priv -outform DER -out /root/MOK.der \
  -subj "/CN=Local module signing/"
sudo chmod 600 /root/MOK.priv
sudo mokutil --import /root/MOK.der   # enrol at next boot, as in fix 2

# After the reboot, sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
  /root/MOK.priv /root/MOK.der \
  /lib/modules/$(uname -r)/updates/dkms/nvidia.ko

Czy zadziałało? Moduł ma teraz podpis i się ładuje. modinfo wypisuje sygnatariusza.

modinfo nvidia | grep -i sig
sudo modprobe nvidia && nvidia-smi

5. Wyłączenie Secure Boot — ostateczność, nie pierwszy krok

Możesz wyłączyć Secure Boot w ustawieniach firmware'u i moduł od razu się załaduje. Większość innych stron zaczyna właśnie od tego, a jest to najgorsza z dostępnych opcji: Secure Boot jest tym, co powstrzymuje bootkita przed przetrwaniem reinstalacji systemu, a wyłączenie go dla jednego sterownika trwale usuwa tę ochronę dla wszystkiego na maszynie. Psuje też BitLockera przy podwójnym rozruchu z Windowsem, który przy następnym starcie zażąda klucza odzyskiwania. Zamiast tego wpisz klucz — to pięć minut więcej, raz.

⚠️ To wyłącza weryfikację łańcucha rozruchu dla całej maszyny, a w systemie z podwójnym rozruchem wywoła monit odzyskiwania BitLockera po stronie Windowsa. Miej klucz odzyskiwania BitLockera pod ręką, zanim zmienisz to ustawienie.

bash

# bash — confirm the state after changing firmware settings
mokutil --sb-state

6. Zanim uporządkujesz podpisywanie, pracuj dalej Najczęstsze rozwiązanie

Wpisanie klucza wymaga restartu i fizycznego dostępu, których możesz teraz nie mieć. Wnioskowanie na CPU nadal działa — niezaładowany moduł kosztuje cię GPU, a nie maszynę — a mały model w Q4 jest w międzyczasie naprawdę używalny do czatu i lekkiej redakcji. Wybierz taki dopasowany do twojego procesora, zamiast ponawiać próby z modelem na GPU i wnioskować, że wszystko jest zepsute.

bash

# bash — usable on CPU while the module is unsigned
ollama run gemma3:1b
ollama ps

Sprawdź, co zmieści się na twoim sprzęcie — znajdź model, który zostaje używalny na CPU, dopóki moduł się nie załaduje
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli klucz jest wpisany, a moduł nadal odmawia, sprawdź, czy w ogóle został zbudowany dla jądra, które uruchomiłeś — problem z podpisem i problem z brakiem modułu dają różne linie w dmesg i mają różne strony. Czytelnicy z kartami AMD, którzy trafili na to przy amdgpu-dkms, powinni przejść tą samą ścieżką wpisania klucza, a potem wrócić do stron o ROCm.

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

Wynik mokutil --sb-state oraz mokutil --list-enrolled | grep -i subject
Linie z dmesg | grep -iE "lockdown|module verif"
dkms status oraz modinfo nvidia | grep -i sig
Twoja dystrybucja i informacja, czy maszyna ma podwójny rozruch z Windowsem i BitLockerem

Powiązane

Model, który mieści się na większości zestawów:

Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego sterownik buduje się poprawnie, a nie ładuje?

Bo budowanie i ładowanie to różne kroki o różnych wymaganiach. DKMS kompiluje moduł z powodzeniem; jądro odmawia potem jego załadowania, bo Secure Boot wymaga podpisu zaufanym kluczem, a moduł zbudowany lokalnie żadnego nie ma, dopóki go nie podpiszesz.

Czym jest Machine Owner Key?

To twój własny klucz podpisujący, wpisany do magazynu zaufania firmware'u przez jednorazowe potwierdzenie przy starcie. Po wpisaniu moduły nim podpisane ładują się normalnie pod Secure Boot. To przewidziany mechanizm dla sterowników budowanych lokalnie i nie osłabia łańcucha rozruchu.

Wpisałem klucz i nic się nie zmieniło. Co poszło nie tak?

Prawie na pewno niebieski ekran MOK Managera przy następnym starcie został przeoczony albo wygasł, co po cichu odrzuca wpis. Uruchom mokutil --import ponownie i zostań przy maszynie przez cały restart. Pamiętaj, że ten ekran przyjmuje hasło w układzie klawiatury US.

Czy muszę podpisywać ponownie po każdej aktualizacji jądra?

Jeśli podpisujesz ręcznie — tak: DKMS przebudowuje moduł dla każdego nowego jądra, a przebudowany moduł jest niepodpisany. Skonfigurowanie DKMS do automatycznego podpisywania twoim kluczem zdejmuje ten obowiązek. Konfiguracje MOK generowane przez dystrybucję zwykle załatwiają to za ciebie.

Czy zwykłe wyłączenie Secure Boot jest naprawdę aż tak złe?

To realne obniżenie ochrony: Secure Boot jest tym, co powstrzymuje bootkita przed przetrwaniem reinstalacji. Na maszynie z podwójnym rozruchem wywoła też monit odzyskiwania BitLockera po stronie Windowsa. Wpisanie klucza daje ten sam efekt i zajmuje jakieś pięć minut więcej.