About jjz

Das Problem ist schließlich vollständig behoben. Nochmals vielen Dank für Ihre Mithilfe.   Um die mit sbkeysync durchgeführte BIOS-Bearbeitung rückgängig zu machen, habe ich Folgendes verwendet: flashrom (Lesen: flashrom -p internal -r filename.bin, Schreiben: flashrom -p internal -r filename.bin) einen Hex-Editor (GHex) zum Bearbeiten der BIOS-Datei. UEFITool, um einen Einblick in die BIOS-Datei zu erhalten (sehr hilfreich, aber nicht erforderlich) Um jedoch einen Backup-Plan zu haben, falls das BIOS nach dem Schreiben auf den BIOS-Chip doch noch vollständig unbrauchbar werden sollte, habe ich mich über die Möglichkeiten des Lesens und Schreibens des Chips mit einem CH341A Mini-Programmiergerät informiert. Der Medion MS-7728 v2.0 (BIOS v3.0) verfügt wie viele MSI-Motherboards über einen SPI-Header mit der Bezeichnung JSPI1, was mehr Möglichkeiten zur Wiederherstellung bietet, falls er vollständig beschädigt werden sollte. Die Möglichkeit, diesen SPI-Header zu verwenden, könnte auch für andere nützlich sein.   Abschnitt A beschreibt die Schritte, die ich zur Behebung des Problems durchgeführt habe. Abschnitt B beschreibt einen erforschten Backup-Plan zur Verwendung des SPI-Headers auf der Hauptplatine und eines CH341A-Mini-Programmiergeräts. Glücklicherweise war dieser Plan letztendlich nicht notwendig.   A. Medion MS-7728 v2.0 (BIOS v3.0) (CPU, GPU und RAM installiert) im Computergehäuse Lesen und Schreiben mit flashroms internen Programmiere Haftungsausschluss: Ich übernehme keine Verantwortung für Schäden oder sonstige Probleme.   Da es sich um einen Desktop-Rechner handelt, könnte flashrom -p internal verwendet werden. Bei Laptops, zumindest bei älteren Modellen, ist die Verwendung des internen Programmiergeräts gefährlich und daher dringend abzuraten [1].   Dies sind die Schritte, die ich durchgeführt habe:   Tastatur mit originalem PS/2-Anschluss (d. h. ohne Adapter) angeschlossen. Bootfähige Festplatte mit Kali Linux gestartet (wahrscheinlich auch andere Distributionen möglich). In meinem Fall kein bootfähiger USB-Stick, da die USB-Anschlüsse nicht mehr funktionierten. GRUB-Menü durch Drücken der Umschalttaste oder der Esc-Taste aufgerufen (beim Starten von Kali Linux wird dieses Menü automatisch angezeigt). Die „e“ gedrückt, um die Kernel-Boot-Parameter zu bearbeiten. Die Parameter „ro quiet splash“ ersetzt durch „iomem=relaxed nomodeset“. iomem=relaxed ermöglicht die Bearbeitung des BIOS-Chips. nomodeset aktiviert den abgesicherten Modus. Kali Linux durch Drücken von F10 gestartet. Tastatur und Maus an die beiden USB-Anschlüsse angeschlossen, die im abgesicherten Modus funktionierten. Ein Terminal geöffnet. BIOS-Chip gelesen: flashrom -p internal -c 'W25Q64BV/W25Q64CV/W25Q64FV' -r filename.bin Die aus dem BIOS-Chip gelesene Datei mit einem Hex-Editor wie GHex bearbeitet. Um einen Prüfsummenfehler zu vermeiden, habe ich die PK-Variable nicht aus den NVRAM-Variablen entfernt, sondern umbenannt und die Länge des Variablennamens unverändert gelassen, d. h. zwei Zeichen. BIOS-Chip geschrieben: flashrom -p internal -c 'W25Q64BV/W25Q64CV/W25Q64FV' -w filename.bin   B. Medion MS-7728 v2.0 (BIOS v3.0) (CPU, GPU und RAM installiert) im Computergehäuse, gelesen mit JSPI1-Header und CH341A-Miniprogrammierer (Schreiben nicht getestet)   Das Lesen des BIOS-Chips mit installierter CPU, GPU und RAM war erfolgreich. Die Pinbelegung des JSPI1-Headers auf einem MS-7728 v2.0 (BIOS v3.0)-Motherboard schien der von MSI verwendeten Pinbelegung zu entsprechen, zu finden unter [2] [3] [4]: VCC 3.3V | 1 | 2 | VCC 3.3V (nn) MISO | 3 | 4 | MOSI #CS | 5 | 6 | SCLK GND | 7 | 8 | GND (nn) #HOLD (nn) | 9 | 10 | NC (nn) nn = war in meinen Tests nicht erforderlich   Die Pinbelegung 25XX der SPI pins auf dem CH341A Mini-Programmierergerät. USB MOSI GND SCLK MISO 3VSB #CS | 0     Haftungsausschluss: Ich übernehme keine Verantwortung für Schäden oder sonstige Probleme.   Erforderlich: CH341A Mini-Programmiergerät und zugehörige ICs/Werkzeuge (die genauen Namen kenne ich nicht) Jumperkabel Weiblich-Weiblich mit einem Ende mit einem Abstand von 2,0 mm und dem anderen Ende mit einem Abstand von 2,54 mm (die Enden mit einem Abstand von 2,0 mm sind gepaart). Da sich der Rechner im Gehäuse befand, erwies sich eine Kabellänge von 10 cm als zu kurz. Mit 10 cm langen Jumperkabeln M-F 2,54 mm konnte das Problem gelöst werden. Es ist jedoch wahrscheinlich besser, Jumperkabel F-F (2,0 mm und 2,54 mm) mit einer Länge von 20 cm zu verwenden. Oder die Hauptplatine aus dem Gehäuse zu nehmen. Antistatisches Armband (nicht erforderlich, aber wahrscheinlich sinnvoll) Dies sind die Schritte, die ich durchgeführt habe: Stromversorgung vom Motherboard getrennt und Netzteilschalter auf „0” gestellt, die CMOS-Batterie entfernt Jumper von den mit J1 gekennzeichneten Pins entfernt. Diese Pins befinden sich in der Nähe des BIOS-Chips. Dies muss vor dem Auslesen des JSPI1-Headers erfolgen, da sonst der vom CH341A-Mini-Programmiergerät gelieferte Strom zu anderen Teilen des Motherboards als dem BIOS-Chip fließt. Das Ende des Überbrückungskabels mit zwei Löchern (Rastermaß 2,0 mm) auf den JSPI1-Header gesteckt und die beide Enden mit 2,54 mm auf den passenden CH341A-Pin gesteckt. Insgesamt müssen 6 Kabel angeschlossen werden: 1 VCC, 1 GND, MISO, MOSI, #CS, SCLK.   Den CH341A Mini-Programmierer in den USB 3-Anschluss eines Laptops gesteckt (oft blau oder mit SS=SuperSpeed gekennzeichnet). Er sollte auch in Anschlüssen mit niedrigeren USB-Versionen funktionieren. Stellen Sie sicher, dass die Jumper am CH341A Mini-Programmierer richtig eingestellt sind. Den Laptop gestartet. Mehrere Lesevorgänge durchgeführt und überprüft, dass mehrere Lesevorgänge konsistente Ergebnisse liefern. Unter Linux kann dies mit flashrom durchgeführt werden: Lesen: flashrom -p ch341a_spi -c 'W25Q64BV/W25Q64CV/W25Q64FV' -r filename.bin (Schreiben nicht durchgeführt: flashrom -p ch341a_spi -c 'W25Q64BV/W25Q64CV/W25Q64FV' -w filename.bin) Unter Windows scheint es andere Software zu geben, mit der ein CH341A-Mini-Programmiergerät betrieben werden kann.   Noch einmal, ich bin nicht verantwortlich für Schäden oder sonstige Probleme.   [1] https://www.flashrom.org/classic_cli_manpage.html > PROGRAMMER-SPECIFIC INFORMATION > internal programmer > laptops [2] https://www.manualslib.com/manual/360307/Msi-Ms-7346.html?page=33#manual [3] https://www.flashrom.org/user_docs/msi_jspi1.html [4] https://web.archive.org/web/20151211154756/http://e-shop.fccps.cz:80/download/adv/frr/spi/msi_spi.html [5] CH341A Mini Programmer Schematic and Drivers · One Transistor [6] https://www.reddit.com/r/ASRock/comments/1cz1bcz/comment/lweh44c/?force-legacy-sct=1, first post, first picture ... View more

