Hallo an alle!
Ich muss vorab gestehen das ich kein wirklicher Linux Spezialist bin. Ich hoffe das mein Problem nicht allzu trivial ist.
Wir haben auf einer VMWare (3.5U5) eine Opensuse 10.3 (Kernel: 2.6.22.12-0.1) laufen wo ein IBMDirector unsere Server seit Jahren problemlos überwacht. Nun haben wir vor einigen Tagen am VMWare das U5 installiert und ich musste das System habe neu starten. Nach dem Neustart wird die Netzwerkkarte nicht mehr aktiviert. Beim Booten erscheinen folgende Einträge:
(Siehe Bild: http://download.lenze.at/ibm/err_IBMDirectorNetwork.png
Hat jemand einen Tipp für wie ich das Netzwerk wieder hinbekomme? Oder wie kann ich zumindest mal den Grund herausfinden. Die unter VM definierte Netzwerkkarte ist aktiv und auch an das richtige Netzwerk angehängt.
Danke für alle Informationen im voraus!
Wilfried
Danke, das war’s, was mir vorhin nicht einfallen wollte. Jetzt kann ich mir das Suchen sparen.
Schaden kann es nichts. Aber das wird nichts bringen. Das Gerät wird ja gar nicht gefunden. Statt dessen gibt es ein eth2, das nicht konfiguriert ist. Ich vermute ganz stark, dass die Bezeichnung der NIC bei VMware geändert wurde und Suse das “neue” Gerät eth2 genannt hat und das alte ist eben nicht mehr da.
Ich erinnere mich allerdings auch sehr dunkel an ein Phänomen mit irgendeiner älteren Suse. Das Problem war, dass bei jedem Systemstart ein neues eth auftauchte. Also eth0 beim ersten, eth1 beim zweiten, eth2 beim dritten Start usw. Das ist allerdings nur noch eine sehr trübe Erinnerung.
Och, so eine watch dog kann ruhig auf einer alten Suse laufen, solange das Teil nicht von außen ansprechbar ist. Es sei denn, man traut den eigenen Usern nicht über den Weg.
Doch wird es, denn in der Ausgabe wird man sämtliche verfügbaren NICs sowie sämtliche in der obigen udev-Regel enthaltenen devices und deren MAC-Adresse sehen.
Wo ein eth1 ist (war?) auch sicher ein eth0 und wenn die auch umbenannt wurde, dann hat man das Problem vielleicht doppelt.
Normalerweise würde ich nämlich die “Deppenmethode” vorschlagen (obige udev-Regel löschen und Kiste neu starten), aber bei zwei Karten kann das ins Auge gehen, wenn dann auf einmal eth0 und eth1 vertauscht werden (woher sollte udev das auch wissen, das wird eben EINMAL mehr oder minder zufällig festgelegt).
//Edit:
Je nach Version des Scripts, ist der Inhalt der 70-persistent-net.rules nicht mehr in der Standardausgabe drin, dann deren Inhalt noch zusätzlich posten (und ich werde mal den Autor anschreiben, ob man das nicht besser wieder hinzufügen sollte).
Auch wenn es der default ist, so muß man die Zuordnung des Devicenamens nicht an die MAC-Adresse binden, sondern kann statt dessen den physikalischen Anschluss in die entsprechende udev-Regel einbinden.
YaST bietet das auch in der Konfiguration der Netzwerkgeräte unter “Hardware” an (heisst soviel ich weiß “BUS-ID”), dann kann sich die MAC-Adresse eines Gerätes auch mal ändern (z.B. wenn man eine PCI-Netzwerkkarte durch eine andere ersetzt, also “alte Karte raus, neue Karte rein”) ohne daß sich gleich alle Devicenamen ändern.
In “udev speak” heisst es dann eben nicht mehr
ATTR{address}=="MA:CA:DR:ES:SE"
sondern
KERNELS=="0000:PCI(E)-SLOT"
.
Beispiel (meine Kiste hier):
WLAN-Karte
lspci | grep WiFi
**0e:00.0** Network controller: Intel Corporation Ultimate N WiFi Link 5300
Sollte ich eines Tages (wir wollen es nicht hoffen) meine mini-PCIe WLAN-Karte gegen eine andere mini-PCIe austauschen müssen, dann wird sie ohne Änderung wieder “wlan0” heissen, denn der Anschluß hat sich ja bei diesem “Umbau” nicht geändert.
Bei einer udev-Regel basierend auf der MAC-Adresse ist das mit an Sicherheit grenzender Wahrscheinlichkeit nicht so einfach (der Thread hier ist wahrscheinlich ein gutes Beispiel dafür, daß es dabei “nur” um “virtuelle” Geräte geht, ist irrelevant).
