Hallo.
Wir haben ein merkwürdiges Problem, das wir nicht so richtig einkreisen können: Startet man in einem Raum mit 16 Clients alle PCs, läuft alles wunderbar. Kommt ein zweiter Raum dazu, kommt LINBO zum Teil nicht mehr aus den Socken. Der grüne Startbildschirm (V6.1) erscheint noch – und dann war’s das. DHCP läuft dabei IMMER problemlos. Das Problem taucht erst danach auf, genauergesagt, sobald LINBO starten soll.
Wenn man dort den debug-Modus anwählt, hat man sehr kurz Zeit, um am LINBO-Prompt “debug” einzugeben. Dann dauert es aber EWIG, bis der Kernel und das linbofs geladen sind. Irgendwann läuft es dann durch. dmesg zeigt nichts ungewöhnliches, bis auf die Tatsache, dass es RTL8169-Treiber sind, die ja schon öfter Probleme gemacht haben??
(Es sind übrigens alles ASUS M5A78L-M LE Boards mit BIOS V13.01)
Bis vor der Umstellung von 6.0 auf 6.1 gab es dieses Problem nicht – die Hardware dürfte also in Ordnung sein. Wir vermuten im Moment, dass es mit der LINBO-Version 2.2.16 oder dem verwendeten LINBO-Kernel zusammenhängen könnte?? Aber da es immer andere Clients sind, die dann nicht oder nur EXTREM zäh starten, ist das Problem sehr schwer einzugrenzen.
Auf dem Switch haben wir auch schon geschaut – es tritt wieder dieses seltsame Phänomen auf, dass die DLink-Switche auf allen LEDs gleichmäßig blinken, wenn ein Client da nicht weiter kommt. Das hatte ich neulich schon mal beobachtet und gepostet. Damals wurde ein Zusammenhang mit PXE + Spanning Tree vermutet, doch das ist jetzt überall deaktiviert!
Wer hat eine brauchbare Idee, wonach wir da suchen können?
rollt ihr dabei ein Image aus, dh. läuft torrent mit? Ich hatte dann das Problem, dass die torrents das Netzwerk ausgebremst haben und linbo sehr lange für seinen boot brauchte (die, die eben später dran waren).
Ich habe u.a. deswegen auf HDD-Boot umgestellt (spart bei mir ca. 20 sek pro boot, ein weiterer Grund). Einziger Wermutstropfen: Bei einer neuen Festplatte muss man den Boot auf Ethernet umstellen oder mit dem Stick ran.
Nein, währenddessen ist nichts los im Netz. Das seltsame ist wie gesagt, dass DHCP ganz am Anfang immer klappt aber PXE danach nicht mehr; und zwar direkt am Anfang.
Hm, ich weiß, dass TFTP sehr langsam ist. Wie stark sich das kumuliert, kann ich nicht testen, da ich HDD boot habe. Wie schaut es denn mit der Serverlast zu dem Zeitpunkt aus (auf der Konsole “top” eingeben, mit “q” beenden)?
kannst Du den ganzen Vorgang mal beobachten, indem Du am Server, Konsole 1, eingibst:
tail -f /var/log/syslog
und an einer zweiten Konsole dann:
linbo-remote -w 1 -g [Gruppenname Deiner Rechner]
(ggf. nochmals für die zweite Gruppe im anderen Raum)
Dann schau mal, ob an der Konsole, bei der Du den tail-Befehl abgesetzt hast, sowas kommt:
Apr 24 23:25:09 server dhcpd: DHCPDISCOVER from 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:09 server dhcpd: DHCPOFFER on 10.16.8.27 to 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:09 server dhcpd: DHCPDISCOVER from 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:09 server dhcpd: DHCPOFFER on 10.16.8.43 to 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:10 server dhcpd: DHCPDISCOVER from 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:10 server dhcpd: DHCPOFFER on 10.16.8.23 to 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:10 server dhcpd: DHCPDISCOVER from 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:10 server dhcpd: DHCPOFFER on 10.16.8.30 to 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:10 server dhcpd: DHCPDISCOVER from 00:22:68:53:f7:19 via eth0
Apr 24 23:25:10 server dhcpd: DHCPOFFER on 10.16.8.26 to 00:22:68:53:f7:19 via eth0
Apr 24 23:25:11 server dhcpd: DHCPREQUEST for 10.16.8.27 (10.16.1.1) from 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:11 server dhcpd: DHCPACK on 10.16.8.27 to 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:11 server dhcpd: DHCPREQUEST for 10.16.8.27 from 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:11 server dhcpd: DHCPACK on 10.16.8.27 to 00:1f:e2:4f:8e:43 via eth0
Apr 24 23:25:11 server dhcpd: DHCPREQUEST for 10.16.8.43 (10.16.1.1) from 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:11 server dhcpd: DHCPACK on 10.16.8.43 to 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:11 server dhcpd: DHCPREQUEST for 10.16.8.43 from 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:11 server dhcpd: DHCPACK on 10.16.8.43 to 00:1f:e2:4f:8d:f5 via eth0
Apr 24 23:25:12 server dhcpd: DHCPREQUEST for 10.16.8.23 (10.16.1.1) from 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:12 server dhcpd: DHCPACK on 10.16.8.23 to 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:12 server dhcpd: DHCPREQUEST for 10.16.8.23 from 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:12 server dhcpd: DHCPACK on 10.16.8.23 to 00:1f:e2:60:8f:bb via eth0
Apr 24 23:25:12 server in.tftpd[13751]: tftp: client does not accept options
Apr 24 23:25:12 server dhcpd: DHCPREQUEST for 10.16.8.30 (10.16.1.1) from 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:12 server dhcpd: DHCPACK on 10.16.8.30 to 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:12 server dhcpd: DHCPREQUEST for 10.16.8.30 from 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:12 server dhcpd: DHCPACK on 10.16.8.30 to 00:1f:e2:60:8f:bc via eth0
Apr 24 23:25:12 server in.tftpd[13758]: tftp: client does not accept options
Apr 24 23:25:13 server dhcpd: DHCPREQUEST for 10.16.8.26 (10.16.1.1) from 00:22:68:53:f7:19 via eth0
Apr 24 23:25:13 server dhcpd: DHCPACK on 10.16.8.26 to 00:22:68:53:f7:19 via eth0
Apr 24 23:25:13 server dhcpd: DHCPREQUEST for 10.16.8.26 from 00:22:68:53:f7:19 via eth0
Apr 24 23:25:13 server dhcpd: DHCPACK on 10.16.8.26 to 00:22:68:53:f7:19 via eth0
Apr 24 23:25:13 server in.tftpd[13789]: tftp: client does not accept options
Apr 24 23:25:13 server in.tftpd[13818]: tftp: client does not accept options
Apr 24 23:25:14 server in.tftpd[13861]: tftp: client does not accept options
Apr 24 23:25:14 server dhcpd: DHCPDISCOVER from 00:22:68:53:f7:2d via eth0
Apr 24 23:25:14 server dhcpd: DHCPOFFER on 10.16.1.70 to 00:22:68:53:f7:2d via eth0
Apr 24 23:25:14 server dhcpd: DHCPDISCOVER from 00:1f:e2:60:06:0a via eth0
usw.
Da müsste dann, wenn der Vorgang stockt, sich in dieser Logik etwas ändern.
Wenn Du etwas beobachtest, poste es hier doch mal !
Gruß Christoph G.