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.
ich hau Sonntag abends noch einen Fix raus und alles was dir dazu einfällt, ist mich anzumachen, weil irgendwas scheints nicht dokumentiert ist.
Darum geht es nicht. Nutzung wurde nicht verboten. Es wurde aber ausdrücklich darauf hingewiesen, dass es noch nicht für Produktivbetrieb taugt. Aber was weiß denn ich.