Cannot read network infos

Hallo Holger,
sorry für meine späte Antwort und danke für die Rückmeldung - ich hatte das schon fast befürchtet.
Durch ein anderes Problem mussten wir das Update auf die lmn 7.2 ohnehin vorziehen, sodass wir jetzt ein aktuelles linbo am Start haben.
Leider bootet der neue Rechner damit nach wie vor nicht. Die Symptomatik ist ganz ähnlich wie zuvor auch, der Teil über PXE klappt, aber nach einer kurzen Ladezeit bietet linbo nur noch Neustart oder Shutdown an. Ich weiß gerade nicht mehr, was im Wortlaut als Meldung angezeigt wird, aber es sieht wieder danach aus, als würde der Server nicht gefunden. Ich vermute daher, dass die Netzwerkkarte nach wie vor nicht erkannt wird. Der von linbo verwendete Kernel ist 6.12.33, iirc. Der ist ja quasi topaktuell, insofern würde es mich wundern, wenn da kein passender Treiber dabei wäre - aber vielleicht müsste ein passendes Kernelmodul geladen werden?!

Ich finde ohnehin sehr wenig dazu bezüglich Linux-Unterstützung des Netzwerkchips. Dachte erst, das Teil sei vielleicht sehr neu, aber hier gibt es einen vier Jahre alten Thread, in dem jemand über Probleme damit klagt: https://askubuntu.com/questions/1318569/how-can-i-get-my-realtek-rtl8111-8168b-nic-working

Jedenfalls weiß ich gerade nicht so recht weiter, wie ich untersuchen könnte, ob das Problem wirklich daran liegt, dass die Karte nicht erkannt wird und - falls dem so ist - wie man es denn dann lösen könnte. Daher bin ich für sämtliche Tipps dankbar.

Hallo,

Bei mir lag es an dem Spanning-Tree-Protocol der Switche und ich löse es so:

Neue Rechner werden an einem unkonfigurierten alten HP-Switch aufgenommen. Da der kein RSTP macht, habe ich so kein Problem mit einem DHCP-timeout bei LINBO. Alternativ schalte ich RSTP an dem UNIFI-Switch vorübergehend aus, an dem die neuen Rechner hängen, die aufgenommen werden sollen.

MfG!
Stefan

1 „Gefällt mir“

Hallo Philipp
Hallo Stefan,
Danke für den Hinweis @S.Senft :slight_smile:
Ich halte es auch für eher unwahrscheinlich, dass die Netzwerkkarte von linbo nicht unterstützt wird: das erleben wir vielleicht alle 3 Jahre mal, dass sowas passiert (ja, hier im Thread war das so … ist aber schon 2,5 Jahre her …).

Ich hatte das

  1. PXE Boot klappt
  2. linbo kommt hoch mit seinem „Grafischen“ LINBO schriftzug auf der Console
  3. linbo schreibt hin 1) für shutdown 2) für Reboot (oder so)
    auch schon mehrmals.
    Einmal ganz schlimm bei mir ZUhause im Testnetzt: plötzlich zeigten alle Rechner die ich per PXE bootete diesen Bildschirm … stellte sich heraus: Switch war hin. Nich Tot an sich: der tat noch so, als würde er gehen: aber so richtig ging er nicht mehr.
    Neuer Switch, alles gut.

Manchmal hab ich es in der Schule: da passiert es, wenn ich einen Rechner, der in Subnetz 15 gehört an einer Dose in Subnetz 22 gebootet wird (also außerhalb seines Subnetzes).

Aber ich meine, ich hatte das auch schon, wenn was in der start.conf nicht stimmte.

Bitte teste doch mal:

  1. sichere deine /srv/linbo/start.conf.GRUPPE
  2. kopier eine saubere aus /srv/linbo/examples/start.conf.IRGENDEINE nach /srv/linbo/start.conf.GRUPP
  3. lass linuxmuster-import-devices laufen
  4. starte deinen Client.

Versuch es auch mal an einem anderen Switch …

LG
Holger

1 „Gefällt mir“

Vielen Dank @S.Senft und @baumhof für Eure Tipps. Ich werde das ausprobieren!

Wir haben ausprobiert, den PC an einen „einfachen“ Switch zu hängen, und damit hat es tatsächlich funktioniert. :blush:

Nochmals vielen Dank für eure Hilfe.

Hallo,

bei mir hat sogar mal der Austausch des Netzwerkkabels gereicht, dass das Problem weg ging…

LG
Holger

Hallo Entwickerl,

kann man das Problem mit dem „Spannung-Tree lässt LINBO scheitern“ irgendwie so lösen, dass LINBO es etwas länger probiert, die „netwok infos“ zu lesen?
Das wäre gerade für linuxmuster-Einsteiger eine Stolperfalle weniger.

Beste Wünsche!
Stefan

1 „Gefällt mir“

Hi,

wenn die manche Switche bis zu 30 Sekunden benötigen, um die Weiterleitung der Datenpakete auf dem Port zu aktivieren, hat man - denke ich - zwei Optionen:

  1. (Rapid) Spanning Tree für Ports der Endgeräte ausschalten (bevorzugt)
  2. Im Linbo die Option für dhcpretry auf einen sehr hohen Wert setzen. Das verzögert aber auch Bootvorgänge ohne Netzwerk und umgeht ein Netzwerkproblem auf Anwendungsebene.

Zu 1.: Das (Rapid) Spanning Tree Protocol ist dafür gedacht in der Netzwerk-Topologie schleifenfreie Verbindungen zu ermöglichen. Netzwerk-Topologie meint hier explizit Switch-zu-Switch-Verbindungen, um bspw. verschiedenen Etagen- oder Gebäudeverteiler in einem Ring zu verbinden für den Fall, dass dort eine Verbindung ausfällt. Es ist nicht dafür gedacht die Kabelverbindungen an sogenannten Access-Ports (auch: Edge-Ports), wo Endgeräte angeschlossen werden zu prüfen, ob da jemand „aus Versehen“ ein Kabel links und rechts in die Netzwerkdoppeldose steckt. Nahezu alle managed Switches bieten die Option Ports als Access-Ports zu definieren und leiten dann die Ethernet-Pakete sofort (nach max. 1-3 Sekunden) nach dem aktiv werden des Ports (durch Anstecken des Netzwerkkabels oder Einschalten des Geräts) weiter.

Die korrekte Lösung wäre die Switches korrekt zu konfigurieren oder konfigurieren zu lassen.

Mittlerweile steht sogar im Artikel Rapid Spanning Tree Protocol – Wikipedia

Für die schnelle Umschaltung ist es notwendig, dass der Administrator bei der Konfiguration der Switches für jeden Port festlegt, um welchen Typen es sich handelt.
Edge-Ports sind Ports, die ausschließlich zu Endstationen verbinden (Arbeitsstationen, Server etc.). Dort können keine Schleifen entstehen und es treten keine BPDUs auf. Diese Ports werden bei der Neuordnung schnell umgeschaltet. Empfängt ein solcher Port eine BPDU, verliert er seinen Edge-Status

(BPDU sind Datenpakete mit Konfigurationsnachrichten, die nur Switch-artige Netzwerkgeräte aussenden.)

VG
Buster

1 „Gefällt mir“

Hallo Buster,

Danke für die Erläuterung!
Dann bleibe ich beim „Switch ohne Spanning Tree“ für die Rechneraufnahme. Ist für mich der einfachste Weg.

MbW!
Stefan