Sommerrätsel mit secure-boot

Normalerweise hat man ein Problem, das man möglichst genau beschreibt, oder hat hat eines gelöst und teilt die Lösung der Community mit.

Kein direkter Anlass, sondern ein Chat mit @Noah.runggaldier , motivierte mich die Möglichkeit von Clonezilla alle lokale Betriebsysteme ausfindig zu machen und das gewünschte zu starten nach längerer Zeit wieder zu probieren. Früher half es mir öfters, dann funktionierte es nicht mehr und ich fand den Grund nicht.

Also die neueste Iso mit debian geholt, auf den Stick kopiert und bei meinem großen System mit mehreren Platten und Systemen ausprobiert.

Es kommen viele Meldungen auch Fehler, die ich nicht so schnell lesen kann, wie sie weg sind, und die Liste der verfügbaren efi-Systeme. Das 1. in der Liste ist clonezille selbst.

Ich starte ein System, funktioniert, ich probiere noch eines das dann Fehler meldet. Ich probiere sie alle durch und stelle fest: windows und manjaro starten, opensuse und debian bringen Fehlermeldungen, die ich fotografiere, weil sie kurz darauf verschwinden.

Wenn ich nach der Fehlermeldung suche, finde ich viele Ratschläge, die alle in diese Richtung gehen: secureboot abwählen oder gar csm auswählen.

Auf slimbook fand ich die genaueste Beschreibung. Leider ebenfalls secureboot abstellen.

Es wird aber noch verzwickter: den clonezillestick in einem anderen efisystem gesteckt, wird dort nicht als uefi-boot-device erkannt, während ein Stick mit fuss12 einwandfrei erkannt wird. Der clonezillastick in einem weiteren System mit fuss12 gesteckt, bootet, erkennt und startet debian. Alle 3 Systeme booten nur efi-systeme und haben secureboot enabled.

Fast vergessen zu erwähnen: das große System startet einwandfrei alle 4 Systeme über die Bios-Auswahl und mit Ausnahme vom alten opensuse zeigt grub2 in der Auswahl der anderen immer alle verfügbaren Systeme an und bootet sie auch, ohne dass der Fehler auftritt.

Das internet ist voll von Problemen mit diesen Fehlermeldungen. Als heise-Leser habe ich von der secure-boot-Problematik (Suchbegriff: linux secure boot probleme 2025 :url heise.de) gelesen, aber mich nicht weiter bemüht, weil ich für den seltenen Start von Windows durchaus das Bios ändern kann, wenn die Linuxe sonst ohne secureboot starten.

Sollten sich ein paar Freiwillige melden mit der Schwarmintelligenz dem Problem näher zu kommen, kann ich gerne in einem gesicherten Bereich (z.B: chatgruppe auf xmpp/omemo oder Matrix) mehr Daten meiner Systeme anbieten.

Hallo Franz,

Als erster Gedanke kommt mir im Sinn, dass vielleicht die EFI-Partition voll ist.
Windows erstellt meist bei der Erstinstallation nur eine 100MB Paritition, und vielleicht ist die nun mit all den Multiboot-Optionen voll.

Bei mir mit nur einen Debian Betriebsystem gibt mir der Befehl:
df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/nvme0n1p1 510M 5,9M 505M 2% /boot/efi
D.h der Bootloader vom installierten Debian verbraucht bei mir nur circa 6MB von der 500MB EFI-Partititon.

Oder es kann sein, dass bei Clonezilla die EFI-Partition nur als read-only (ro) gemountet wird!?
Bei mir im laufenden Debian-System wird diese als rw gemountet:
mount
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Bei den anderen Computer mit aktiven Secure Boot kann ich mir vorstellen, dass irgendwelche Bootloader-Schlüssel von dem Clonezilla-Medium vielleicht nicht akzeptiert werden, und eventuell vom UEFI in der Whitelist eingetragen werden müssen. Stichwort: Machine Owner Key Enrollment

Gruß Julian

Hallo Franz,
ich versuch mal meinen Wissensstand zum Rätsel hinzuzufügen.
Als ich nach den Fehlermeldungen gesucht habe, bin ich auch auf viele Forum Posts gestoßen, wo lediglich gesagt wurde, secure-boot zu deaktivieren.
Ich habe mich tiefer mit der Materie befasst und bin dann auf andere Antworten und Informationen gestoßen.

