Secure Boot lehnt Bootloader oder Kernel-Abbild ab · Linux Fix Lab

Symptome und Geltungsbereich

Firmware oder shim zeigt vor Linuxstart eine Signatur-/Sicherheitsverletzung.
GRUB lehnt gewählten Kernel mit bad shim signature ab.

Betroffene Umgebung

UEFI Secure Boot mit Distributions-shim/GRUB oder signierter systemd-boot-/UKI-Kette. Dies unterscheidet sich von Modul-Signaturablehnung nach dem Start.

Erkennbare Meldungen (synthetische Beispiele)

error: bad shim signature.

Boot-Abbild-Vertrauenskette statt unbeteiligtes Kernelmodul prüfen; Zeile unterscheidet unsignierte, widerrufene und fehlerhafte Abbilder nicht.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Ein unsigniertes oder nicht vertrauenswürdiges Abbild kann signierte Boot-Komponente ersetzt haben.
Ein widerrufener älterer Lader oder inkonsistente Hersteller-/eigene Schlüsselkette kann trotz Signatur scheitern; signiert bedeutet nicht automatisch vertrauenswürdig.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Secure-Boot-Status aus funktionierender Installation oder Rettungssitzung mit shim-/MOK-Tool lesen; keine Schlüsseländerung.

mokutil --sb-state

Ergebnis einordnen: Aktiv bestätigt Erzwingungskontext dieser Sitzung. Abgelehntes Abbild und ablehnende Stufe müssen weiterhin aus Boot-Bildschirm bestimmt werden.

Prüfschritt 2

Pfad durch tatsächlich abgelehntes EFI-/UKI-Abbild ersetzen; sbverify aus sbsigntool listet Signaturen ohne Änderung.

sbverify --list /boot/efi/EFI/Linux/example.efi

Ergebnis einordnen: Eine Signatur kann vorhanden, aber nicht vertrauenswürdig oder widerrufen sein. Fehlen begründet Prüfung, ob unsigniertes Artefakt vorgesehenes Paketabbild ersetzte.

Nächste Schritte nach Befund

Unterstützte signierte Boot-Kette wiederherstellen

Ersetzte lokales unsigniertes Artefakt unterstützte Distributionskomponente, über vertrauenswürdiges Distributionsmedium wiederherstellen und passende signierte Lader-/Kernelpakete in verifizierte ESP neu installieren. Bestehenden vertrauenswürdigen Alternativ-Eintrag behalten.

Vorsicht: Firmware-PK-/KEK-/db-Schlüssel nicht löschen und widerrufene Lader nicht blind herabstufen. Verschlüsselungs-Wiederherstellungsdaten bei gemessenen Boot-Dateiänderungen bereithalten.

Wiederherstellung / Rücknahme: Erhaltenen aktuell vertrauenswürdigen Eintrag oder unterstütztes Rettungsmedium starten; widerrufenes altes Abbild kann als Rollback unbrauchbar sein.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Bewusst eigene Signaturkette abgleichen

Ist eigener Kernel/UKI beabsichtigt, mit bekanntem Schlüssel der zuständigen Lader-/Firmware-Stufe nach dokumentiertem Verfahren signieren. Gesamte Kette prüfen, statt unpassende Modulschlüssel zu registrieren.

Vorsicht: Vertrauensdatenbank jeder Stufe kennen und vertrauenswürdiges Rettungsabbild behalten. Vorhandene Signatur allein ist keine Ende-zu-Ende-Prüfung.

Wiederherstellung / Rücknahme: Bei nicht startfähiger neuer Kette erhaltenen signierten Distributionseintrag wählen und vorherige eigene Abbildkonfiguration zurückstellen.