@Major_ToM, Ist die BIOS-Version E7728MLN.30F wirklich in allen Archiven von Medion nicht verfügbar? Wenn ich einen neuen Thread starten soll, da ich Ihre Antwort bereits akzeptiert habe, lassen Sie es mich bitte wissen. Hintergrundinformationen: Der Computer kann nun mit derselben beschädigten BIOS-Datei unter Linux gestartet werden (1), allerdings bootet er langsam und nur zwei USB-Anschlüsse funktionieren (vor dem Start von Linux funktioniert kein USB-Anschluss). Das derzeit beschädigte BIOS kann mit flashrom gelesen werden. Ich kann auch eine zuvor gelesene BIOS-Datei zurück in das BIOS schreiben. Das beschädigte BIOS (Version 30F) scheint viel mehr NVRAM-Einträge zu haben als das mitgelieferte BIOS (Version 30G). Die NVRAM-Einträge der beschädigten BIOS-Datei enthalten beispielsweise die MAC-Adresse und die Seriennummer. Ich würde diese mit einem Hex-Editor in das mitgelieferte BIOS einfügen. Ich vermute jedoch, dass noch weitere NVRAM-Variablen eingefügt werden müssten. Daher wäre es viel einfacher, wenn die BIOS-Version 30F (vollständiger Name E7728MLN.30F) verfügbar wäre. Hinweis 1: Das Booten gelingt durch Anschließen einer Festplatte mit Linux und einer PS/2-Tastatur (eine klassische PS/2-Tastatur, keine USB-Tastatur mit Konverter, da diese nicht funktionierte). Rufen Sie das GRUB-Menü auf (durch Drücken der Esc-Taste), drücken Sie die Taste 'E', um die Boot-Optionen zu bearbeiten, fügen Sie die Kernel-Parameter 'iomem=relaxed nomodeset' hinzu und entfernen Sie die Kernel-Parameter „ro quiet splash“. 'iomem=relaxed', um das Lesen und Schreiben vom BIOS-Chip zu ermöglichen. 'nomodeset', um im abgesicherten Modus zu booten, da Linux sonst beim Booten hängen bleibt. ... View more

