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
Hallo Dominik,
klar, auf lmn 7.1 muss natürlich vor dem 7.2er-Upgrade auf linuxmuster-linbo7 4.0.44 aktualisiert werden.
VG, Thomas
Hallo zusammen,
Das steht wo dokumentiert? Ich habe 4.0.23 und beschriebenen Fehler wie wohl viele andere. Auf manchen Laptops, die nie ans LAN-Kabel kommen ist noch linbo 2.x. Wie kommt man da jetzt raus? Wäre ja schon hilfreich, wenn man die GUI mit linbo-remote deaktivieren könnte, was aber leider auch nicht geht.
Viele Grüße
Klaus
Guten Morgen Klaus!
Ich glaubs ja nicht. Was hast du für ein Problem?
Dass das System vor dem Upgrade auf den aktuellen Stand zu bringen ist, steht ganz vorne in der Upgradeanleitung. Und das werden die Admins bestimmt auch so machen, wenn sie demnächst auf 7.2 upgraden.
Im Moment ist allerdings noch BETA-Test. Da werden Fehler gesucht und gefixt. Nur falls sich das noch nicht herumgesprochen hat.
Schreibt der, der es seit Jahren versäumt hat, die Software seiner Geräte aktuell zu halten. Sorry, dass wir bei der Entwicklung von Linbo 2.0 nicht daran gedacht haben, dass es sich einmal geschmeidig auf Linbo 4.1 upgraden lassen muss.
VG, Thomas
Hallo Klaus,
klar, auf lmn 7.1 muss natürlich vor dem 7.2er-Upgrade auf linuxmuster-linbo7 4.0.44 aktualisiert werden.Das steht wo dokumentiert?
hier:
https://docs.linuxmuster.net/de/latest/appendix/beta-lmn72/index.html
„Bringe zuerst den lmn7.1 Server auf den aktuellsten Paketstand.“
… bringt dir aber nix, weil das 4.0.44 Paket ja erst jetzt raus kam:
nach deinem upgrade auf 7.2 … und vor allem auch wegen deiner Hilfe und
deines Debuggings.
Ich habe 4.0.23 und beschriebenen Fehler wie
wohl viele andere. Auf manchen Laptops, die nie ans LAN-Kabel kommen ist
noch linbo 2.x. Wie kommt man da jetzt raus? Wäre ja schon hilfreich,
wenn man die GUI mit linbo-remote deaktivieren könnte, was aber leider
auch nicht geht.
… wie man da durch linbo-remote raus kommt, weiß ichleider ncht.
Auch ich hatte beim Umstieg von 7.0 (linbo 2.4) auf 7.1 (linbo4.0)
einzelne Laptops die ich nach Monaten das erste mal in der Hand hatte
auf denen noch 2.4 drauf war.
Die hab ich gebootet und frisch partitioniert, danach neugebootet und
nochmal mit linbo 4.0 partitioniert.
Ich weiß: viel Handarbeit: tut mir Leid 
LG
Holger
Hallo Holger!
Warum sollte dir das leid tun? Dass Laptops mehr Arbeit machen, liegt in der Natur der Sache.
VG, Thomas
Hallo Thomas,
ja klar!
Habe jetzt nochmal komplett neu von einer 7.1 aus angefangen…passt! Client bootet neu und startet dann mit Linbo 4.1.
…bleibt noch der Quota-Fehler…
LG
Dominik