Hallo,
ich hab jetzt mal eine meiner Schulungsumgebungen upgedatet.
Hat alles gut geklappt.
Am Ende hab ich die Clients gestartet, dann kam dieser Bildschirm:
(das erschien durchlaufend: die Meldung kam also immer wieder).
Nach 3 Minuten habe ich den Client neu gestartet: dann startete linbo 4.1
Syncen klappt (Windows 10 und Ubuntu 20.04) und auch die Anmeldung und die WebUi funktionierten.
LG
Holger
Hallo,
habe heute Nacht ebenfalls mal in meiner Schulungsumgebung getestet. Läuft alles sauber durch.
Beim ersten Start der Clients bleiben diese mit derselben Meldung wie bei Holger hängen. Da fehlt eine passende Bibliothek bei der linbo-gui (eventuell @dorian )? Per linbo-ssh kommt man zu diesem Zeitpunkt nicht auf den Client. Nach abwürgen des Clients und Neustart klappt dann alles.
Das Problem mit den Quota tritt bei mir auch auf. Sophomorix-quota läuft durch und endet mit folgender Fehlermeldung:
Viele Grüße
Dominik
Dann liegt es wahrscheinlich nicht an der Gui.
Wenn es ein Probkem der Gui wäre, würde ssh funktionieren.
VG,
Dorian
Hallo,
ich mach das gerade einfach nochmal mit meiner 7.1er Schulungsumgebung…
Ich sag dann, wie es diesmal aussah 
LG
Holger
Hallo zusammen,
auch hier der Fehler mit linbo_gui und der GLIBC:
Ich habe einen Client mit Linbo 4.0 und bereite das Löschen der Cache Partition vor, damit das Update auf 4.1 klappt:
linbo-remote -d -p initcache:torrent,reboot -i win10-client1root@server:~# cat /srv/linbo/linbocmd/win10-client1.cmd
initcache:torrent,reboot disableguiAls erstes fällt auf, daß die GUI beim nächsten Start des Clients nicht deaktiviert wird. Der Cache wird zwar aktualisiert, aber danach der Fehler im Screenshot in einer Dauerschleife.
Wenn ich den Client neu starte, läuft alles. Wenn ich dann nochmal obiges linbo-remote Kommando absetze und wiederum neu starte, kommt „Der PC wird ferngesteuert…“ in der GUI, was aber endlos läuft.
Weiter fällt auf, daß das manuelle Initialisieren des Caches über die GUI nicht funktioniert. Das läuft ewig und der Cache wird nicht aktualisiert.
Danke für die Fixes!
Viele Grüße
Klaus
Noch eine Ergänzung:
Nachdem der Client mit Linbo 4.1 aktualisiert ist, sieht man in der GUI fast keine Infos mehr mit F1. Ebenso ist ein Klick auf das Ausschalten oder Neustart Symbol nicht funktionell.
Hi!
Den linbo_gui-GLIBC-Fehler kann ich hier nicht beobachten. Sieht so aus, dass ein Linbo4.0 die Linbo4.1-Gui starten will. Habt ihr warmstart abgeschaltet?
Kann ich hier auch nicht reproduzieren. Liegt es evtl. daran:
Der Schritt steht nämlich nicht in der Anleitung.
VG, Thomas
Hallo,
Ja.
Gerade nochmal komplett von Vorne in einer anderen völlig unverbastelten Testumgebung angefangen und genau dasselbe „Fehlerbild“. Beim ersten Start eines Clients nach dem Update kommt der _gui_GLIBC-Fehler und der Client hängt. Habe mal einen neuen Client angelegt und auch dort kommt derselbe Fehler. Wäre ja nicht schlimm, wenn man per linbo-remote noch drauf käme aber der Client hängt an dieser Stelle und es hilft nur ein hard out.
Auch der Quota Fehler ist da…
Meldet euch, wenn ich was testen soll!
VG Dominik
Muss ich mal sehen, wie ich das abfangen kann. Nächste Woche gehts weiter.
VG, Thomas
Hi,
den _gui_GLIBC-Fehler habe ich nicht weiter eingrenzen können aber trotzdem einen Fortschritt erreicht. Bevor man nach dem Update den ersten Client startet, setzt man in /etc/linuxmuster/linbo/ssh_config
den Eintrag:
HostKeyAlgorithms +ssh-rsa
und kommentiert den unnötigen Eintrag
PubkeyAcceptedKeyTypes=+ssh-dss
Wenn man jetzt einen Client startet läuft der zwar in den _gui_GLIBC-Fehler, man kommt aber per linbo-remote drauf, d.h. man kann von dort den Client steuern…damit kann man in dieser Entwicklungsphase gut leben! Bei jedem weiteren Start klappt dann alles und der Fehler ist weg.
@dorian vielleicht doch ein gui Problem? Seltsam ist auch, dass wenn man die gui in der start.conf disabled sämtliche Einstellungen (wie sync+start) in der start.conf ignoriert werden…die gui startet trotzdem, es steht da „Der Rechner wird Ferngesteuert…“ und das läuft unendlich. Auf dem client sieht man auch, dass kein linbo_wrapper Prozess läuft, sondern nur der gui-Prozess. Schaltet man die gui wieder an, funktioniert alles. Irgendwas ist da krumm…
VG
Dominik
Der Fehler von der GUI kommt vielleicht daher, dass beim ersten Start noch die alten Libraries (z.b. glibc) geladen sind, obwohl schon die neue GUI heruntergeladen wurde? Die sind nämlich nicht mit der neuen Binary kompatibel.
@foer nein, das ist genau so gedacht. Der gui-disabled Parameter ist nur für die interne Nutzung. Das setzt linbo-remote, wenn man den Parameter -d mitgibt. Der Name ist vielleicht etwas unglücklich gewählt …
Hi @dorian,
ja, das habe ich ja schon geschrieben. Wenn warmstart abgeschaltet ist, startet das Linbo 4.0 nicht in Linbo 4.1, sondern bootet weiter und startet das neu heruntergeladene Gui. Dann hat man den Schlamassel. Das ssh-Ding ist leicht gefixt. Wobei das für Linbo 4.1 egal ist.
Fix-Vorschlag für das Gui. Das Paket legt das Archiv wie vereinbart nach /srv/linbo/gui. Dann kann Linbo 4.0 es nicht herunterladen und startet das alte Gui aus dem Cache.
Evtl. könnte man ja auch mal testweise warmstart wieder einschalten. Auf meinen Kisten ist das kein Problem. Evtl. hilft da auch nomodeset. In den VBox-Clients hilft es, wenn man fürs Video VMSVGA nimmt.
VG, Thomas
Ja, das kann ich machen. Aber wäre es nicht sinnvoll, den Client nach einem Update zu rebooten? Sonst startet er ja nochmal mit dem alten Linbo und ist erst nach dem zweiten Start aktuell…
Oder hab ich das falsch verstanden?
VG,
Dorian
Hallo Thomas,
warmstart ist nicht konfiguriert.
Es war ein Hinweis von Holger in einem anderen Thread um ein Problem mit Linbo im Cache auszuschließen.
Das Problem mit der nicht funktionierenden GUI besteht immer noch, reproduzierbar. Es funktioniert auch kein Starten des Betriebsystems, kein Sync etc.
Kein Fehler im linbo.log des Clients
[+++ Chapter +++] Starting Windows 10
[Info] Linbo state changed to: 4
[Info] Executing: linbo_cmd start /dev/sda3 /dev/sda3 auto /dev/sda4Allerdings fällt auf daß die Cache Partition /dev/sda4 nicht gemountet ist.
Viele Grüße
Klaus
Hallo zusammen,
Heute Morgen hat es nurnoch für das Upgrade auf 7.2 in meiner VM
Umgebung gereicht: nicht mehr für das testen der Clients.
Jetzt hab ich also meine zwei Clients gebootet.
Vorher hab ich warmstart=no aus der start.conf.GRUPPE entfernt.
Beim ersten Client hab ich die Anzeige auf VMSVGA gestellt und beim
zweiten auf VBoxSVGA gelassen.
der erste hat linbo 4.0 gebootet und automatisch auf 4.1 upgegraded und
dann die GUI geladen: alles ohne Probleme und ohne restart.
der zweite hat linbo 4.0 gebootet und dann ist er beim Splashscreen
„hängen“ geblieben: ich komm aber mittels linbo-remote drauf.Nach einem
reboot ist die GUI da.
Syncen von Win und Lin haben beide funktioniert.
Die Clients waren vorher leer: nur mit linbo (damals noch 4.0)
partitioniert. Es war also linbo 4.0 auf der Platte, aber noch kein BS.
Dann hab ich die zwei Clients nochmal aus der .ova wiederhergestellt und
warmstart=no wieder reingenommen.
Server und OPNsense sind also identisch geblieben.
Beide Clients laufen in das glibc Problem.
linbo-remote funktioniert nicht (es läuft ja noch linbo 4.0 denke ich).
getestet wurde alles mit linbo 4.1.23
LG
Holger
Hallo Holger,
also ist es so, dass der Gui-Fehler nur auftaucht, wenn der Warmstart abgeschaltet ist. Das deckt sich mit meinen Beobachtungen.
Das macht ja eigentlich der Warmstart. Ich könnte natürlich bei abgeschaltetem Warmstart stattdessen einen Reboot veranlassen. Das könnte aber zu unerwünschtem Verhalten führen, wenn bei Clients per Grub der Standardboot ins Betriebssystem festgelegt ist. Dann wird nach einem Reboot ins BS gestartet und nicht wieder in Linbo. Sollen wir das so machen?
VG, Thomas
Hallo Thomas,
Das macht ja eigentlich der Warmstart. Ich könnte natürlich bei
abgeschaltetem Warmstart stattdessen einen Reboot veranlassen. Das
könnte aber zu unerwünschtem Verhalten führen, wenn bei Clients per Grub
der Standardboot ins Betriebssystem festgelegt ist. Dann wird nach einem
Reboot ins BS gestartet und nicht wieder in Linbo. Sollen wir das so machen?
ja, mach das so.
Da, wenn inm pxegrub ein automatischer boot ins installierte BS
eingestellt ist, dann kommt er ja auch schon nicht ins linboupdaten…
also kommt das Problem garnicht.
Will jemand linbo updaten, dann muss er eh an pxegrub rumfummeln, und
bei den Leuten die das schon umgestellt hatten ist zu erwarten, dass sie
sich damit auskennen …
Also: ich bin für reboot nach linbo update (falls warmstart=no ist, was
bei mir viele brauchen).
LG
Holger
Ok. 
Hi Thomas,
bei mir klappt das in der Testumgebung nicht. Neuestes Linbo ist drauf und warmstart=no gesetzt. Der Client bleibt beim ersten pxe-Boot nach dem Update mit demselben Gui-Fehler hängen statt zu rebooten. Ist das bei anderen auch so oder nur bei mir?
VG
Dominik