Vielen Dank noch! Es kann einige Zeit dauern, bevor ich einen Versuch starten werde. Weil ich zuerst versuchen möchte mit dem JSPI1-Header zu laden, und ich werde noch entscheiden, welches Gerät zu kaufen. ... View more

@daddle, danke für Ihre Antwort.   Die Festplatte mit Windows hat tatsächlich eine MBR-Partitionierung. Die Festplatte mit Linux hat aber eine GPT-Partitionierung, und damit bootet sie auch nicht mehr (und damit ist auch der Platform Key angemeldet).   Mit der ESC-Taste komme ich leider auch nicht ins BIOS, selbst wenn ich sie schon vor dem Einschalten gedrückt halte. Das gleiche gilt für die DEL-Taste. Da die Tastatur-LEDs nicht leuchten (sowohl über USB als auch über PS/2), habe ich den Eindruck, dass die Tastatur nicht mehr ausgelesen wird. An einem anderen Rechner funktioniert diese Tastatur noch.   Wenn ich Zeit habe, werde ich das Lösen der Grafikkarte weiter untersuchen. Ich hatte den Eindruck, dass eine Metallabdeckung auf der Rückseite schwer zu entfernen ist. Aber eigentlich hoffe ich, dass es eine Lösung gibt, bei der man die Grafikkarte nicht ausbauen muss, zumal ich mir das nach dieser Erfahrung noch weniger zutraue. ... View more

