Netzwerkboot an UCC scheitert über Switch (Netgear)

german

#1

Hallo Freunde,

weil es so schön ist, hier noch ein weiteres zur Installation der paedML-Linux 6.x:

Unsere Umgebung ist wie folgt aufgebaut:

Server (Pädagogik) hängt an Netgear ProSafe GS724T Switch --> via LWL an Netgear ProSafe GS748Tv5 Switch --> via LWL an Netgear ProSafe GS748Tv5 --> Verteilerfeld Computerraum

Soweit so gut. Die Switche können untereinander kommunizieren - auch angeschlossene Netzwerkgeräte sehen sich und können Kommunizieren. Wichtig: schon vorinstallierte Arbeitstationen verhalten sich ganz normal - Zugriffe und OPSi usw. laufen /kommunizieren so wie vorgesehen… eben nur die UCC-kommunikation scheitert…

Der virtuelle Zugriff auf UCC über den ESXi (als VM ohne HDD eingerichten, rein Netboot) klappt einwandfrei.

Hier in der Werkstatt habe ich 3 Arbeitsstationen vorinstalliert über das festgelegte Verfahren; Arbeitsstationen bei Erstanmeldung über LAN an UCC gebootet und darüber auf OPSI/Server angemeldet.
Genutzt wurden stinknormale 15EUR Gigabit-Switche - zum Vergleich mit den Netgear jenseits der 150EUR :-/

Vor Ort versuche ich die gleiche Vorgehensweise und scheitere total. Die Arbeitsstation versucht zu booten, es wird auch angezeigt das ein DHCP gefunden wird und er fängt an das kleine Netboot Image / Linux-Client zu laden. Wenn dann der Hinweis oben links kommt, “starte DHCP client…” stürzt es ab bzw. scheitert mit weiterem Booten mit der Meldung “ERROR: A local boot device was not found…”

Da wird wohl das local boot device vom UCC gemeint…

Zur Info: LAN-Kabel sind es nicht, Dosen auch nicht und wir reden hier von ca. 110 Arbeitsstationen mit gleichem Ergebnis :wink:

Ich habe mal beide Bilder der Fehler angehängt.


und


Zum Verständnis:
– wenn ich den Client DIREKT an die Netzwerkkarte hänge, klappt alles wunderbar - Starten des UCC-Clients und Anmeldung klappt.
– wenn ich das Obige direkt über den Switch versuche, scheitert er nach kurzem Moment.

Ich meine mich dunkel zu erinnern, schonmal etwas in der Richtung gelesen zu haben? Beißt sich da eventuell etwas auf Linux-Ebene beim Switch mit dem Server?
Es liegt auf jeden Fall an Kommunikation ÜBER/mit Switche…

An die Herren Entwickler oder Erfahrene…gab/gibt es ähnliche Meldungen oder Erfahrungen - ggfls. mit anderen Switch-herstellern? Wenn ja, Workaround möglich? 110 Rechnern die MAC zu entlocken und dann alles händisch machen ist keine Lösung - und dem Kunden nun zu verklickern, dass er wieder andere, auch so endsteure Switche kaufen muss - sollte erstmal vermieden werden.

Na denn, rettet mir die Woche :wink: Bitte…

Marcus


#2

Hallo Marcus,

das Problem ist bisher nicht bekannt. Vorweg eine Frage: wird der Client im Subnetz der paedML Linux Server betrieben oder läuft der Client in einem eigenen Subnetz, dass über die Dokumentation Netzerweiterung erstellt wurde? Im letzteren Fall sollte versucht werden die Optionen “Portfast” und “Spanningtree” am Switch zu deaktivieren.

Meine Vermutung ist, dass das Problem beim Switch liegt. Lässt sich der paedML Linux Server über den Port, an dem der Client angeschlossen ist per Ping und HTTPS erreichen?

Zur weiteren Fehleranalyse empfehle ich den Kontakt zur Linux Hotline des LMZ zu nutzen.

Viele Grüße,

Jan Christoph