wenn man mit Linbo 4.0.8-0 das Image auf einen Laptop mit angeschlossener Netzwerkkarte zurückschreibt, ist alles in Ordnung. Der Laptop startet danach einwandfrei in Windows.
Anschließend zieht man den USB-Netzwerkadapter ab, da der Laptop keine eingebaute Netzwerkkarte hat. Beim nächsten Neustart kommt Press [1] to reboot oder [2] to shutdown
Wenn man nach dem Klonen den Laptop 1x mit angeschlossenem Netzwerkadapter neu startet, dann funktionieren auch nachfolgende Offline Neustarts ohne Probleme und die Fehlermeldung ist verschwunden.
Das kann man auch in einer virtuellen Maschine reproduzieren, indem man den Netzwerkadapter nach dem Klonen deaktiviert und den Client startet.
Ein kleiner Fehler, aber vielleicht weißt Du ja warum und kannst das leicht beheben.
ist wohl doch ein größeres Problem, denn dieses tritt jetzt auch auf, nachdem wohl irgendein Windows Update gelaufen ist. Die Laptops hängen jetzt alle mit obiger Meldung.
Wenn ich den USB Netzwerkadapter anstecke, dann bootet Linbo das installierte Windows. Ohne Netzwerkadapter startet Windows nicht mehr. BSOD.
Welche Bootreihenfolge steht den im BIOS zu dem Zeitpunkt?
Kann man das mal auf grub oder auf die SSD umstellen und testen?
Windows Updates sind sowiso ein Problem: die sollten, bei einem Rechner der regelmäßig geimaged wird, in jedem Fall ausgeschaltet sein.
ich finde deine Beiträge immer sehr HIlfreich: du steigst sehr tief in die Materie ein und hilfst beim Finden der Lösung enorm.
Gerade bei der Entwicklung von linbo 4 hast du sehr viele Fehler gefunden und geholfen sie zu beheben.
Trotzdem würde ich mir manchmal wünschen, dass am Ende deiner Posts nicht der Befehlston aufkommen würde
Das steht nur die Platte als mögliche Bootoption und da bootet dann der installierte grub.
Ja, das weiß ich. Automatische Updates sind per default deaktiviert. Ich kann aber nicht verhindern, daß ein Lehrer, der Adminrechte auf seinem Dienstgerät hat, Windows Updates macht.
ich finde deine Beiträge immer sehr HIlfreich: du steigst sehr tief in die Materie ein und hilfst beim Finden der Lösung enorm.
Gerade bei der Entwicklung von linbo 4 hast du sehr viele Fehler gefunden und geholfen sie zu beheben.
Hoppla, das kommt falsch an? Ok, ist aber auf keinen Fall so gemeint. Tut mir leid, wenn das so wirkt. Tatsächlich ist es so, daß ich da eine Lösung für mich brauche. Ich sage ja nicht, daß ich diese von Euch brauche. Wäre natürlich schön wenn jemand eine Lösung hätte, oder der Bug schnell behoben werden könnte, da ich ein Testing System im Produktivbetrieb habe.
ja, das stimmt.
Wenn die in dem „Leihgerätemodus“ sind, dann sind bei mir auch die „Besitzer“ Admins und sollen natürlich auch Updates machen dürfen.
Meine Yoga L13 Convertables haben den „BUG“, dass Windows sich selbst in der Startreihenfolge an die Spitze setzt.
In diesem Fall ist das aber HIlfreich, weil linbo damit komplett im Hintergrund ist.
Am BUG kann ich so nichts machen, aber vielleicht einen Workaround anbieten.
Steht Windows Bootmanager den im UEFI Bootmenü zur Verfügung?
Wenn ja, dann nimm das an erster Stelle rein.
Wenn es dann geht ist ja alles gut.
Geht das nicht oder steht der Windows Bootloader nciht zur Verfügung, dann stell ihn wieder her durch booten vom Windowsdatenträger (-> Startreparatur) und erstell danach ein neues Image.
Dabei sollte auch der Inhalt der EFI Partition gesichert werden und damit beim nächsten wieder hergestellt werden.
Vorteil: niemand klickt ausversehen auf sync (die kommen ja garnicht an das linbo) und damit wundert sich auch niemand, wenn alle Daten weg sind
Sollte das Gerät irgend wann mal wieder geklont werden müssen, dann macht man den USB Netzwerkdongel ran und bootet mittels F12 → Netzwerk.
LG
Holger
PS: meine KOllegen haben noch eine Anleitung anbei bekommen mit
Der Windows Bootloader steht bei den Lenovo Notebooks nicht zur Verfügung. Eine gute Idee den Linbo Bootloader zu überschreiben. So werde ich es machen. Ist halt lästig, weil eine aktuelle Windows 10 Boot DVD den Storagetreiber nicht hat und dieser umständlich vom Stick geladen werden muß. Wäre also trotzdem gut rauszubekommen, warum das so passiert.
@thomas Bitte gib doch Bescheid, wenn ich etwas dazu beitragen kann, daß die Ursache gefunden wird.
kann ich so leider nicht nachvollziehen. Die Konsolenmeldung kommt, wenn aus irgendeinem Grund das Guiarchiv nicht in den lokalen Cache heruntergeladen werden konnte.
danke für Deinen Test und die mögliche Ursache.
Es ist ja so, daß der Laptop offline gestartet werden soll, d.h. ohne verkabelte Netzwerkverbindung. In dem Fall ist es natürlich richtig, daß er das GUI Archiv nicht runterladen kann. Aber warum probiert er das überhaupt ohne Netzwerkverbindung?
Wenn der Rechner mit Netzverbindung gestartet wird, wird das Guiarchiv heruntergeladen und in den lokalen Cache gelegt. Bei Offlinebetrieb wird nicht versucht das Gui herunterzuladen, sondern das aus dem Cache genommen. Wenn die Konsolenmeldung mit reboot und shutdown kommt, heißt das, dass das Guiarchiv nicht im lokalen Cache liegt. Warum das in deinem Fall passiert, kann ich nicht sagen. Hängt wahrscheins mit deinem speziellen Setup mit USB-Netzwerkadapter zusammen.
ich denke nicht, daß es an dem USB-Netzwerkadapter liegt, da ich das auch in einer VM reproduzieren kann. Also zumindest so wie im Ursprungspost geschrieben nach dem Imaging. Warum das jetzt auch mit Laptops passiert, die bisher ganz normal gelaufen sind, weiß ich nicht. Der Cache wurde da nicht verändert und das GUI Archiv ist dort vorhanden. Ich könnte mir nur vorstellen, daß es mit meinem Eingangs Post zu tun hat.
… sorry: hätte ich auch drauf kommen können
Also: ich hab das mal nachgestellt in meiner VBox Umgebung.
Stand lmn7.1 mit linbo 4.08
Clietns mit Win10 und Ubuntu 20.04
Test Client 1 (wurde schon ein paar mal gesynct mit Win und oder Ubuntu)
Test:
Client1 gestartet: in den durchlaufenden Meldungen erhasche ich „Downloaduing linbogui“
Neu+Start gedrückt: Win10 synct aus dem Cach (war schon mal gesynct) und bootet.
Heruntergefahren, netzwerkkarte deaktiviert.
Eingeschaltet: linbo erscheint (alles gut)
Gleichzeitig hab ich Client 2 gestartet, der auch schon ein paarmal irgend was gesynct hatte.
„Downloading linbogui“ konnte ich nicht erhaschen: war aber nicht aufmerksam (könnte also da gewesen sein).
Um den Test zu Variieren hab ich den Partitioniert und dann (direkt, ohne Reboot) Win10 gesynct (neu+start). Danach Heruntergefahren und Netzwerkkarte deaktiviert.
Es erscheint [1] [2].
Dann ausgeschaltet und Netzwerkkarte aktiviert, dann linbo gebootet („Downloading linbogui“ gesehen).
Danach direkt linbo heruntergefahren (nix gesynct oder so) und Netzwerkkarte wieder ausgehängt.
Dann wieder gebootet: es erscheint (im offline Modus) linbo.
Es scheint also tatsächlich so zu sein, dass nach dem ersten sync die gui nicht auf dem Client ist.
Einmal danach am Netzwerk linbo booten booten behebt das.
Ach so: die Clients laufen im BIOS Mode nicht im UEFI Mode.
Nachdem das auch andere betrifft und auch dann passiert, wenn das System schon eine Zeit problemlos gelaufen ist, muß es irgendetwas anders sein, als das Vorhandensein der GUI im Cache.
Das kann ich auch so bestätigen - der Fehler ist gestern bei mir aufgetreten und daher hatte ich hier im Forum nach dem Fehler gesucht.
Ich hatte gestern bei einem Client eine neue SSD eingebaut und den neu partitioniert, Cache synchronisiert und OS synchronisiert und gestartet. Dann hatte ich das Netzwerkkabel abgezogen, weil die das Fehlerbild bei der vermutlich defekten, alten SSD dann anders war.
Der hier beschriebene Fehler trat dann auf. Nach einem weiteren regulären Start mit eingestecktem Netzwerkkabel konnte man den Client auch wieder offline starten.
Danke für die Rückmeldungen, konnte das jetzt auch so mit einem UEFI-Client mit unpartitionierter Festplatte nachvollziehen. Es gibt ja glücklicherweise einen funktionierenden Workaround, den man anwenden kann, bis es einen Fix gibt.
Bei auftreten des Fehlers, Kiste nochmals mit bestehender Netzwerkverbindung starten.
Dann herunterfahren.
Neustart dann ohne Netzwerkverbindung sollte LINBO im offline-Modus zeigen.
Richtig?!
Markiere das jetzt erstmal als Lösung, da es eine Workaround-Markierung ja nicht gibt. Dieser Post ist als Wiki-Eintrag für jeden editierbar, falls ich etwas falsch wiedergegeben habe.
tut mir leid, wenn ich da jetzt etwas lästig bin. Ich denke nur ein Teilaspekt ist gelöst, nämlich die Situation nach dem Imaging so wie Thorsten es zusammengefasst hat.
Bei meinen genannten Systemen trat das plötzlich auch nach einem bereits erfolgreichen Betrieb ohne LAN, d.h. nur mit WLAN auf. Bei mehreren Laptops.
Ans LAN verbinden startet auch Linbo und Windows. Ohne LAN seit neuestem eben nicht mehr.
Danke!
Viele Grüße
Klaus
Edit:
Hier die Fortsetzung und Lösung des zweiten Aspekts
Hänge mich mal an diesen Thread an. Ich habe heute einen neuen Rechner in unser LMN 7.1 aufgenommen, erstmals AMD-Prozessor.
Der erste Start führte zu einem Einfrieren nach „Initializing hardware…“ Nach Setzen der Option „nomodeset“ war das Problem behoben, allerdings startet der Rechner nun immer noch nicht ins Linbo sondern landet im „Press [1] to reboot or [2] to shutdown.“-Bildschirm.
Linbo lädt beim Netzwerk-Start mit "Loading /linbo64 … Loading /linbofs64.lz … " herunter, die Gerätegruppe wird richtig erkannt.
Die Festplatte habe ich mit einem Windows-Bootstick formatiert. Es handelt sich um ein UEFI-System mit NVME-Festplatte. GRUB taucht im Bootmenü noch gar nicht auf.
Wo könnte ich ansetzen, um den Rechner ans Laufen zu bekommen?
