sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Linux => Thema gestartet von: SunFireT2000 am 07. August 2008, 00:39:37
-
Hallo!
Ich schaffe es nicht die zweite NIC meiner Netra T1 unter Debian 4.0 vernünftig zu nutzen. Nachdem ich sie mit "setenv pcib-probe-list 1,2,3" aktiviert hatte, wurde sie zwar erkannt, aber immer "eth1_rename_rename" genannt. Ich möchte aber dass sie eth1 heißt oder einen anderen kurzen Namen hat. Da beide NIC die gleiche MAC-Adresse haben, ist es nicht möglich, in /etc/udev/rules.d/z25_persistent-net.rules den Namen zu ändern. Kennt ihr eine Lösung für dieses Problem? Kann man vielleicht die MAC-Adresse der zweiten NIC ändern? Ich könnte dazu auch vorübergehend Solaris installieren.
Danke
Markus
-
Hier wird es erklärt:
ID 16733: Why do all my ethernet interfaces have the same ethernet MAC address? (http://www.sun-rays.org/lib/sunsolve/16733.html)
-
Danke, aber diese Seite beinhaltet keine Lösung für mein Problem. local-mac-address?=true funktioniert bei der (meiner?) Netra nicht, und das skriptgesteuerte Ändern der MAC-Adresse mit ifconfig hilft mir nicht, da ja nicht die doppelte MAC-Adresse das Problem ist, sondern die (durch die doppelte MAC-Adresse verursachte) Umbenennung von eth1 durch udev. Und bevor udev nicht konfiguriert ist, kann ich nicht ifconfig aufrufen.
Aber ich habe jetzt eine Lösung gefunden. Falls es jemanden interessiert: die Regeln in /etc/udev/rules.d/z25_persistent-net.rules müssen so aussehen:
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="08:00:20:c2:16:4c", ATTR{ifindex}=="2", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="08:00:20:c2:16:4c", ATTR{ifindex}=="3", NAME="eth1"
Durch "ifindex" können die NICs unterschieden werden. Die Werte für "ifindex" erhält man mit
udevinfo -a -p /sys/class/net/eth0
udevinfo -a -p /sys/class/net/eth1_rename_rename
Grüße
Markus
-
Dieses udev ist ja ne feine Sache für die Desktoprumstöpseler, die jeden Gimmik an ihren PC ranfrimmeln müssen. Im Serverbereich ist das Ganze eine Katastrophe.
Jeder der schonmal eine defekten NIC oder noch besser die sda tauschen durfte, freut sich darüber, das es keine eth0 mehr gibt, der Server nicht mehr bootet, weil die Bootplatte nicht erkannt wird usw. usf.
Wer sich diesen Mist ausgedacht hat, muss scheinbar keine Produktivsysteme betreuen.....
-
Hallo,
bei einem völlig anderen Problem hat mal irgendeiner drauf hingewiesen,
daß das hier ein Heimanwender-Forum ist.
Wenn also irgendwer zuhause auf seine SUN-Kisten ein Linux packt
und daran intensiv umkonfiguriert, ist sein eigener SysAdmin, und wenn
er dann keine konfigurierbare kiste mehr hat, weil hme0 oder was auch immer
nicht mehr da ist, ist er halt selbst schuld.
Wer seine SUN-Kiste zuhause so nutzt und es klappt - sehr gut.
Grüße vom Haasen
-
Hallo,
bei einem völlig anderen Problem hat mal irgendeiner drauf hingewiesen,
daß das hier ein Heimanwender-Forum ist.
Wenn also irgendwer zuhause auf seine SUN-Kisten ein Linux packt
und daran intensiv umkonfiguriert, ist sein eigener SysAdmin, und wenn
er dann keine konfigurierbare kiste mehr hat, weil hme0 oder was auch immer
nicht mehr da ist, ist er halt selbst schuld.
Wer seine SUN-Kiste zuhause so nutzt und es klappt - sehr gut.
Dessen bin ich mir bewusst. Meine Äusserungen sind eher als Kritik an diesem grottigem udev zu verstehen, als einen professionellen Support zu verlangen. Genausogut müsste man ja dann die Kritik am xorg-Treiber der XVR unter Solaris als böse verteufeln, die hier häufig geäussert wird.
Und was bitteschön ist daran nicht Heimanwender, wenn ich auf meine Sparkisten Linux drauftue? Soetwas würde ich im professionellem Umfeld nie tun, da selbst bei Debian die Unterstützung alles andere als gut ist.
Aber Du beschreibst genau den Heimanwenderfall, wo jemand Probleme hat, weil er die Kisten zu Hause mit Software beschickt, für die es keinen prof. Support gibt. Soetwas tun Heimanwender nun mal.
-
Jetzt wüsste ich aber zu gerne, wieso local-mac-address?=true nicht funktioniert auf Deiner V210?
# eeprom | grep local
local-mac-address?=true
# uname -a
SunOS sagichnicht 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V210
Gruss
Dominik
-
Jetzt wüsste ich aber zu gerne, wieso local-mac-address?=true nicht funktioniert auf Deiner V210?
# eeprom | grep local
local-mac-address?=true
# uname -a
SunOS sagichnicht 5.10 Generic_127111-06 sun4u sparc SUNW,Sun-Fire-V210
Gruss
Dominik
Meinst du mich? Ich habe keine V210 sondern eine Netra T1.
Markus
-
SunbFireT2000:
Oh, sorry! Da hab ich mich doch glatt verlesen. Was sagt denn 'eeprom | grep local'? Habe noch keine Sun erlebt, die diesen Parameter NICHT gehabt hätte. Meine Netra T1 105 sagt:
# uname -a
SunOS sagicherstrechtnicht 5.10 Generic_125100-09 sun4u sparc SUNW,UltraAX-i2
# eeprom | grep local
local-mac-address?=true
-
Der Parameter ist bekannt, hat aber keine Auswirkung:
netra:/home/markus# eeprom | grep local
local-mac-address?=true
netra:/home/markus# ifconfig -a | grep HWaddr
eth-IBK Link encap:Ethernet HWaddr 08:00:20:C2:16:4C
eth-M Link encap:Ethernet HWaddr 08:00:20:C2:16:4C
netra:/home/markus#
Ich habe die Beschreibung auf der von Ebbi empfohlenen Seite so verstanden, dass local-mac-address? nur bei neueren NICs funktioniert.
-
Zumindest unter Solaris gibts die Möglichkeit, die MAC-Adresse mit einem Eintrag unter /etc/ether.<if> zu ändern. Hab allerdings keine Ahnung ob das auch unter Linux funktioniert.
Dass das local-mac-adress? nicht greift ist sehr seltsam...
-
Unter Linux geht das mit
ifconfig eth-M hw ether 0A:00:20:C2:16:4C up
Aber wie ich schon geschrieben habe, hilft mir das nichts, da das Problem zu einem Zeitpunkt des Bootvorgangs entsteht, wo ich ifconfig noch nicht anwenden kann. (Die mit ifconfig geänderte MAC-Adresse gilt immer nur bis zum nächsten booten.)
-
Der Parameter ist bekannt, hat aber keine Auswirkung:
netra:/home/markus# eeprom | grep local
local-mac-address?=true
netra:/home/markus# ifconfig -a | grep HWaddr
eth-IBK Link encap:Ethernet HWaddr 08:00:20:C2:16:4C
eth-M Link encap:Ethernet HWaddr 08:00:20:C2:16:4C
netra:/home/markus#
Ich habe die Beschreibung auf der von Ebbi empfohlenen Seite so verstanden, dass local-mac-address? nur bei neueren NICs funktioniert.
local-mac-address? funktioniert seit asbach uralt. Selbst mit den alten 10Mbit Lance Ethernet Karten ging das. Hast Du zufälligerweise 3rd Party NICs drin? Da könnte es natürlich sein, dass der Parameter nicht funktioniert. Meiner Meinung nach setzt das OBP die MAC Adressen, d.h. beim Bootvorgang ist die richtige MAC schon gesetzt. Daher wird es wohl kein Linux-Problem sein.
Gruss
Dominik
-
Das heißt bei deiner Netra sind die MAC-Adressen (OHNE dass sie in Solaris während des Bootens nachträglich verändert werden) verschieden?
-
SunFireT2000:
Du hast mir leider Deine Frage nicht beantwortet, aber ja, natürlich sind sie verschieden. Habe zu dokumentationszwecken mal rasch eri1 geplumbed:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet x.x.x.x netmask ffffff00 broadcast x.x.x.x
ether 8:0:20:fe:5e:ce
eri1: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 3
inet 0.0.0.0 netmask 0
ether 8:0:20:fe:5e:cf
Gruss
Dominik
-
lspci sagt:
netra:/home/markus# lspci
00:00.0 Host bridge: Sun Microsystems Computer Corp. Ultra IIi
00:01.0 PCI bridge: Sun Microsystems Computer Corp. Simba Advanced PCI Bridge (rev 13)
00:01.1 PCI bridge: Sun Microsystems Computer Corp. Simba Advanced PCI Bridge (rev 13)
01:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
01:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01)
01:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 03)
01:03.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01)
02:01.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 04)
03:0e.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 03)
netra:/home/markus#
d.h. es sind Sun-NICs.
Hast du vielleicht eine Platte mit Linux drauf von der du mal booten könntest? Vielleicht liegt das Problem beim NIC-Treiber im Linux-Kernel. Der sieht nämlich die gleichen MAC-Adressen:
Aug 11 20:45:03 netra kernel: eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:16:4c
Aug 11 20:45:03 netra kernel: eth1: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:16:4c
Ich werde versuchen bei mir Solaris zu installieren um zu sehen wie es dort ist; aber das wird dauern.
-
Hallo SunFireT2000
Leider kann ich Dir mit Linux nicht weiterhelfen. Wir setzen die T1 produktiv ein und ich kann sie nicht "einfach so" mal rasch mit Linux booten. Vielleicht in 1 Jahr wenn die Maschine endgültig EOL geht und ersetzt wird. Aber das dauert Dir wohl zu lange :)
Gruss
Dominik
-
Auf meiner netra
Netra t1 (UltraSPARC-IIi 360MHz), No Keyboard
OpenBoot 3.10.25 ME, 1024 MB memory installed, Serial #12762264.
Ethernet address 8:0:20:c2:bc:98, Host ID: 80c2bc98.
netra:~# uname -a
Linux netra 2.6.18-6-sparc64 #1 Fri Jun 6 23:50:46 UTC 2008 sparc64 GNU/Linux
funktioniert local-mac-address?:
netra:~# prtconf -pv |grep local-mac-address
local-mac-address?: 'true'
local-mac-address: 080020c2.bc98
local-mac-address: 080020c2.bc99
Allerdings habe ich auch das Problem der gleichen MAC-Adressen:
sunhme.c:v3.00 June 23, 2006 David S. Miller (davem@davemloft.net)
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:bc:98
eth1: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:bc:98
netra:~# ip a | egrep '(ether|qlen)'
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 08:00:20:c2:bc:98 brd ff:ff:ff:ff:ff:ff
3: eth1_rename_ren: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 08:00:20:c2:bc:98 brd ff:ff:ff:ff:ff:ff
Wenn ich allerdings dem Modul einen Parameter mit übergebe, habe ich 2 verschiedene MAC:
netra:~# cat /etc/modprobe.d/sunhme.local
options sunhme macaddr=0x08,0x00,0x20,0xc2,0xbc,0x98
netra:~# rmmod sunhme
netra:~# modprobe -v sunhme
insmod /lib/modules/2.6.18-6-spasunhme.c:v3.00 June 23, 2006 David S. Miller (davem@davemloft.net)
rc64/kernel/driveth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet ers/net/sunhme.k08:o macaddr=0x8
c2:bc:98
eth1: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:bc:99
netra:~# ip a | egrep '(ether|qlen)'
5: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 08:00:20:c2:bc:98 brd ff:ff:ff:ff:ff:ff
6: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 08:00:20:c2:bc:99 brd ff:ff:ff:ff:ff:ff
Allerdings funktioniert das nicht beim Booten, aber vielleicht ist das ein Ansatz.
Grüße, Andreas
-
Hallo!
Danke Andreas für den hilfreichen Hinweis. Ich habe jetzt das Modul hme in den Kernel kompiliert, und damit funktioniert die Angabe der MAC-Adresse beim Booten:
markus@netra:~$ cat /etc/silo.conf
[...]
image=/vmlinuz
label=Linux
initrd=/initrd.img
append="sunhme.macaddr=0x08,0x00,0x20,0xc2,0x16,0x4c"
[...]
markus@netra:~$
netra:~# dmesg | grep "HAPPY MEAL"
eth0: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:16:4c
eth1: HAPPY MEAL (PCI/CheerIO) 10/100BaseT Ethernet 08:00:20:c2:16:4d
netra:~#
Weiters habe ich herausgefunden, dass local-mac-address? keine Auswirkung hat:
netra:~# prtconf -vp | grep local-mac-addr
local-mac-address?: 'true'
local-mac-address: 080020c2.164c
local-mac-address: 080020c2.164d
netra:~#
[...]
netra:~# prtconf -vp | grep local-mac-addr
local-mac-address?: 'false'
local-mac-address: 080020c2.164c
local-mac-address: 080020c2.164d
netra:~#
Auch sonst verhält sich alles gleich, egal welchen Wert local-mac-address? hat.
Und man kann dem Modul hme jede beliebige MAC-Adresse übergeben. Es muss nicht die Adresse einer eingebauten NIC sein. Das zweite Interface bekommt immer eine um 1 höhere Adresse.
Grüße
Markus