der Computerraum der von mir betreuten Schule ist nun einige Zeit nicht benutzbar gewesen, hat aber einmal vollkommen problemlos mit LINBO an einem LMN 6.2-Server gelaufen. Dieser Server ist seit einem Jahr zu LMN 7.1 migriert und ich habe mir nun endlich wieder Zeit für den Computerraum genommen, scheitere aber bisher daran, LINBO zum Laufen zu bekommen (in meinem Heim-Testnetzwerk funktioniert das alles prima).
Die bisherigen Schritte sahen so aus:
Client über PXE booten - nichts ging
Client mit MAC- und IP-Adresse in der Schulkonsole eingetragen > Client bekommt IP-Adresse (s. Bild unten)
Aber: LINBO startet nicht: es wird ein ARP timeout sowie die Fehlermeldung „TFTP cannot open connection“ angezeigt:
Mein Kollege, der das Netzwerk (und früher auch den LMN 6.2-LINBO-Computerraum) sagt, dass es das Thema schon einmal gab, als das Netz auf Cisco umgebaut wurde. Dort dauert das Spanning-Tree-Protokoll zu lange, so dass es zu den Timeouts kommt. Daher ist bei allen Ports spanning-tree portfast edge eingestellt. Und wie gesagt: mit LMN6.2-Server und LINBO hat schon alles funktioniert, ohne dass es mir bekannte Änderungen am Netzwerk gegeben hätte.
Da ich dazu nicht viel in ask gefunden habe, die Frage an den Kreis: wer kann mir einen Tipp geben, wie ich das nun am besten debugge? Am Sonntag soll das Wetter schlecht werden und ich werde vermutlich mal schauen, ob ich das nicht zum Laufen bekomme …
nach dem screenshot zu urteilen ist das kein linbo Problem: linbo wird
ja schon nicht geladen.
Das ist entweder ein Netzwerkproblem, oder der tftp auf dem Server läuft
nicht, aber das hast du ja schon nachgeschaut.
Irgend was an dhcpretry rumstellen in linbo bringt also nichts.
Also: switches richtig konfigurieren.
Du kannst ja mal testen und den cisco gegen einen
feldwaldundwiesenswitch tauschen und dann nochmal testen.
ich kann Holgers Aussagen nur unterstützen. Der ARP-timeout-Fehler kommt bei mir, wenn unser LINBO-Server (bei uns ist das ein Cache-Server, weil LMN-Server im netzint-Rechenzentrum) ausgefallen ist.
Also z.B. am besten mal einen Client möglichst direkt an den Server hängen!
Ich hatte ehemals bei der Migration 6.2 > 7.1 den 7.1-Server eine Zeit lang parallel zum 6.2 laufen. Zu der Zeit hatte er die IP 10.32.1.2. Aus der Zeit muss noch die Zeile
next-server 10.32.1.2;
in der /etc/dhcp/dhcpd.conf übrig geblieben sein. Seitdem ich das auf 10.32.1.1 (die IP meines Servers jetzt) geändert habe, ist der ARP timeout auch weg.
Jetzt habe ich aber noch ein übriges Relikt aus der Zeit, das noch Ärger macht: führe ich ein linuxmuster-import-devices durch, schreibt mir das Script jedes Mal
[LINBO]
Server = 10.32.1.2
in die betroffenen start.conf-Dateien. Wo holt sich das Script denn die IP her? Ich hab schon überall nach entsprechenden Quellen gesucht, bisher ohne Erfolg.
der Eintrag in der start.conf kann händisch bearbeitet werden und kommt initial aus einer der Vorlagendateien /srv/linbo/examples/start.conf.*. Diese werden, wenn ich das richtig verfolgt habe, beim Update durch den Wert aus /etc/linuxmuster/linbo/start.conf.default aktualisiert.
das hatte ich auch so gedacht. Kann ich nur in meinem Fall nicht bestätigen. Folgendes Prozedere:
start.conf.abc (abc=Name meiner HW-Klasse) mit ersten beiden Zeilen
[LINBO]
Server = 10.32.1.1
linuxmuster-import-devices ausführen, jetzt sehen die ersten beiden Zeilen so aus:
[LINBO]
Server = 10.32.1.2
Daraufhin habe ich mir alle start.conf*-Dateien im examples-Verzeichnis angeschaut. Überall stand noch Server = 10.32.1.2 drin. Ich habe alle fix durch 10.32.1.2 ersetzt und oben genanntes wieder ausprobiert. Selbes Ergebnis: nach linuxmuster-import-devices steht wieder der falsche Server 2 drin.
Nächster Schritt: in /srv/linbo liegen noch die start.conf-Dateien der Clients (z.B. start.conf-10.32.20.4). In allen Server = 10.32.1.2. Alles ersetzt:
grep -l "10.32.1.2" start* | xargs sed -i 's/10.32.1.2/10.32.1.1/'
Und Hurra! Nach linuxmuster-import-devices bleibt es bei
[LINBO]
Server = 10.32.1.1
Mein Problem ist also gelöst. Die Frage, die bleibt: Bug oder Feature, dass sich linuxmuster-import-devices irgendwas aus anderen start.conf-Dateien „sucht“?
Schönen Abend und vielen Dank für die Denkanstöße!
Jens
P.S.: In /etc/linuxmuster/linbo/start.conf.default stand zumindest seit gestern schon 10.32.1.1 drin. Trotzdem war das o.g. Verhalten heute noch reproduzierbar und ist erst durch das Ersetzen in allen start.conf-Dateien behoben.
