rohrbold
Anmeldungsdatum: 6. Mai 2006
Beiträge: Zähle...
Wohnort: Stuttgart
|
Hallo beisammen, wir haben 24 neue Testbettrechner, die jeweils mit zwei Onboard-Netzwerkkarten und zusätzlich einem Intel 82574L Controller mit vier weiteren Interfaces ausgestattet ist, also insgesamt sechs Netzwerkschnittstellen bietet.
Dummerweise initialisiert Ubuntu (10.10 64bit Server) diese Schnittstellen bei jeder Installation unterschiedlich, so dass die Benamung von eth0 bis eth5 immer unterschiedlich ausfällt. Ich weiß, dass ich über udev-Regeln speziellen MAC-Adressen einen eth-Namen geben kann. Allerdings müsste ich das dann für jeden Rechner manuell und nach jeder neuen Installation betätigen.
Wenn ich sudo lshw -class network eingebe, werden mir auch zuerst die vier Schnittstellen des 82574L Controllers und danach die der beiden Onboard-Karten ausgegeben.
Das würde ich gerne nutzen, um entsprechend die eth-Bezeichnungen zu vergeben. Weiß jemand, wie man das hinbekommen kann? Vielen Dank,
Martin
|
theinlein
Anmeldungsdatum: 29. Dezember 2007
Beiträge: 1279
|
Hallo, Das ist ein sch... typisches LINUX Problem.
Die Namen werden vom Kernel vergeben und die Reihenfolge hängt irgendwie vom Detektieren der Karten ab, also irgendwie ein Gerangel der Netzwerkkarten am Bus beim Installieren. Auf Suse Enterprise SLES 11 hatte ich das mal mit einem Script gelöst: Hatte heraus gefunden, wie der Zusammenhang zwischen PCI-Bus-Adresse (lspci) und Anschlussbezeichnung auf dem Gerät war.
Irgendwie habe ich dann einen Weg gefunden, wie man MAC-Adresse und PCI-ID in Zusammenhang setzen kann (ip Commando).
Dann hat das Script die Config unter /etc/networks .... geändert. Kann da jetzt leider nicht ran ☹ Ich glaube, es gibt da keine einfache UDEV-Lösung (?)
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16333
|
die zuständige udev-Regel /etc/udev/rules.d/70-persistent-net.rules kann man imho ändern so daß nicht die MAC-Adresse herangezogen wird sondern die dev_id SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
hier sollte man ansetzen
|
rohrbold
(Themenstarter)
Anmeldungsdatum: 6. Mai 2006
Beiträge: 13
Wohnort: Stuttgart
|
Leider ist die dev_id für alle Karten gleich. ☹
Hier mal die Udevadm-Ausgabe für eine Onboard (eth2 und eth5 – hier eth2) und eine der extra-Karten (eth0, eth1, eth3, eth4 – hier eth0):
sudo udevadm info -a -p /sys/class/net/eth0
looking at device '/devices/pci0000:00/0000:00:03.0/0000:01:00.0/net/eth0':
KERNEL=="eth0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{dev_id}=="0x0"
ATTR{ifalias}==""
ATTR{iflink}=="2"
ATTR{ifindex}=="2"
ATTR{features}=="0x2114bb3"
ATTR{type}=="1"
ATTR{link_mode}=="0"
ATTR{address}=="00:1b:21:8b:83:90"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{carrier}=="1"
ATTR{speed}=="1000"
ATTR{duplex}=="full"
ATTR{dormant}=="0"
ATTR{operstate}=="up"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1003"
ATTR{tx_queue_len}=="1000"
looking at parent device '/devices/pci0000:00/0000:00:03.0/0000:01:00.0':
KERNELS=="0000:01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x150e"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{subsystem_device}=="0x12a1"
ATTRS{class}=="0x020000"
ATTRS{irq}=="16"
ATTRS{local_cpus}=="00000000,0000000f"
ATTRS{local_cpulist}=="0-3"
ATTRS{modalias}=="pci:v00008086d0000150Esv00008086sd000012A1bc02sc00i00"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="64"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00/0000:00:03.0':
KERNELS=="0000:00:03.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0xd138"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{subsystem_device}=="0x83d8"
ATTRS{class}=="0x060400"
ATTRS{irq}=="45"
ATTRS{local_cpus}=="00000000,0000000f"
ATTRS{local_cpulist}=="0-3"
ATTRS{modalias}=="pci:v00008086d0000D138sv00001043sd000083D8bc06sc04i00"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{enable}=="2"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS=="" sudo udevadm info -a -p /sys/class/net/eth2
looking at device '/devices/pci0000:00/0000:00:1c.6/0000:05:00.0/net/eth2':
KERNEL=="eth2"
SUBSYSTEM=="net"
DRIVER==""
ATTR{addr_len}=="6"
ATTR{dev_id}=="0x0"
ATTR{ifalias}==""
ATTR{iflink}=="3"
ATTR{ifindex}=="3"
ATTR{features}=="0x110ba9"
ATTR{type}=="1"
ATTR{link_mode}=="0"
ATTR{address}=="bc:ae:c5:16:6e:78"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{operstate}=="down"
ATTR{mtu}=="1500"
ATTR{flags}=="0x1002"
ATTR{tx_queue_len}=="1000"
looking at parent device '/devices/pci0000:00/0000:00:1c.6/0000:05:00.0':
KERNELS=="0000:05:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="e1000e"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x10d3"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{subsystem_device}=="0x8369"
ATTRS{class}=="0x020000"
ATTRS{irq}=="18"
ATTRS{local_cpus}=="00000000,0000000f"
ATTRS{local_cpulist}=="0-3"
ATTRS{modalias}=="pci:v00008086d000010D3sv00001043sd00008369bc02sc00i00"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="64"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00/0000:00:1c.6':
KERNELS=="0000:00:1c.6"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x3b4e"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{subsystem_device}=="0x83d8"
ATTRS{class}=="0x060400"
ATTRS{irq}=="49"
ATTRS{local_cpus}=="00000000,0000000f"
ATTRS{local_cpulist}=="0-3"
ATTRS{modalias}=="pci:v00008086d00003B4Esv00001043sd000083D8bc06sc04i00"
ATTRS{numa_node}=="-1"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{enable}=="2"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS=="" Ich fürchte mir gibt das net-Subsystem keine spezifischere Information für etwaige udev-Regeln aus, als letztlich die MAC-Adresse selbst. Vielleicht kann ich aber eine 70-persistent-net.rules Datei anlegen, in der die MAC-Adressen aller 25 mal 6 Netzwerkkarten angelegt sind und die ich dann nach einer Installation einspielen muss. Leider viel Aufwand, sehr statisch und erstmal sehr Ubuntu-spezifisch ...
|
elektronenblitz63
Anmeldungsdatum: 16. Januar 2007
Beiträge: 29307
Wohnort: NRW
|
Hallo, oder auch von der MAC-Adresse auf die jeweilige PCI BUS-ID umstellen:. Das ist auch eindeutig. Natürlich für jede Karte entsprechend ändern.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ID=="0000:00:19.0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Die PCI Bus-ID zeigt
lspci | grep Ether
Beispiel:
00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02)
|
rohrbold
(Themenstarter)
Anmeldungsdatum: 6. Mai 2006
Beiträge: 13
Wohnort: Stuttgart
|
Ok, jetzt kommen wir der Sache vermutlich schon sehr nahe. ☺
Mit einer Dummheit schlage ich mich aber noch herum: Wenn ich die 70-persistent-net.rules Datei ändere und danach neustarte, erhalte ich das wohlbekannte Phänomen, dass die Interfaces, die mir angeboten werden, hochgezählt wurden (dann eth6 bis eth10 und ein eth5-eth6) und die 70-persistent-net.rules Datei nach meinen Zeilen wieder neu generierte Zeilen für ebenjene Interfaces anhängt.
Wie gewöhne ich ihm dieses Neu-generieren ab?
|
rohrbold
(Themenstarter)
Anmeldungsdatum: 6. Mai 2006
Beiträge: 13
Wohnort: Stuttgart
|
Potzblitz, es geht. In einem anderen Foreneintrag habe ich ebenfalls von elektronenblitz63 den gleichen Lösungsvorschlag gelesen, nochmal genauer hingeschaut und festgestellt, dass ich bei mir vergessen hatte, die "0000:" Sequenz der PCI-ID voranzusetzen. Seitdem ich das getan habe funktioniert alles genau so, wie ich das haben will ☺
Tausend Dank.
|
adun
Anmeldungsdatum: 29. März 2005
Beiträge: 8606
|
Nur so nebenbei, der aktuelle unstable Kernel räumt mit dem Schwachsinn auf, das neue eindeutige Schema ist pci<slot>#<port>. Bei ner späteren Migration wird dir das womöglich um die Ohren fliegen, vielleicht in der Doku schon mal als Warnung vermerken.
|
elektronenblitz63
Anmeldungsdatum: 16. Januar 2007
Beiträge: 29307
Wohnort: NRW
|
Nur so nebenbei, der aktuelle unstable Kernel räumt mit dem Schwachsinn auf, das neue eindeutige Schema ist pci<slot>#<port>. Bei ner späteren Migration wird dir das womöglich um die Ohren fliegen, vielleicht in der Doku schon mal als Warnung vermerken.
Bislang genügte es dann die /etc/udev/rules.d/70-persistent-net.rules zu löschen/sichern und neu zu erzeugen. Beispielweise auch nach einem Systemwechsel oder Austausch einzelner LAN-Karten.
sudo udevadm trigger
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16333
|
adun schrieb: Nur so nebenbei, der aktuelle unstable Kernel räumt mit dem Schwachsinn auf, das neue eindeutige Schema ist pci<slot>#<port>.
kann man u.U. jetzt schon haben: http://linux.die.net/man/1/biosdevname http://linux.dell.com/files/biosdevname/
|