Hallo zusammen,
seit heute Morgen bekommen wir die folgende Meldung auf den LINBO Clients obwohl nichts geändert wurde. Hat da jemand Ideen wie man dies fixen könnte?
Vielen Dank im voraus für die Vorschläge und Lösungsansätze!
Hallo c.althoff93,
werden die Clients den remote gesteuert?
Also habt ihr einen syncjob remote angestoßen?
Booten die Clients nach einigen Minuten einfach weiter?
Es kann ja sein, dass Jemand einen linbo remotebefehl in die Pipeline gelegt hat mittels
linbo-remote -p …
Dann wird das beim nächsten Boot ausgeführt.
Was passiert den, wenn du einen Clietn neu startest? Komt das wieder?
Kannst du einen solchen Client erreichen vom Server aus mittels
linbo-ssh 192.(REST DER IP)
Hat euer Netzwerk wirklich ein 192.er IP NEtz?
LG
Holger
Moin!
Welche Linbo-Kernel-Optionen werden verwendet? Der screen sollte nur erscheinen, wenn nogui nomenu verwendet werden (s. GitHub - linuxmuster/linuxmuster-linbo7: Next generation linbo).
VG, Thomas
Bisher eigentlich nicht. Außer Update auf 7.3 haben wir in den letzten Tagen nichts gemacht.
Nein, nicht nach <15 Minuten
An dieser Installation hat noch nie jemand linbo-remote genutzt, ging bis jetzt in 7.2 auch.
Ja, immer wieder, bis man das Netzwerkkabel absteckt, dann kommt er hoch. Danach hört das Problem dann auf.
ja, das ist möglich.
Ja, das ist richtig, 10er giibt es aber auch.
Heute hatten wir an unserem Gymnasium das Problem auf allen Rechnern…
In den Herbstferien ist dort auf 7.3 geupgradet worden.
Viele Grüße
Christian
Nein, nur folgende Optionen:
quiet splash dhcpretry=20
Mit ohne Netzwerkkabel geht es auch.
Hallo zusammen!
Interessant - das hatten wir heute morgen bei einem Client auch, der längere Zeit nicht mehr angerührt wurde.
Es gab keine Remote-Steuerung und auch die erwähnten Kernel-Optionen haben wir nicht verwendet.
Was am Ende geholfen hat, war diesen Rechner per Remote-Befehl neu einzurichten. Meine Vermutung war, dass vielleicht lokal auf dem Client noch irgendetwas herumlag, was für diesen Zustand sorgte.
Viele Grüße
Thomas
Abend,
hab das jetzt nicht alles gelesen, aber schau doch mal ob nicht noch alte Befehle in
/srv/linbo/linbocmd rumgammeln. Ich hatte den Fall schon, dass da noch Kram in der Pipeline war, der im unguenstigen Moment losgelassen wurde.
Gruss Harry
Hallo Harry,
das war das Erste, was ich überprüft habe - war aber nicht der Fall. Da der Fall nach dem Plattmachen des Clients nicht mehr auftrat, vermute ich eher irgendetwas im lokalen Cache, was das ausgelöst hat. Ist aber eben nur das, eine Vermutung.
Viele Grüße
Thomas
Hallo Christian,
ich habt 10.x.y.z und 192.x.y.z Adressen in eurem internen Netz?
LG
Holger
Hallo,
selbes Problem hier, also dieselbe Fehlermeldung.
Linbo Kernel ist 6.18.4
Linbo 4.3.31-0
Die Notebooks sind Lenovo Thinkbook G5 und werden mit USB-C Netzwerkadaptern geklont.
Das hatte mit Linuxmuster 7.2 funktioniert. Offenbar kennt der aktuelle Linbo Kernel den USB Adapter nicht mehr, da das Notebook keine IP-Adresse beim Linbo Boot bekommt. Der PXE-Boot liefert im Syslog durchaus die IP zurück, aber der Linbo Kernel kann damit wohl nicht.
Ich kann also mit linbo-remote die Notebooks nicht erreichen.
Wie kann ich, um das zu verifizieren einen anderen Linbo Kernel booten?
Danke und viele Grüße
Klaus
Soeben in einem anderen Post die Möglichkeit gefunden einen Custom Kernel zu booten.
Mit Kernel 6.1.159 tritt das Problem nicht auf.
@thomas
Könntest Du Dir das bitte anschaun?
@baumhof
Evtl könntest Du das an Thomas weiterleiten. Meine Posts wurden in der Vergangenheit von ihm geblockt.
Danke und viele Grüße
Klaus
Hallo Klaus,
du hast ja schon eine Lösung gefunden.
Jetzt wollen wir mal schauen, welche Netzwerkkarte da nicht mehr geht (welcher Chip).
Ich Teile nämlich deine Analyse, dass der Treiber des USB Adapters im neuen Kernel fehlt.
Könntest du mal an einem Rechner, in dem der Adapter steckt, den Befehl
lspci
absetzen (also root).
Das geht auch am betroffenen Cleint mit linbo, wenn er mit einem anderen Kernel gebootet wurde (vielelicht sogar mit dem Orginalkernel).
Sehe ich es richtig, dass die anderen Clients im Netz kein Problem mit linbo 4.3.31 hatten?
LG
Holger
Hallo Holger,
mit dem Longterm Kernel funktioniert der USB-Adapter ebenfalls. Nur nicht mit dem aktuellen Stable Kernel. Bei älteren Thinkbooks, welche mit Linbo 7.2 und den USB-C Netzwerkadaptern problemlos funktioniert hatten gibt es dasselbe Problem mit dem Stable Kernel. Der Longterm oder Legacy Kernel funktionieren hier ebenso.
Ich komme gar nicht soweit, daß Linbo vollständig geladen wird. Wenn ich einen Dauerping laufen lasse, sehe ich daß die initrd geladen werden soll. Zu diesem Zeitpunkt kommt genau ein einziger Ping vom Server zum Client durch. Anschließend ist der Client nicht mehr im Netzwerk erreichbar und die initrd wird nicht vollständig geladen. Dort hängt er also fest.
Die älteren Thinkbooks bleiben dann bei der Meldung des Topics in diesem Thread hängen und sind ebenfalls nicht mehr erreichbar.
Leider bin ich jetzt eine Woche nicht mehr in der Schule um hier weiter zu testen und die Hardwarekonfiguration auszulesen. Eventuell findet @thomas ja bereits mit der Beschreibung den Fehler.
Danke und viele Grüße
Klaus
Hallo,
ich habe dazu weiter getestet und das Problem in einer VirtualBox Umgebung reproduzieren können.
- lmn 7.3 auf dem aktuellen Softwarestand von heute
- Leere, unpartitionierte virtuelle Platte im Windows 10 Client
- keine Einträge in /srv/linbo/linbocmd/
- UEFI Boot mit KernelOptions = quiet splash dhcpretry=15
- Der Boot Vorgang bleibt mit der Meldung des Threads stehen
- Egal welcher Kernel. stable, longterm oder legacy
Der Client ist dann per linbo-ssh vom Server aus erreichbar
Wenn ich dann zum Test ein onboot command file erstelle, dann wird dieses nicht ausgeführt. Ich kann den Client also nicht klonen.
Viele Grüße
Klaus
Hallo Klaus,
welche Netzwerkkarte (Typ) war den in den virtuellen Client „eingebaut“?
War der Client aufgenommen?
Welche IP hat er den bei PXE bekommen?
LG
Holger
Hallo Holger,
danke für Deine Fragen.
Ich erlaube mir diese zu ignorieren, weil ich eine Erklärung für das VirtualBox Verhalten liefern kann. Es war mein Fehler und ist nicht vergleichbar mit dem Problem in der Schule.
Wegen Deiner Fragen habe ich die virtuelle Umgebung nochmal gestartet und plötzlich geht das wieder. Grund ist, daß ich vor der Partitionierung des Clients das vorhandene Windows 10 auf dem Client durch „new“ nach dem 7.3 Upgrade zum Test neu klonen wollte. Der Torrent lief nicht los und irgendwann hat Linbo dann auf rsync gewechselt. Ich wollte den Prozess stoppen, aber der rsync Prozess lief noch. Also habe ich den rsync Prozess auf der Kommandozeile abgebrochen. Weil ich gründlich sein wollte, habe ich auch den rsyncd terminiert. Das war wohl der Fehler. Nach dem Serverneustart läuft der rsyncd wieder und das „Problem“ ist behoben.
In der Schule ist das aber nicht der Grund, weil dort der rsyncd läuft.
Sorry für die Verwirrung und die unbrauchbare Analyse im letzten Post.
Viele Grüße
Klaus