@daddle, danke für Ihre Antwort.   1.Der Rechner hatte eine MBR-Partitionstabelle. Ich nahm an, dass dies keinen Einfluss auf die BIOS-Optionen haben würde, aber da lag ich wohl falsch. Also habe ich in den letzten Tagen eine andere alte Festplatte gesäubert (die vorherige Datensicherung hat einige Zeit gedauert) und Ubuntu mit einer GPT-Partitionstabelle darauf installiert. Das BIOS-Menü enthält nun eine Boot-Option '[UEFI:Ubuntu]', die ich von nun an zum Booten verwende. In diesem Kommentar geht es um mokutil, ein Tool, das anscheinend nur für Linux verfügbar ist. Hoffentlich sind einige Leser dieser Seite damit vertraut. sudo mokutil --sb-state zeigt: SecureBoot disabled Platform is in Setup Mode Da das Verzeichnis /var/lib/shim-signed/mok/ keine Schlüssel enthielt, wurde mit dem folgenden Befehl ein neuer MOK-Schlüssel erzeugt: sudo update-secureboot-policy --new-key Mit mokutil habe ich Schlüssel eingeschrieben: sudo mokutil --import /var/lib/shim-signed/mok/MOK.der. Der MOKManager (blauer Bildschirm) erschien nach dem Neustart, und die Registrierung des MOK-Schlüssels war erfolgreich. Als nächstes habe ich ausgeführt: sudo mokutil --enable-validation Nach dem Neustart erscheint MOKManager erneut, diesmal mit der Option 'Change Secure Boot state'. Nachdem ich diese Option ausgewählt hatte, erschien die folgende Fehlermeldung: 'Failed to delete Secure Boot state'. Ich habe das Internet durchsucht, aber ich konnte das Problem nicht lösen. Die Installation des efivar package, grub-install mit dem Parameter --uefi-secure-boot und 'mokutil --set-verbosity true' brachten keine Lösung oder einen Hinweis. Obwohl die Ubuntu OEM-Installation ohnehin nicht der richtige Weg dafür zu sein scheint, bietet der Assistent auch keine Option zur Aktivierung von Secure Boot. Was außerdem auffällt, ist, dass sudo mokutil --pk nichts ausgibt. Könnte die Fehlermeldung 'Failed to delete Secure Boot state' durch fehlende Hardwareunterstützung verursacht werden?   2. Die ursprünglich verwendete Festplatte enthielt keine GPT-Partition. Wenn diese Festplatte wieder in den Rechner eingesetzt und mit einem Live-USB mit Ubuntu gebootet wird, gibt sudo parted -l 'Partition Table: msdos'. Wahrscheinlich wurde die Boot-Option deshalb nur '[UEFI]' genannt, ohne Namensangabe. Jetzt, mit einer GPT-Partition und Ubuntu, enthält das BIOS-Menü eine Boot-Option '[UEFI:Ubuntu]'.   3. Wenn ich mich richtig erinnere, ging der Bootvorgang bis zur nächsten Bootoption.   Übrigens, wenn Secure Boot in Ubuntu auf diese Weise gelingen würde, bin ich nicht sicher, ob ich den Kernel und die Kernelmodulpakete nach jedem Kernel-Update signieren müsste. ... View more

@daddle    Vielen Dank für Ihre Antwort. Inzwischen habe ich ein anderes Thema gefunden, das sich ebenfalls mit der Secure Boot-Unterstützung für MS-7728 beschäftigt: https://community.medion.com/t5/Desktop-PC-All-In-One/MS7728-2-0-CSM-und-Secure-Boot-Eintr%C3%A4ge-im-BIOS-nicht-vorhanden/td-p/89149. Das sieht nicht gut aus, trotz dieser weiteren Informationen. Der Computer läuft jetzt auf Windows 10, obwohl ursprünglich (Ende 2012) auf Windows 7. In BIOS-menü unter 'Boot' ist eine Bootoption [UEFI] verfügbar. Aber nicht Enable/Disable, wie ich es aus den BIOS-Menüs anderer Rechner gewohnt bin. Ich habe diese [UEFI] Boot-Option bei Boot Option #1 ausgewählt, aber ohne Erfolg. Unterhalb diesem Beitrag finden Sie Bilder der BIOS-Menü-Registerkarten Advanced, Boot und Security. 'UEFI' wird in den Menüs bereits erwähnt, so dass ein Firmware-Upgrade nicht aus einem klassischen BIOS ein UEFI machen muss. Ist es wirklich ausgeschlossen, dass nach einer Aktualisierung der Motherboard-Firmware Secure Boot unterstützt wird? Hat Medion eine Liste der Firmware-Versionen für ein bestimmtes Mainboard auf seiner Website, da die Verwendung einer externen Suchmaschine das Risiko erhöht, die neueste Version zu übersehen? ... View more