Die Fehlermeldung auf deinem Foto sagt, dass ein Volume voll ist. @j54n1n tippte als erstes auf die EFI-Partition. Diese könntest du kontrollieren. Des Weiteren hat er auch MOK’s also Machine Owner Keys angesprochen.

MOK’s werden im NVRAM gespeichert und dort ist wenig Platz. Meist weniger als 256 Kilobytes. Es könnte sein, dass der NVRAM voll ist. Mit dem Befehl mokutil (Link zur Ubuntu Manpage) kannst an MOK’s werkeln. Es gibt viele interessante Befehle mit mokutil.

Mit diesem Befehl mokutil --list-enrolled kannst du alle Keys sehen.

Willst du bestimmte Keys löschen, so musst du folgendes eingeben:
Mit mokutil --export kannst du die Keys exportieren, um deren Dateinamen zu erhalten.
Mit dem Dateinamen, z.B. MOK-0001.der kannst du den jeweiligen Key mit folgendem Befehl löschen: mokutil --delete MOK-0001.der.

Hier ein paar Links, welche ich sehr interessant fand oder hilfreich sind:

MfG,
Noah

danke @j54n1n , danke @Noah.runggaldier für euer Mitdenken!

Den einzigen sicheren Schluss, den ich ziehen konnte, war, dass es mit clonezilla zusammenhängt, weil

  • sonst alle 4 Systeme einwandfrei booten, sei es über eine Bios-Auswahl (F8) oder im Grubmenü der im Bios eingestellten 1 Bootquelle was mir erlaubt zwischen den grubs zu verzweigen. Nur opensuse ist so alt, dass ich kein grub-config aufrufe und im Grubmenü deshalb die aktuellen Systeme nicht vorhanden sind.
  • weil beim clonezillastick wahrscheinlich irgendwas nicht stimmt, da es an einem System nicht als Efi-Bootstick erkannt wird.
  • clonezilla hat beim Booten weder auf EFI noch auf NVRAM was anzulegen oder zu schreiben, selbst wenn der Platz zu klein für Erweiterungen wäre.

Woher kommt der Bezug zu secure-boot?

  • einmal über die Fehlermeldung und den Lösungsvorschlägen in den Foren.
  • weil ich viel über möglicherweise nicht mehr bootende Systeme gelesen habe.
  • weil ich ein völlig anderes Problem bei einem Laptop beobachtet habe, das damit zusammen hängen kann. Weil ich nur sporadisch Zugriff auf den Laptop habe, kommt ein Beitrag dazu, wenn ich genug Daten gesammelt habe.

Zu den Schlüsseln im NVRAM:

  • ich habe die Schlüssel mit Bios-Mitteln exportiert, die 4 Dateien sind zwischen knapp 1kB und kleiner 20 kB.
  • mokutil zeigt 7 Schlüssel in db an, 2 davon verfallen nächstes Jahr.
  • mokutil zeigt 2 Schlüssel in dbx an, allerdings nur mit einem sha256.
  • mokutil zeigt mir bei 2 Systemen an, dass secure-Bot nicht aktiv ist im Widerspruch zur Anzeige im Bios.
  • ich stochere fürchterlich im Nebel, weil ich die Doks dazu noch nicht gelesen/verstanden habe, danke @Noah.runggaldier .
  • mokutil bereits in fuss12 installiert, Dank an @paolo.dongilli
root@wsr-debian:/home/admin# mokutil --sb-state
SecureBoot disabled
root@wsr-debian:/home/admin# mokutil --db|grep "Not After"
            Not After : Dec 26 23:35:04 2031 GMT
            Not After : Dec 27 00:18:52 2031 GMT
            Not After : Jun 27 21:32:45 2026 GMT
            Not After : Oct 19 18:51:42 2026 GMT
            Not After : Jun 13 19:31:47 2038 GMT
            Not After : Jun 13 19:08:29 2035 GMT
root@wsr-debian:/home/admin# mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: *****************************
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            **********************
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Debian Secure Boot CA
        Validity
            Not Before: Aug 16 18:09:18 2016 GMT
            Not After : Aug  9 18:09:18 2046 GMT
        Subject: CN=Debian Secure Boot CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)