Netzwerkkartenproblem, eth1_rename

[Merc]

Hallo allerseits.

Ich betreibe einen Rechner samt darauf installierten Debian 3.1.
Der Kernel des Systems hat die Version 2.6.8.3 (war beim netinst mit dazu).
Unter jenem funktionieren meine beiden 3com Netzwerkkarten vom Typ 3c905b Combo ohne jegliche Probleme, d.h. beide arbeiten mit den ihnen zugewiesenen statischen IP's.

Unteren neueren Kernels (> 2.6.8.3) tritt jedoch ein Problem auf: die 2. Netzwerkkarte, eth1, wird beim Booten nicht mehr ordentlich erkannt und hochgefahren.
Folgende Fehlermeldung tritt dabei auf:

Code: Alles auswählen

SIOCSIFADDR: NO such device
eth1: ERROR while getting interface flags: no such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
eth1: ERROR while getting interface flags: no such device
failed to bring up eth1

Compiliert wurden die neueren Kernels mit den Standardmethoden, sprich mit "make" und anschließendem "make install".
Ein "make modules" bzw. "make modules_install" wurde ebenfalls ausgeführt.
Die Unterstützung der NIC's erfolgt via Modul (was beim Standardkernel 2.6.8.3 auch anstandslos funktioniert).

Ein "ifconfig -a" bei den Problem-Kernels bringt folgendes zutage:

Code: Alles auswählen

eth0      Protokoll:Ethernet  Hardware Adresse 00:60:97:31:5A:7D  
          inet Adresse:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Maske:255.255.254.0
          inet6 Adresse: fe80::260:97ff:fe31:5a7d/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:619 errors:0 dropped:0 overruns:0 frame:0
          TX packets:222 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:73092 (71.3 KiB)  TX bytes:19666 (19.2 KiB)
          Interrupt:12 Basisadresse:0xdc00 

eth1_rena Protokoll:Ethernet  Hardware Adresse 00:50:04:0A:F8:EC  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:5 Basisadresse:0x2f80

