Linux MX auf einem Win 11 Rechner - Falsche Shim Signatur

spinstone

Cadet 3rd Year
Registriert
Apr. 2008
Beiträge
46
Hallo,

ich habe MX installiert auf einer leeren Partition (erstellt mit gparted), für's ESP die vorhandene von Ubuntu erstellte Partition angegeben (ohne Formatierung). Nun fehlt aber die passende Shim Signatur und Grub meldet den üblichen Fehler. Bei neuen Ubuntu Versionen ist das alles kein Problem, da sie auf dieselbe zugreifen. Nun basieren MX und Ubuntu ja beide auf Debian, aber offenbar braucht MX eine eigene Signatur? Aber es kam keine Meldung dazu bei der Installation. Bei Ubuntu Mint gabs da mal die Frage bzgl. MOK, hier aber nix.

Was kann ich noch tun?

MfG
 
Wenn du ausschließlich Linux nutzt, mach doch einfach SecureBoot aus.
Ansonsten, ja. Erstelle eigene Schlüssel. Hier ist etwas für Debian.
 
Lasst bitte die Hinweise auf SecureBoot! Und wie kann ich bitte eine eigene Shim erstellen, wenn das BS gar nicht bootet?
 
spinstone schrieb:
Lasst bitte die Hinweise auf SecureBoot! Und wie kann ich bitte eine eigene Shim erstellen, wenn das BS gar nicht bootet?
Vielleicht solltest dir den Artikel doch einfach mal zu Gemüte führen. Shim ist nun mal Teil von SB und in dem Artikel steht alles wissenswerte drin.
spinstone schrieb:
Bei neuen Ubuntu Versionen ist das alles kein Problem, da sie auf dieselbe zugreifen.
Nein, weil Ubuntu das alles implementiert hat! MX vermutlich nicht und ist eh nur für sich selbst zuständig.


spinstone schrieb:
Nun basieren MX und Ubuntu ja beide auf Debian,
Irrelevant in dem Fall.
spinstone schrieb:
Bei Ubuntu Mint gabs da mal die Frage bzgl. MOK, hier aber nix.
Es gibt kein Ubuntu Mint!
 
  • Gefällt mir
Reaktionen: Lotsenbruder
Danke, aber nicht wirklich hilfreich.....
Ergänzung ()

@mo schrieb:
Vielleicht solltest dir den Artikel doch einfach mal zu Gemüte führen. Shim ist nun mal Teil von SB und in dem Artikel steht alles wissenswerte drin.

Nein, weil Ubuntu das alles implementiert hat! MX vermutlich nicht und ist eh nur für sich selbst zuständig.



Irrelevant in dem Fall.

Es gibt kein Ubuntu Mint!
Danke, aber nich twirklich hilfreich....
 
Ganz einfach: weil die SSD mit den Ubuntu's noch jede Menge leeren Platz hat und im Installationsprogramm von MX man nur vorhandene Partitionen überschreiben oder die ganze Platte putzen kann. Da liegt doch wohl Gparted näher als Windows. und ja, da wurde "nix nach Shimgedöns" gefragt - und genau das scheint das Problem zu sein.

An eine manuelle Installation von shimx64.efi für MX, wie im vorgeschlagenen Debian-Beitrag vglweise beschrieben, traue ich mich nicht ran. Und: nein - SecureBoot bleibt an! Aus vernunftigen Gründen, auch wenn das früher von vielen und auch von mir bei Win8 anders gesehen wurde. Ich habe auch keine Lust, das immer wieder zu wiederholen.

Und mal so BTW: Win 11 gibt es jetzt seit über 2 Jahren, SecureBoot seit über 10 Jahren, aber offenbar sind einige "Distributeure" nicht willens oder in der Lage, sowas wie zB. die von Ubuntu oa. im Installatiosprozess zu implementieren. Fühle mich irgendwie um fast 20 Jahre zurückversetzt... (etwas provokativ formuliert).
 
Meine Güte>: ich hatte schon Mint, da wurde nach MoK gefragt und dann lief das Ding. Und mit SB. Und wenn du bei der Installation SB abschaltest, warum sollte dann shimx64.efi auf dem PC landen?
 
Nach langem Googeln und Lesen bleibt eigentlich nur noch dieses Résumé:

- Linux MX hat kein Interesse mehr daran, eine Installation mit eingeschaltetem SB zu ermöglichen. Allerdings fehlen jegliche Hinweise bei der Installation. Das ist sehr bedauerlich.

- Der aktuelle (von 2015!) Eintrag im MX-Wiki: " Beachten Sie, dass MX-17 die erste Startoption ist (in dieser speziellen Installation) und dass Sie die Möglichkeit haben, in UEFI zu starten, jedoch mit Secure Boot OFF. Windows 10 startet weiterhin und funktioniert in diesem Modus, beschwert sich jedoch darüber, dass Secure Boot nicht ordnungsgemäß installiert ist. Wenn Sie möchten, können Sie die UEFI-Firmware-Einstellungen ganz einfach ändern, um mit Secure Boot ON zu starten. Sie müssen dies jedoch jedes Mal manuell ändern, wenn Sie Windows 10 starten möchten, wenn Sie Secure Boot wünschen. Wie viele andere Distributionen signiert MX-17 seinen Code nicht und unterstützt daher derzeit Secure Boot ON nicht."

- MS versucht alles um sich die Konkurrenz vom Halse zu schaffen, alles wie vor über 10 Jahren. Kooperation statt Konkurrenz wäre angebracht.

