gerade den IT-Raum mit aktuellem Linbo geclont stehen alle PC mit dieser Meldung seit 20 Minuten, nichts passiert, keine Festplattenaktivität.
Das Kommando war: linbo-remote -r it1 -p format,sync:1,start:1
/var/log/linuxmuster/linbo/it1-pc09_image.log
##################
Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Restoring partition UUID 3842E600-C0C3-4D31-B7EC-BFB90ACCF1FF of /dev/sda3.
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help):
Expert command (? for help): Partition number (1-4): Enter the partition’s new unique GUID (‚R‘ to randomize): New GUID is 3842E600-C0C3-4D31-B7EC-BFB90ACCF1FF
Expert command (? for help):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
##################
Wenn ich in diesem Zustand von der GUI auf die Konsole wechsle, dann lese ich:
Checking file system consistency ...
"/dev/sda3" opened read-write
"/dev/sda3" closed
No errors were found
Das wiederholt sich dann ohne Ende.
Wenn ich dann neu starte, lande ich in einer Linbo Bootschleife und Windows 10 wird nicht gestartet.
Zurück auf 4.0.21-0 und neu+start landen die PC ebenfalls in einer Bootschleife. Nach ca. 6x booten, startet dann Windows 10 wieder… Keine Ahnung warum. Das habe ich allerdings nur auf einem einzigen PC getestet
Ich bin jetzt wieder zurück auf 4.0.19-0 und da starten die oben beschriebenen PC beim ersten Mal in Windows 10.
Zurück auf 4.0.21-0 und neu+start landen die PC ebenfalls in einer
Bootschleife. Nach ca. 6x booten, startet dann Windows 10 wieder… Keine
Ahnung warum. Das habe ich allerdings nur auf einem einzigen PC getestet
hast du da den Client auch mit
format
platt gemacht?
Oder nur gesynct?
Was steht den nach dem boot von 4.0.21 in der linbo GUI welche Version
gestartet wäre? (steht unten links, glaube ich).
Ich hatte die Clients alle formatiert
Das Kommando war: linbo-remote -r it1 -p format,sync:1,start:1
Da weiß ich jetzt nicht, was gemeint ist. 4.0.22-0 hatte nicht funktioniert 4.0.21-0 auch nicht. Dann bin ich auf 4.0.19-0 zurück, weil ich nicht länger Zeit hatte. Bei meinem Testsystem unter VirtualBox hatte ich ähnliche Probleme mit den neueren Linbo Versionen.
Ich weiß nicht, was das heißt. Ich habe die Rechner von PXE gestartet und nach dem Downgrade auf die jeweiligen Versionen wurde diese auch via PXE vom Server geholt.
ich beschreib mal ein wenig, wie das update auf dem Client läuft (in
diesem Fall „Downgrade“).
Du hast 4.0.22 auf dem Client und hast auf dem Server aus 4.0.21
downgegradet.
Jetzt bootest du den Client (egal ob lokal oder per PXE).
Linbo bootet mit der lokalen Version 4.0.22 und bemerkt „eine andere“
Version auf dem Server. Diese installiert linbo und macht, wenn du nciht
„warmstart=no“ verwendest, einen „warmstart“ (früher einen reboot aka
„Kaltstart“).
Erst nach diesem restart läuft die „Serverversion“ von linbo.
Deswegen meine Frage: welche Version lief?
Sie steht ja unten in der GUI (und weiß auf Schwarz während des bootens,
wenn splash aus ist).
Vielleicht ist beim restart was schief gelaufen.
es lief immer die auf dem Server installierte Version auf dem Client. Linbo startet also 2x nach einem Downgrade.
Es sind ja 2 Probleme:
„Checking filesystem consistency“ wo es dann nicht weitergeht. Konnte ich heute auf VirtualBox leider nicht reproduzieren.
Da habe neulich schon in einem anderen Thread dazu etwas geschrieben und sollte eigentlich in einer extra UEFI FAQ stehen:
Sobald ein „Windows Boot Manager“ NVRAM Eintrag existiert, aber keine EFI Partition mit Microsoft Bootverzeichnis und Dateien, startet Linbo mit efibootmgr -n diesen Windows Boot Manager Eintrag. Der sucht nach dem Microsoft Verzeichnis auf der EFI Partition, welches es nicht gibt, wenn Linbo die Platte formatiert hat. Die Bootschleife ist die Folge. Da das Verhalten abhängig vom UEFI Hersteller ist,
ob ein Microsoft UEFI NVRAM existiert, bzw. bestehen bleibt, obwohl kein EFI/Microsoft/Boot in der ESP Partition vorhanden ist, ist es ein Lotteriespiel, ob der Rechner noch bootet.
Das kann man auch schön in VirtualBox simulieren bzw. reproduzieren:
Windows 10 PC starten
Eingabeaufforderung mit administrativen Rechten starten
bcdboot c:\windows /l de-de
Damit werden der „Windows Boot Manager“ NVRAM Eintrag geschrieben, sowie Microsoft/Boot auf der EFI Partition erstellt. Windows bootet jetzt immer direkt, ohne grub.
Virtuellen PC von PXE starten(auf die ESC Taste beim Starten hämmern um ins UEFI NVRAM zu kommen), mit Linbo formatieren(also auch die EFI Partition) + neu
Bootschleife
Erst wenn man den „Windows Boot Manger“ Eintrag aus dem NVRAM löscht, dann kann der grub Windows wieder starten, weil dieser nicht auf die EFI Partition verweist, sondern auf das EFI Verzeichnis in der Windows Partition.
@thomas
Man könnte also Linbo dahingehend erweitern, daß es nach dem formatieren der ganzen Platte überprüft, wenn auf der ESP Partition kein Microsoft Eintrag existiert(und bitte nur dann), daß es einen existierenden „Windows Boot Manager“ Eintrag aus dem NVRAM löscht.
Das war nur ein Beispiel um einen gültigen MS UEFI Eintrag zu generieren und damit das jemand reproduzieren kann.
Ja, das funktioniert tatsächlich, danke! Damit existiert der ungültige MS UEFI Eintrag nach wie vor, aber das interessiert den grub dann nicht. Ich mags halt gerne aufgeräumt, denn so ein Mist kostet einfach unglaublich viel Zeit. Aber das ist vielleicht auch nicht die Aufgabe von Linbo, die teils abenteuerlichen UEFI Implementationen der Hersteller auszubügeln.
Man sollte die Zusammenhänge aber im Hinterkopf haben, wenn es mit UEFI Probleme gibt. Und wenn ich mich im Forum so umsehe, sind das nicht wenige.