(die IP's der eth0 sind unkenntlich gemacht, also nicht über die "xxx.xxx.xxx.xxx" wundern)

ein "lspci -v" erzeugt folgenden Output:

Code: Alles auswählen

0000:00:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
	Flags: bus master, medium devsel, latency 64, IRQ 12
	I/O ports at dc00 [size=64]
	Expansion ROM at cffe0000 [disabled] [size=64K]

0000:00:0f.0 Ethernet controller: 3Com Corporation 3c905B Deluxe Etherlink 10/100/BNC [Cyclone]
	Subsystem: 3Com Corporation 3c905B Deluxe Etherlink 10/100/BNC [Cyclone]
	Flags: bus master, medium devsel, latency 64, IRQ 5
	I/O ports at d800 [size=128]
	Memory at cfffdf80 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at cffc0000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1

(nicht wundern, zwecks oben genanntem Problem hab ich die zweite 3c905C gegen ein anderes 3com-Modell getauscht, der Fehler bleibt aber der selbe)

Ein "cat /proc/interrupts" zeigt:

Code: Alles auswählen

           CPU0       
  0:      77071          XT-PIC  timer
  1:       1443          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  ohci_hcd:usb1
  7:          0          XT-PIC  parport0
  8:          4          XT-PIC  rtc
  9:          1          XT-PIC  acpi
 10:          0          XT-PIC  ohci_hcd:usb2
 12:        941          XT-PIC  eth0
 14:       1787          XT-PIC  ide0
 15:         57          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0 

Alles in allem kann ich mir nicht erklären, warum die zweite NIC nicht funktionieren will untern einem anderen, standardmäßig kompilierten Kernel.

Das die zweite Karte als "eth1_rename" (ein "ip link show" zeigt den vollen Namen statt "ifconfig -a" an) beim ifconfig angezeigt wird, verstehe ich ebensowenig.

Aus dem Forum hier konnte ich entnehmen, das gelegentlich Firewire sowie damit verbunden udev bzw. hotplug dafür verantwortlich sein könnten. Allerdings habe ich den ieee1394-Support im Kernel deaktiviert und ebenfalls läuft kein udev bzw. hotplug.

ich wäre für eventuelle Ratschläge zur Problemlösung äußerst dankbar.

MfG
Merc

EDIT KBDCALLS: Codetags eingefügt

[mistersixt]

Nur ein kleiner Tip:
Hast Du evtl. schon mal versucht, von http://backports.org/ einen Debian-Kernel aus "Backports" zu installieren, also beispielsweise 2.6.18?

Gruss, mistersixt.

PS: Willkommen im Debian Forum!

[cosmac]

hi,

"eth_rename" ist typisch fuer udev-Probleme. Benutzt du evt.
eine initrd? Da wird u.U. udev mit eingebaut, auch wenn du den
udevd nicht explizit startest. Mit einem selbstgebauten Kernel
barucht man doch eigentlich keine initrd?

[Merc]

Hallo mal wieder.

@ mistersixt:

Von Backports habe ich ehrlich gesagt noch nichts weiter installiert.
Zugegeben, ich bin kein Linux-Pro, eher das Gegenteil, was sich ja schon am Scheitern von obigem Problem zeigt

@ cosmac

Ich habe udev bzw. auch hotplug mit den regulären Befehlen wie "dpkg -P <package-name>" und / oder "apt-get remove --purge <package-name>" aus dem System entfernt.

Allerdings benutze ich eine mit "mkinitrd" (bzw "mkinitrd.yaird") erstellte initrd (benutze ich "mkinitramfs" muß ich dummerweise wieder udev und / oder hotplug installieren, irgendwie bestand da eine gewisse Abhängigkeit).

Verzichte ich auf den Gebrauch einer initrd, wird mir das meistens mit einem "Kernel Panic - Can't mount root-fs on ..." quittiert. Aus dem Grunde habe ich mich notgedrungen für die Verwendung einer initrd entschieden.

Ich bin noch nicht ganz dahinter gestiegen, warum bei Nichtverwendung dieser Fehler auftaucht. Ich vermute, das das initrd.img-File zu groß ist. Aus dem Grunde habe ich das "mkinitramfs" verwendet, das eine kleinere Datei erzeugt hat, was letztlich in einem bootbaren System endete.

Der oben bereits Erwähnte 2.6.8.3er Kernel verwendet ebenfalls eine initrd, bei dem tauchen jedoch, wie beschrieben, keinerlei Probleme mit den NIC's auf.


Wie weiterhin erwähnt, kenne ich mich lediglich rudimentär mit Linux aus, d.h. ich weiß ungefähr wie ich mir beim "make menuconfig" das auswähle, was ich brauche.
Das allerdings solcherlei Probleme auftauchen, ahnt man leider selten im Voraus (vor dem Neuinstall des Linux-Systems lief ein 2.6.15.x-Kernel, dort tauchten derlei Probleme ebenfalls nicht auf).


Danke erstmal euch beiden für die aufgezeigten Möglichkeiten. Ich werde beides erstmal ausprobieren.

MfG
Merc

[cosmac]

ein paar Gedanken zur Nacht:
- hast du noch eine " /etc/udev/rules.d/z25_persistent-net.rules"?
---> Netzwerkkarte auf einmal weg

- wenn die initrd mit yaird erstellt wird, wird udev nicht gebraucht,
insofern ist mein voriges Posting gegenstandslos.
- allein die Verwendung einer initrd führt sicher nicht zum Problem

- dass ein Original-Debian-Kernel mit der passenden initrd läuft,
will ich ja mal hoffen...

- trotzdem würde ich versuchen, die initrd loszuwerden:
liste mal die geladenen Module, wenn dein neuer Kernel mit initrd läuft
und bau alles was mit Festplatten(-Controllern) zu tun hat fest ein.

[Merc]

Hallo.

Es stimmt, es 'existierte' auf meinem System tatsächlich eine Datei namens "z25_persistent-net.rules"...jetzt allerdings nicht mehr (zusammen mit udev und hotplug, oder brauch ich wenigstens eines der beiden ?).

Ich baue mir grade einen neuen "Versuchs-Kernel" mit der, zugegeben, etwas veralteten Version 2.6.15.3.

Der sollte morgen früh dann fertig sein (heute hab ich leider nicht mehr den Nerv zu warten, bis das fertig wird).

Falls sich an der Situation dann etwas zum positiven geändert haben sollte, werde ich das hier mitteilen sowie den Output von lsmod posten (und eventuell noch die .config-Datei für's make, damit ich vielleicht mit etwas Anleitung die initrd noch wegbekomme).

MfG
Merc

[Merc]

Mahlzeit.

Mittlerweile habe ich den 2.6.15.7 am laufen (dummerweise vergessen, HighMem-Support mit einzubauen).
Die NIC's funktionieren auch alle, was wahrscheinlich auf das jetzige Fehlen von udev samt seiner Konfigurationsdateien zurückzuführen ist.

Weiterhin habe ich mir einen aktuellen (zumindest laut Kernel.org) 2.6.18.2er Kernel zusammengeschustert, dessen einziges Problem nunmehr das Nichtfunktionieren von iptables ist.

Kleiner Auszug der Fehlermeldung nach Ausführen meines Routing-Skriptes:

------------------------------------------------------------------------------------------------------
iptables v1.3.6: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables v1.3.6: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables v1.3.6: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
-------------------------------------------------------------------------------------------------------

Die aktuelle Version von iptables sollte die 1.3.6. sein, zumindest nach einem "apt-get update".

Hier noch die .config-2.6.18.2

http://www-user.tu-chemnitz.de/~dewo/.config-2.6.18.2

Hat eventuell jemand noch eine Idee woran es diesmal krankt ?


MfG
Merc

[nepos]

Fuer NAT sollte

Code: Alles auswählen

CONFIG_IP_NF_NAT=m

in deiner .config sein. Mit deiner Konfiguration wird einfach das entsprechende Modul nicht mit gebaut.

[Merc]

Danke für die schnelle Antwort

Ich nahm an, das ein "m" bei 'CONFIG_IP_NF_IPTABLES=m' bedeuten würde, das alle darunter aufgelisteten Features später dann nach dem Reboot mit dem erstellten Kernel automatisch zur Verfügung stehen würden.

Es scheint, als läge ich da falsch.

Würden sich die Funktionen für iptables wie z.B. "nat" per modul nachladen lassen ?
Oder müßte ich, um zum Beispiel auch "mangle" und "filter" funktionstüchtig zu bekommen, diese ebenfalls auf "m" setzen unter 'CONFIG_IP_NF_IPTABLES' ?


MfG
Merc

[nepos]

m heisst, dass es als Modul gebaut wird und nicht fest im Kernel ist. Damit kann man es mit modprobe oder insmod laden.

[Merc]

Ja, das "m" für ladbar als Modul stand war mir bewußt.

Das allerdings alles weitere unter der Zeile "CONFIG_IP_NF_IPTABLES" ebenfalls mit "m" deklariert werden muß damit es funktioniert, wußte ich nicht.

Ich war der Meinung, ein "m" bei einer übergeordneten Zeile hat eine bestimmte Automatik für alle (eingerückt) darunter angegebenen zur Folge.

Scheint, man lernt nie aus



MfG
Merc