Lmn7.1: nach upgrade Windows Bluescreen

Server v7
#1

Hallo,
wir nutzen die Osterferien für das Upgrade von 7.0 auf 7.1

	root@server:/srv# dpkg -l | grep -i muster
ii  linuxmuster-base7                      7.1.8-0       
ii  linuxmuster-client-servertools         0.9d     
rc  linuxmuster-linbo-common7              2.4.3-4  => EDIT: bereits beseitigt
ii  linuxmuster-linbo-gui7                 7.0.5    
ii  linuxmuster-linbo7                     4.0.23-0 
ii  linuxmuster-prepare                    7.1.3-0  
ii  linuxmuster-webui7                     7.1.16   
root@server:/srv#

EDIT: kein UEFI Windows sondern normal BIOS boot

Beim heutigen Versuch:

  • schreiben eines neuen Installationsimages
  • eines Windows 10 Rechners, der bisher unter Lmn 7.0 lief
  • jetzt unter obiger Lmn 7.1 Umgebung und obiger Linbo 4 Version ein neues Image erstellt
  • landet wie gewünscht im /srv/linbo/images/name.qcow2
  • Reg Patches neue aus aktuellem examples kopiert (wie Doku)
  • jetzt an einem weiteren (zweiten) PC:
  • per Linbo 4 neu partitioniert und Image neu aufgespielt
  • direkt nach Abschluss des Klonens zu beginn des Start Vorgangs erscheint ein Windows Bluescreen
  • in der Bluescreen Meldung war zu erkenne, aus dem Kopf grob: windows system 32\ winloader.exe

Jetzt sind wir dabei zuerst per linbo-cloop2qcow2 ein Windows cloop in ein qcow2 zu migrieren.

Oder hat wer ein Vorschlag der Fehlerbehebung oder Lösung oder soll Ablauf der Migration bei Windows anders durchgeführt werden?

Grüße,
gerd

Linbo regpatcher ab 4.0.13
Linbo regpatcher ab 4.0.13
#2

Hallo Gerd,

der Vorgang ist genau richtig:

  1. Einen Client unter 7.0 mit neu+start gesynct vorhalten
  2. upgrade 7.0 → 7.1 durchführen
  3. in der start.conf von .cloop auf .qcow2 umstellen
  4. Vorbereiteten Client in linbo booten (er wird wohl einmal neustarten, weil das linbo aktualisiert wird)
  5. kontrollieren, ob die linbo Version am Cleint stimmt (steht in der GUI unten in der Zeile)
  6. Image erstellen und hochladen

Die Meldung beim BlueScreen wäre schon wichtig: jetzt kann ich nur raten was es ist.
Bitte sync einen Cleint nochmal vollständig mit dem neuen qcow2 Image: also partitionieren und dann syncen.
Bitte lass auch mal testweise den .reg weg (vor dem Booten des Clients .reg Datei auf server entfernen).
Das funktioniert nur, wenn der Client auch partitioniert wurde: sonst mußt du während des syncs mit linbo-ssh auf den Cleint und die .reg weglöschen (liegt im Cache).

Ich ziehe das Verfahren „Image an 7.1 erstellen“ dem Verfahren: cloop-in-qcow2-umwandeln-mittels-script vor.

LG

Holger

#3

Hallo Holger,

hab’ schnell ein Foto gemacht.
Das ist im frühen Windows boot Prozess kurz nach dem MBR, die Meldung erscheint in den ersten einstelligen Sekunden des Windows Boot:

Fehlercode_winload
Fehlercode_winload2048×1536 208 KB

EDIT: kein UEFI Windows sondern normal BIOS boot

ÜBRIGENS:
Clint Linbo Upgrade auf V.4 hat bei den letzten Versuchen auch nach drei Reboots nicht funktioniert, obwohl PXE, DHCP usw. alles sauber durchläuft.
Erst nach Partitionieren mit Client Linbo v. 2.4 und wiederholtem reboot erfolgt das Upgrade auf Client Linbo V4.x.
Natürlich hab ich damit nochmal partitioniert …

Grüße,
gerd

#4

EDIT: kein UEFI Windows sondern normal BIOS boot

So hatten wir das als erstes versucht und obigen Fehler erhalten.
Ich hab’ ja noch ein paar W10 PCs in dem selben Raum mit denen ich das nochmal testen kann.
Zuvor unter Lmn7.0 wurde auf „saubere Installation“ per „Neu + Start“ durchgeführt, hier bootet das W10, das zuvor im produktiven Einsatz war, durch.

Ich versuchs über Ostern - wenn mir langweilig ist :wink: :frowning:
noch mal

Grüße,
gerd

#5

Erst mal Entwarnung! wahrscheinlich gelöst bzw. „tritt nicht mehr auf“
jetzt, nach dem zweiten Versuch, fährt das Windows normal hoch, der Login mit globa-admin funktioniert.
(weitere Tests mache ich heute nicht mehr)
Diesmal wurde das neue/erste qcow2 Windows 10 Image, wie oben beschrieben, nicht per Client und Linbo 4 erstellt, sondern auf der Kommandozeile per linbo-cloop2qcow2 …

Jetzt habe ich bei uns aber noch ein Fehler ( evtl. unsererseits?) des regpatches festgestellt.
Das möchte ich aber besser heir beim passenden Thema klären:
https://ask.linuxmuster.net/t/linbo-regpatcher-ab-4-0-13/8660/18?u=gpeter
https://ask.linuxmuster.net/t/linbo-regpatcher-ab-4-0-13/8660

EDIT:
Beschreibung wie ich vor gegangen bin, siehe hier:
https://ask.linuxmuster.net/t/linbo-regpatcher-ab-4-0-13/8660/26?u=gpeter
Grüße,
gerd

#6

nur eine kurze abschließende Rückmeldung:
wir haben jetzt grob 95% der Clients, ganz grob ca. 500, nach obigem Schema umgestellt bekommen.
Die ein zwei Hand voll, die blöd gemacht haben, haben nichts mit dem Upgrade zu tun.
Wir mussten so gut wie alle -wie oben beschrieben- manuell zum Ziehen der 4er LINBO Version überreden, das funktionierte bei fast allen auch nach zwei Reboots nicht von allein.
Sprich: Gute Arbeit! Bei uns hat der Upgrade auf 7.1 sehr gut funktioniert, den produktiven Test im Einsatz folgt ab Montag :wink:

Grüße,
gerd