bei 2 Hardware Generationen gibt es diese Fehlermeldung und die separat für jede Hardware erstellten .qcow2 Images können zwar zurückgeschrieben werden, booten aber mit dem Fehler 0x0000225 Bluescreen.
Fujitsu Lifebook U7510
Hier gibt es eine Bootschleife. Wenn ich mit F12 ins Bootmenü gehe, dann kann ich „grub“ auswählen. Scheitert mit „Boot failed“. Wenn ich im BIOS den Eintrag „grub“ lösche(ja, das geht in diesem BIOS), dann gibt es den Bluescreen, weil Windows 10 nicht gebootet werden kann.
Lenovo ThinkBook 14s Yoga ITL
Hier kann ich keinen grub Eintrag löschen und das Gerät bootet direkt nach dem zurückspielen des Images in diesen Bluescreen.
Ich denke, daß grub irgendwie nicht mit dem BIOS dieser Geräte umgehen kann, bzw. nicht richtig geschrieben wird. Wie kann man so etwas debuggen?
Dummerweise sind das ausgerechnet die Lehrerdienstgeräte(Lenovo) und Homeschooling Notebooks für die Schüler(Fujitsu), welche ich doch gerne mit Linbo klonen würde, da diese öfter mal zurückgesetzt werden müssten.
Im Anhang das Linbo Log des Fujitsu Laptops. Ich wäre dankbar, wenn sich das jemand ansehen könnte und Rat weiß.
Wieso kann man hier im Forum keine .log/.txt Dateien hochladen? Bitte die Datei umbenennen in .log oder .txt home-pc03_linbo.docx (75,1 KB)
mittlerweile denke ich, daß es evtl. hier um ein Problem handelt, das sich in Linbo 4.0.5-0 eingeschlichen hat.
Es ist nämlich so, daß ich ein anderes Linbo Image hatte, welches ich am 29.12.21 erstellt hatte auf einem NVME Terra NUC. Dieses habe ich dann auf SATA Terra PC eingespielt und wieder zurück auf den NVME NUC. Hatte einwandfrei geklappt.
Mittlerweile hatte es ein oder zwei Linbo Updates gegeben. Wenn ich jetzt dieses Image wieder auf den Terra NUC einspiele, so gibt es denselben Fehler, wie bei Lenovo und Fujitsu.
Thomas, könntest Du mir bitte eine ältere Linbo Version vom 29.12.21 aus lmn71 zur Verfügung stellen, dann probiere ich das aus.
danke für den Link!
Ich habe jetzt mit Linbo 4.0.3 und 4.0.4 probiert - leider kein Erfolg.
Ich erstelle ein .qcow2 Image auf einem NVME PC. Anschließend partitioniere ich den Client wieder und klone das Image auf denselben PC wieder zurück - 0x0000225.
… ich weiß das nicht so genau, deswegen leg was ich sag nicht auf die Goldwage…
linbo schreibt beim Erstellen eines Images irgendwelche Bootinformationen von Windows in irgend ein File und legt es auf den server.
Spielst du das image zurück wird am Ende diese Info wieder reingesynct.
Bitte versuch mal folgendes:
nimm einen Client her von der betroffenen Gruppe der windows aus linbo heraus booten kann.
Dann ändere den Imagenamen auf dem server zu einem anderen
linuxmuster-import-devices danach schadet nichts.
Und dann erstellst du ein neues Image vom Cleint.
Danach testen wie vorher auch.
Nimm gleich die aktuelle testingversion von linbo.
Dann sollte es doch erst recht funktionieren, wenn ich das ganze an ein und demselben Client mache. Ist hier nicht so.
Du meinst mit „Imagenamen ändern“ den Namen der Hostgruppe ändern, denke ich, oder? Oder soll ich die Dateien unterhalb /srv/linbo/images/win10_21H2_s_home einzeln ändern?
Oder soll ich beim Hochladen des Images einen anderen Namen vergeben?
Es bleibt schwierig. Ich beginne neu und von vorne:
Ich partitioniere home-pc03 mit Linbo und einer start.conf.win10nvmeshome für UEFI64 und NVME
Installiere Windows auf der NVME Partition
Domänen Beitritt, Treiber, etc. Den PC kann ich anschließend mit dem Linbo Screen booten
Erstelle ein Image win1021H2homes.qcow2 und lade es hoch. Zuweisung reg Patch.
Dann ordne ich das Image der Gruppe zu
6a. Wenn ich den PC nun mit Neu aus dem Cache zurückspiele, dann bootet Windows anschließend
6b. Partitioniere home-pc03 mit Linbo
Spiele das Image win1021H2homes.qcow2 auf home-pc03 zurück
Bluescreen nach dem Neustart
Wenn neu partitioniert wird, geht es nicht.
Also keine unterschiedliche Hardware, derselbe PC. NVME.
Ein SATA Image kann ich kreuz und quer klonen, das läuft auf 4 Hardware Generationen - und lief bisher auch auf einem NVME PC. Jetzt, wie oben geschrieben, auch auf diesem NVME PC nicht mehr.
Ich bin einigermaßen ratlos.
Hier noch die Logs von diesen Vorgängen: home-pc03.zip (62,5 KB)
auf meiner Virtualbox Testumgebung kann ich das alles reproduzieren.
Bei NVME Clients sehe ich im UEFI Bootmenü nach dem zurückspielen des Images keinen Eintrag „Windows Boot Manager“. Dieser ist bei SATA UEFI Client mit demselben Image vorhanden.
Da stimmt also etwas nicht.
@thomas
Hast Du da eine Idee, bzw. gab es Änderungen bzgl. NVME und Linbo/Grub?
ich weiß nicht mehr, mit welcher Version ich das letzte Image gemacht habe, denke aber, daß es die 4.0.3 war. 4.0.3 habe ich jetzt mal auf VirtualBox installiert. Wenn ich von einem funktionierenden Client ein neues Image erstelle und hochlade, dann denselben Client partitioniere und das Image zurückspiele, dann gibt es keinen „Windows Boot Manager“ Eintrag mehr und der Client bootet nicht. Allerdings nur bei NVME Platte.
Wenn ich vor dem Partitionieren die Partitionsdaten mit sgdisk -b sichere und nach dem zurückspielen des Images mit sgdisk -l zurücksichere, dann bootet der Client wieder. Linbo sichert da irgendwie nicht alle Boot Informationen, bzw. stellt diese nicht wieder her(auf NVME)
Es ist also so, daß Linbo 4.0.x beim restore nicht mit NVME Festplatten funktioniert, wenn diese neu formatiert wurden.
Das unter 4.0.3 erstellte Windows 10 NVME Image kann unter 4.0.3 auf einen SATA PC wiederhergestellt werden. Unter 4.0.5 kann dieses NVME Image nicht auf den SATA PC wiederhergestellt werden(Bootschleife)
Muss ich mir anschauen. Das Problem ist, wenn man das Partionsschema komplett mit sgdisk -b wieder zurückspielt, ist ein etwaiges vorausgehendes Resize wieder kaputt.
sgdisk war nur für mich eine Möglichkeit den Fehler einzugrenzen, Lösung ist es, wie Du schreibst keine.
Ich könnte mir aber vorstellen, daß es mit efibootmgr zu tun hat, welches in dieser Version evtl. keinen, für die von mir verwendeten UEFI Firmware Versionen, gültigen Eintrag schreibt. Das allerdings nur, wenn es auf einer NVME Platte ausgeführt wird.
Ich kenne mich dazu aber nicht gut aus, stelle aber nur fest, daß wenn ich mit efibootmgr einen Windows Eintrag händisch schreibe(VirtualBox), dieser dann im UEFI Bootmenü sichtbar ist(aber auch nicht bootet). Wenn Linbo den Eintrag schreibt, ist dieser nicht sichtbar.
Wäre gut, wenn Du hier eine Lösung finden könntest, damit auch die NVME Geräte installiert und geklont werden können.
Dir so schnell Zeit genommen hast, den Fehler zu suchen, zu finden und zu beheben
Du meine Fehlermeldungen ernst nimmst und diese manchmal auch noch hilfreich für Dich sind
Ich habe das jetzt mit VirtualBox und Fujitsu Lifebook U7510 ausprobiert - was soll ich sagen, funktioniert einwandfrei, der BSOD/Bootschleife ist weg und Windows 10 bootet nun auch auf NVME.