Das Symptom
Der Grafiktreiber ist installiert, das Modul gebaut, alles sieht gut aus. Nur lädt es
nicht. Der Kernel sagt: Required key not available. Kein Bild, kein
3D-Beschleuniger, kein VirtualBox – und im Netz steht überall dieselbe Antwort: Secure
Boot abschalten.
Die „Layer 8“-Wahrheit
Secure Boot ist nicht kaputt und nicht im Weg. Es tut exakt das, wofür es gebaut wurde,
und Sie sind gerade der Fremde an der Tür.
Der Startvorgang eines Rechners ist die verwundbarste Phase, die es gibt: Bevor das
Betriebssystem läuft, kann es sich auch nicht verteidigen. Ein Schädling, der sich hier
einnistet, ist für jeden Virenscanner unsichtbar, weil er längst vor ihm da war. Secure
Boot schließt genau diese Lücke, indem die Firmware nur Code ausführt, der eine gültige
Signatur trägt. Das gilt auch für Kernel-Module – denn ein Modul läuft mit allen Rechten
im Kernel. Ein unsigniertes Modul durchzuwinken hieße, die Tür für alles zu öffnen, was
sich als Treiber ausgibt.
Ihr frisch kompilierter Nvidia-Treiber ist genau so ein unsigniertes Modul. Er ist
harmlos. Nur weiß die Firmware das nicht, und sie hat keine Möglichkeit, es zu erfahren.
Und hier kommt der eigentliche Layer-8-Moment: Die meistgeklickte Antwort im Netz lautet,
Secure Boot im BIOS abzuschalten. Das funktioniert sofort – und opfert dauerhaft einen
Schutz gegen eine Angriffsklasse, gegen die man sich sonst nicht wehren kann, um einmalig
einen Treiber zu laden. Die Alternative kostet eine halbe Stunde: einen eigenen Schlüssel
erzeugen, ihn einmal am Bildschirm bestätigen und die Module künftig selbst signieren.
Danach vertraut der Rechner Ihrem Treiber – und weiterhin sonst niemandem.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Die Meldung richtig lesen
Meldet der Kernel beim Laden eines Moduls 'Required key not available', ist das Modul nicht defekt und nicht inkompatibel. Es ist nur nicht signiert – und Secure Boot lässt ausschließlich signierte Module in den Kernel. Ein Blick in das Journal bestätigt es.
dmesg | grep -i 'key\|secure boot'
2.Prüfen, ob Secure Boot überhaupt aktiv ist
Dieser Befehl beantwortet die Frage eindeutig, statt sie zu vermuten. Steht dort SecureBoot enabled, ist die Ursache gefunden.
mokutil --sb-state
3.Einen eigenen Schlüssel erzeugen
Der saubere Weg ist nicht, den Schutz abzuschalten, sondern dem eigenen Modul zu vertrauen. Dazu wird ein Schlüsselpaar erstellt, mit dem Sie künftig selbst signieren.
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=Eigenes Modul-Zertifikat/" -nodes
4.Den Schlüssel zur Bestätigung anmelden
Der Schlüssel wird zur Aufnahme vorgemerkt und beim nächsten Start von Hand bestätigt. Genau diese Bestätigung am Bildschirm macht das Verfahren sicher: Sie kann nur ausführen, wer physisch am Rechner sitzt.
sudo mokutil --import MOK.der
5.Beim Neustart bestätigen
Nach dem Neustart erscheint ein blauer Verwaltungsdialog (MOK Manager). Dort Enroll MOK wählen, den Schlüssel bestätigen und das zuvor gesetzte Passwort eingeben. Wer diesen Bildschirm wegklickt oder durchstartet, findet den Schlüssel danach nicht im System – und der ganze Vorgang beginnt von vorn.
6.Die Signierung dauerhaft einrichten
Damit das Modul nach jedem Kernel-Update automatisch neu signiert wird, gehört der Schlüssel in die DKMS-Konfiguration. Ohne diesen Schritt funktioniert der Treiber genau bis zum nächsten Update – und dann steht man wieder hier.