- Und die Meldung von heise (im Administrator-Beitrag) erschreckt mich und hält mich davon ab mit installiertem Win11 jemals einen Start ohne SB zu wagen; "Wenn man nach dem oben genannten Update Secure Boot abschaltet, kann das bei manchen PCs zu einem vollständigen Datenverlust unter Windows führen, sodass man am Ende ganz ohne funktionierendes Betriebssystem dasteht."

https://mxlinux.org/wiki/system/uefi/
https://forum.mxlinux.org/viewtopic.php?t=67022
https://administrator.de/knowledge/...urrenz-auch-vom-hals-schaffen-3844409870.html

BTW: Ich wollte MX auch deshalb installieren, weil es anscheinend gut mit dem OpenShot Video Editor klar kommt, so wie auch Win11. In den noch supporteten Ubuntu Versionen 22.04 und 23.04 hat der aktuelle Editor in der Vorschau keinen Ton, bei 23.10 wird es vollkommen abstrus, man kriegt den alten Editor mit Vorschau-Ton, aber der ist ziemlich buggy, ein Update scheitert an der nicht mehr untertützten Quelle.
 
So, ich habe nun mal das neue Fedora 39 installiert, mit eigener /boot Partition und eigener Efi-Partition /boot/efi. So wie im Installationsprozess vorgeschrieben. Fedora bringt die nötigen Shim-Signaturen auch gleich mit. Hat geklappt und das System läuft bis jetzt einwandfrei (sogar der Openshot Video Editor 3.1.1.) Sieht richtig gut aus.

Allerdings läßt sich das System nur über das UEFI im NVRAM starten. Allerdings kommt diese Fehlermeldung, die aber den weitern Bootvorgang dann aber nicht stört (Bild 1). s.a. hier im Forum https://forums.fedoraforum.org/show...ot-grub-core-How-to-fix&p=1876937#post1876937


Fedora legt auch ein eigenes GRUB Menü an, da führen allerdings alle anderen Einträge zu ähnlichen Meldungen (Bild 2 und 3, eins davon auch zum Win-Bootmanager).

Im GRUB Update von Ubuntu wird Fedora zwar aufgenommen, der Klick führt aber zu der gleichen Meldung bzgl. Shim wie bei MX.
 

Anhänge

  • PXL_20231127_142025667.MP.jpg
    PXL_20231127_142025667.MP.jpg
    272 KB · Aufrufe: 91
  • PXL_20231127_165207887.MP.jpg
    PXL_20231127_165207887.MP.jpg
    331,5 KB · Aufrufe: 101
  • PXL_20231127_165307785.MP.jpg
    PXL_20231127_165307785.MP.jpg
    326,7 KB · Aufrufe: 96
Fedora hat ein abgelaufenes Secure Boot Zertifikat, bei mir ist 2022 abgelaufen. Viele Informationen finde ich dazu nicht, in bugzilla kann ich den Fehlerbericht aufgrund von unzureichenden Rechten nicht lesen.

Siehe mal damit nach:
Code:
mokutil --list-enrolled
 
Ja stimmt. Der 1. Key ist abgelaufen, die beiden anderen nicht. Warum kriegen die Experten von Fedora das nicht hin, ist das 'ne Geldfrage? Dahinter steht doch das Red Hat Unternehmen immer noch. Und das ist nicht gerade klein. Ok...

... aber warum kann ich dann trotzdem Fedora 39 starten? Da muss doch irgendeiner der anderen Key's das ermöglichen (?).

BootRepair "entlarvt" übrigens MX Linux als ein Debian Derivat. In VBox kennt das System nicht mal den mokutil Befehl bzw. es gibt überhaupt keine Reaktion auf die Eingabe im Terminal. ??

BTW: Debian sieht auch gut aus und es kann auch AppImages laden (Openshot Video Editor in der 3.1.1 Version). Ubuntu 22.04 kann das auch noch, aber insb. 23.10 scheitert kläglich.
 
spinstone schrieb:
Ja stimmt. Der 1. Key ist abgelaufen, die beiden anderen nicht. Warum kriegen die Experten von Fedora das nicht hin, ist das 'ne Geldfrage? Dahinter steht doch das Red Hat Unternehmen immer noch. Und das ist nicht gerade klein. Ok...

Ich sehe nur den einen Schlüssel.

mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 7e:68:65:1d:52:68:5f:7b:f5:8e:a0:1d:78:4d:2f:90:d3:f4:0f:0a
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2574709492 (0x9976f2f4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Fedora Secure Boot CA
Validity
Not Before: Dec 7 16:25:54 2012 GMT
Not After : Dec 5 16:25:54 2022 GMT
Subject: CN=Fedora Secure Boot CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
....

Debian Bookworm und Ubuntu 23.10 haben einen nicht abgelaufenen Schlüssel.
 
Hier die beiden anderen Schlüssel der im System installierten Version von Fedora 39. Als Client bei VBox gibt es auch nur den ersten, der abgelaufen ist. Vllt. ist der 3. von Ubuntu ja sowas wie ein Ersatz?
 

Anhänge

  • PXL_20231128_132534073.MP.jpg
    PXL_20231128_132534073.MP.jpg
    925,9 KB · Aufrufe: 89
  • PXL_20231128_132514044.MP.jpg
    PXL_20231128_132514044.MP.jpg
    851,7 KB · Aufrufe: 95
  • PXL_20231128_132441538.MP.jpg
    PXL_20231128_132441538.MP.jpg
    762,9 KB · Aufrufe: 92
Zurück
Oben