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/sda4
Allerdings fällt auf daß die Cache Partition /dev/sda4 nicht gemountet ist.
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).
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?
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).
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
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.
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.
… 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.
Da müssen wir mal schauen. Ich meine das ist in einem PR bereits behandelt. Führe die Zeile doch mal manuell aus aber ohne -mNT1. Passwort musst du natürlich durch das Passwort des Domain admins ersetzen bzw. administrator einfach durch den global-admin ersetzen.
Dann sollte eine etwas hilfreichere Ausgabe erscheinen.
Die Probleme die ich habe, hatte ich denke ich gut beschrieben.
Die Upgradeanleitung hatte ich gelesen und mich daran gehalten. Linbo 4.0.44 hattest Du nach meinem Upgrade rausgebracht.
Ja, ich bin mittendrin und dabei im Beta Test und habe ein Produktivsystem damit bestückt in der Hoffnung hier im Forum Unterstützung zu finden, wenn es mal nicht weitergeht und mich bei der Fehlersuche zu beteiligen.
Dein Ton gefällt mir nicht. Ich habe nicht geschrieben, daß die Upgrades geschmeidig von statten gehen müssen. Ich habe nur das Problem, daß im Moment gar nichts mehr geht.
Ich für meinen Teil bin nach Deinem Kommentar als Beta Tester raus.
> /usr/bin/smbcquotas --debuglevel=0 -U global-admin%'*****' -S UQLIM:serdarje1:1263324160/1579155456 //server/default-school
> Quotas are not enabled on this share.
> Failed to open \$Extend\$Quota:$Q:$INDEX_ALLOCATION NT_STATUS_ACCESS_DENIED.
…aber das wird wohl nicht das Problem sein. Ich habe auf git den commit im lmn7.2-testing Branch von sophomorix4 gefunden. Den werde ich mal bei meiner Testumgebung versuchen.
ja klar!