Important announcement: there is an English version of this forum on
Datum:
Ich habe Arch neu installiert und würde jetzt eigentlich gerne weitere Software installieren, um aus der Spielwiese ein brauchbares System zu machen. Leider bekomme ich keine Verbindung zu meinem Router. Der Rechner hat zwei NICs: Eine on board von Marvel Technology (eth1) Eine PCI-Karte RealTec 8139 (eth0) Die RealTec ist mit dem Router verbunden. Im Log finde ich folgende Spuren der 8139:
kernel: [ 15.215072] 8139too: 8139too Fast Ethernet driver 0.9.28 kernel: [ 15.215110] 8139too 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 kernel: [ 15.215581] 8139too 0000:05:02.0: eth0: RealTek RTL8139 at 0xffffc9000067ec00, 00:40:f4:5c:0f:5a, IRQ 18 kernel: [ 15.217482] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) |
In rc.conf sind die NICs so parametrisiert:
interface=eth0 # RealTec -> Router address=192.168.254.2 netmask=255.255.255.0 broadcast=192.168.254.255 gateway=192.168.254.1 interface=eth1 # Marvel Technology address=172.30.5.60 netmask=255.255.255.0 broadcast=172.30.5.255 |
Wenn das System hochgelaufen ist, bekommt ping 192.168.254.1 keine Verbindung.
ip link set eth0 up |
endet ohne jede Ausgabe und im log steht nichts darüber.
rc.d restart network |
bringt folgende Fehlermeldung:
RTNETLINK answers: No such process |
ip link show dev eth0 |
sagt '...state UNKNOWN...' Was ist da los? (Hardware-Problem ist es sicher keines, denn Ubuntu 10.04 funktioniert mit dieser Konfiguration.)
Datum:
>Eine on board von Marvel Technology (eth1) >Eine PCI-Karte RealTec 8139 (eth0) Bist Du denn sicher, dass die nicht womöglich vertauscht sind? So etwas hatte ich jedenfalls mal vor gut drei Jahren, als ich mein Gentoo mal neu installiert hatte. Ich habe auch zwei NICs, und Treiber für beide in den Kernel hineinkompiliert, also nicht als Modul. Was dann ETH0 und was ETH1 war dann plötzlich vertauscht. Zunächst hatte ich dann einfach das Netzwerkkabel umgesteckt, später hatte ich mit Google dann gefunden, wie man es vertauschen kann. Außerdem frage ich mich, warum Du nicht DHCP nutzt.
Datum:
Stefan Salewski schrieb: > Bist Du denn sicher, dass die nicht womöglich vertauscht sind? Ich denke doch - siehe oben:
kernel: [ 15.215581] 8139too 0000:05:02.0: eth0: RealTek RTL8139 at 0xffffc9000067ec00, 00:40:f4:5c:0f:5a, IRQ 18 |
15 Sekunden nach dem Systemstart sollte das doch eigentlich festliegen, oder? (Ich habe aber auch vom Netz-Restart Logeinträge mit derselben Zuordnung.)
Datum:
>Bist Du denn sicher, dass die nicht womöglich vertauscht sind?
Es wird dir nicht helfen, aber mir fiel gerade wieder ein, wo ich die
NICs vertauschen konnte:
stefan@AMD64X2 ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the
/lib64/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:13:d4:ab:53:10", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x11ab:0x4320 (skge)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:13:d4:ab:66:98", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Grundsätzlich könntest Du ja mal versuchen, zunächst nur einen NIC zu
aktivieren, also nur einen Treiber in den Kernel einkompilieren bzw. nur
das Modul für einen laden.
Datum:
>Ich denke doch - siehe oben:
Ja, da hast Du wohl recht.
Und warum kein DHCP?
Datum:
Stefan Salewski schrieb: > Und warum kein DHCP? Die statische Adresse stimmt - genau so mache ich es unter Ubuntu. Es muß ein Treiberproblem sein - sonst dürfte es keinen "state UNKNOWN" geben. Wenn der NIC nicht logisch UP ist, geht auch kein DHCP. Irgendwas schmiert da heimlich still und leise ab.
Datum:
>Es muß... Wenn Du meinst. Hast Du resolv.conf richtig gefüttert. Ich würde wirklich mal DHCP probieren, ist ja nicht unüblich bei ARCH https://wiki.archlinux.de/title/DHCP
Datum:
Hm, wenn schon das ping <ip-adresse des routers> nicht geht, braucht man sich über Namensauflösung (noch) keine Gedanken zu machen. Die resolv.conf ist noch leer. Die zu füllen, ist der nächste Schritt, nachdem das ping geht.
Datum:
>Es muß ein Treiberproblem sein - sonst dürfte es keinen "state UNKNOWN"
Du könntest ja mal die Kernel-Konfiguration von Ubuntu und Arch
vergleichen:
zcat /proc/config.gz
Datum:
In deinem Kernel-Log finden sich ZWEI Treiber für die 8139, nämlich 8139too und 8139cp. Deaktiviere mal einen von beiden und schau dann, welcher besser funktioniert. fchk
Datum:
Ubuntu kennt keine /proc/config.gz
inet@lx5:~$ zcat /proc/config.gz gzip: /proc/config.gz: No such file or directory |
Frank K. schrieb: > Deaktiviere mal einen von beiden Wo muß ich da hinlangen?
Datum:
>Ubuntu kennt keine /proc/config.gz Hätte ich nicht gedacht -- diese virtuelle Datei kann vom Kernel bereit gestellt werden um seine Konfiguration zu erhalten, aber das kann man deaktivieren. Frank K. schrieb: >> Deaktiviere mal einen von beiden >Wo muß ich da hinlangen? Da bin ich mir auch nicht sicher -- Module kann man ja mit rmmod entladen, etwa sudo rmmod -f 8139cp Aber ob das reicht? Sonst Kernel neu kompilieren mir nur einem der Module. Oder eine andere Methode war mit so einer Blacklist -- frag mal Google.
Datum:
Ok, ich hab was gefunden. Der 8139cp ist für pcmcia. Warum er den lädt, ist mir rätselhaft. In /etc/rc.conf steht daß blacklisting nicht mehr unterstützt wird. Es wird auf einen Ersatz in /etc/modprobe.d verwiesen.
Datum:
So, jetzt habe ich den 8139cp geblacklistet. Er wird jetzt nicht mehr geladen, aber das Problem ist unverändert.
Datum:
Schau mal bei ifconfig, ob da überhaupt Pakete ankommen. Evtl. auch mit tcpdump schnüffeln... BTW: Das mit den "state unknown" hat nix zum Zustand der HW zu sagen, das habe ich auch auf einem Device, das an einer Bridge hängt und diese Bytes laufen da gerade drüber ;)
Datum:
>Schau mal bei ifconfig, ob da überhaupt Pakete ankommen. Evtl. auch mit >tcpdump schnüffeln... Ein aktuelles Arch hat ifconfig nicht mehr sofort installiert. @uhu Ich wuerde dir vorschlagen den #archlinux.de auf irc.freenode.net bezutreten, die koennen dir sicherlich auskunft geben. (Vielleicht nicht unbedingt um diese Uhrzeit)
Datum:
/me nochmal, vorallem haette ich es mal manuell versucht: ip set eth0 up ip addr add 192.168.254.2/24 dev eth0 ip route add default via 192.168.254.1 ping 192.168.245.1
Datum:
Uhu Uhuhu schrieb: > Ok, ich hab was gefunden. Der 8139cp ist für pcmcia. Warum er den lädt, > ist mir rätselhaft. Eigentlich steht 8139cp für 8139C+, eine neuere Version des Chips. Das Original ist strohdumm, bei C+ sollen einige Sachen wie DMA erst sinnvoll funktionieren. Probiere diesen Treiber auch mal aus, vielleicht hast Du ja diese neuere Version des Chips. fchk
Datum:
max schrieb: > ip set eth0 up Das habe ich schon - null Effekt, keine Spur im Log - (wenn ich das für eth1 mache, dann gibt das Log-Einträge.) > ip addr add 192.168.254.2/24 dev eth0 das hatte ich schon - kein Effekt > ip route add default via 192.168.254.1 Der gateway ist in rc.config definiert - sollte aber keine Rolle spielen, wenn ich das eingebe:
ping -I eth0 192.168.245.1 |
Hat auch aber nichts gebracht. > Ich wuerde dir vorschlagen den #archlinux.de auf irc.freenode.net > bezutreten, die koennen dir sicherlich auskunft geben. Gute Idee. Frank K. schrieb: > Probiere diesen Treiber auch mal aus, vielleicht hast Du ja diese neuere > Version des Chips. Ja, das werde ich ausprobieren. Allerdings ist die Karte nicht gerade neu; 10 Jahre hat sie sicherlich auf dem Buckel.
Datum:
Wenn ich den 8139too blackliste, kommt im Log eine Meldung: "this is not an 8139C+ compatible chip, use 8139too".
Datum:
Uhu Uhuhu schrieb: > Wenn ich den 8139too blackliste, kommt im Log eine Meldung: "this is not > an 8139C+ compatible chip, use 8139too". dann lass den mal laden und blackliste den anderen. evtl. auch mal die pci karte rausnehmen. evtl. nutzen beide die selben pci resourcen und stören sich gegenseitig. alternativ: die onboard nic im bios ausschalten...
Datum:
Ronny Minow schrieb: > dann lass den mal laden und blackliste den anderen. Das hattenwer schon... Bringt nix. > evtl. auch mal die pci karte rausnehmen. Nein, ich will mein Ubuntu 10.04 auf keinen Fall platt machen - das lauft nämlich gut mit der Hardware -, bevor das neue System das alte vollwertig ersetzen kann. Die Ursache ist wohl eine andere: /etc/rc.config ist angeblich nur für einen NIC ausgelegt. Es sieht so aus, als wollten sich die Befürchtungen i.S. Systemwechsel bewahrheiten: man stolpert von einem Problem ins nächste und ein vollwertiger Ersatz für das olle Ubuntu ist nicht in Sicht...
Datum:
Was sagt ifconfig ? Sind die Nics dort angezeigt?
Datum:
ifconfig gibts bei Arch nicht mehr. Die entsprechenden Informationen habe ich mit ip ausgelesen - siehe oben. Ich werde mich von der Idee, auf Arch umzusteigen, verabschieden. Ist zwar ein nettes System, aber ungeeignet, damit aus dem Stand ein Produktionssystem aus dem Boden zu stampfen, das ein ein eingerichtetes Ubuntu ersetzen kann. Bevor man sich so einen Umstieg erlauben kann, sollte man ausgiebig in einer VM üben - die kann natürlich nicht in einem Arch Linux laufen...
Datum:
>Der gateway ist in rc.config definiert - sollte aber keine Rolle
ich weiss echt nicht welche rc.config du meinst.
Solltest du aber rc.conf meinen, dann muss ich dir sagen, haben die
Einstellungen nur einen Effekt, wenn du /etc/rc.d/network restart
machst.
rc.sysinit sourced rc.conf, dabei werden die daemons aus
DAEMON="...network..." gestartet. Der network daemon kann glaub ich nur
1. lanverbindung deren einstellung er aus rc.conf nimmt. Wenn du zwei
brauchst, musst du dir netcfg installieren oder einen anderen
networkmanager, oder du schreibst dir die 'ip addr add …' anweisungen
fuer die zweite Lanverbindung in rc.local.
Komm doch mal in den #archlinux.de da kann man dir vielleicht schneller
helfen, wenn du noch gewillt bist.
Datum:
max schrieb: > ich weiss echt nicht welche rc.config du meinst. max, es hat keinen Zweck, Ratschläge zu geben, die längst ausgeführt sind. Du solltest dir vorher schon ein Bild dessen machen, was bisher gemacht wurde. Das geht leider nicht, ohne daß man den Therad vorher liest. > Komm doch mal in den #archlinux.de da kann man dir vielleicht schneller > helfen, wenn du noch gewillt bist. Ich habe mich mittlerweile definitiv gegen Arch Linux entschieden. Ich brauche ein zuverlässig lauffähiges System, das 100% der zeitkritischen Jobs ausführen kann, die ich bisher auf Ubuntu 10.04 laufen habe. Das ist bei den Problemen, in die ich bis jetzt bei der Konfiguration von Arch gestolpert bin, nicht nur nicht garantiert. Das kann nur eine komplette Bauchlandung werden und darauf habe ich absolut keine Lust. Wie gesagt, mir gefällt das Arch Linux ganz gut, aber gut Ding will weile haben und mit einer neuen Distribution sollte man vorher zumindest in einer VM ausgiebig üben, bevor man sich daran macht, damit ein Produktionssystem aufzubauen. Allerdings haben mich die Auswirkungen des "rolling release model", von denen ich mittlerweile gelesen habe, doch etwas geschockt. Offenbar kann es vorkommen, daß von so einen Update z.B. irgendwelche Konfigurationsdateien verschoben, oder aufgespalten werden, ohne daß sich der Installer im Geringsten darum kümmert, daß die Mühle hinterher noch so läuft wie vorher. Sowas geht ganz einfach nicht.
Datum:
>Allerdings haben mich die Auswirkungen des "rolling release model", von >denen ich mittlerweile gelesen habe, doch etwas geschockt. Offenbar kann >es vorkommen, daß von so einen Update z.B. irgendwelche >Konfigurationsdateien verschoben, oder aufgespalten werden, ohne daß >sich der Installer im Geringsten darum kümmert, daß die Mühle hinterher >noch so läuft wie vorher. >Sowas geht ganz einfach nicht. pacman, von archlinux installiert unkritische neue configs als .pacnew. Alte configs die mit dem neuen programm nicht mehr rund laufen wuerden als .pacsav. Du wirst dann aufgefordert dich bei gelegenheit mal zukuemmern diese configs zu mergen. Den Text oben: >> ich weiss echt nicht welche rc.config du meinst. hab ich geschrieben, weil ich das Gefuehl hatte, dass du die Konfiguration von arch noch nicht so ganz verstanden hast. Bzw. dass deine Eingaben mit dem Programm ip unabhaengig von dem zu betrachten sind was in rc.conf steht bzw. was der network daemon macht.
Datum:
max schrieb: > Du wirst dann aufgefordert dich bei gelegenheit mal zukuemmern diese > configs zu mergen. Klingt gut, aber ich glaube nicht, daß das sicher, oder praktikabel ist. Irgendwann wird die Kiste bei einem vermeitlich unkritischen Update den Löffel werfen, wenn sich diese "Gelegenheit" noch nicht geboten hat. Für Maschinen, bei denen es "nicht darauf an kommt" und deren Betreiber immer Zeit und Lust hat, das System aktuell zu halten, mag das gehen; bei einer Kiste, die einfach flutschen muß, geht das nicht.
Datum:
Hallo, wenn es fuer dich noch wichtig ist, ein Treiberproblem wuerde ich ausschliessen. Ich habe hier den gleichen Chip auch auf Arch am Laufen, funktioniert problemlos. Tatsache ist allerdings, dass deine rc.conf nicht funktionieren wird. Im Arch-Wiki steht auch explizit, dass diese Konfiguration nur fuer PCs mit nur einem NIC gedacht ist. (https://wiki.archlinux.org/index.php/Rc.conf#Networking) > damit ein Produktionssystem aufzubauen. Davon wuerde ich abstand nehmen. Wenn es auf Zuverlaessigkeit und Stabilitaet ankommt (Produktivsystem), gibt es in der Linux-Welt meiner Meinung nach besser geeignete Systeme, ohne das jetzt negativ fuer Arch zu werten. Das Roling-Release-Modell ist in diesem Fall einfach eher Kontraproduktiv.
Datum:
sry, loesung wurde schon genannt, man sollte erst mal seite neu laden bevor man postet :P
Datum:
Armin S. schrieb: > wenn es fuer dich noch wichtig ist, ein Treiberproblem wuerde ich > ausschliessen. Ich habe hier den gleichen Chip auch auf Arch am Laufen, > funktioniert problemlos. Ich habe im deutschen Arch-Forum den Hinweis bekommen, das man über /etc/rc.config nur einen NIC konfigurieren kann - steht aber weiter oben auch schon... > Davon wuerde ich abstand nehmen... Na dann verstehen wir uns ja ;-) Wenn ich mei neues System am Laufen habe, werde ich das Arch in einer VM hochziehen. Arch ist schön klar strukturiert und das Wiki ist wirklich sehr gut - das erinnert mich sehr an alte Zeiten, als Programme von 1 MB noch fast undenkbar waren, man den Maschinencode des jeweiligen Mikroprozessors noch fast auswendig in hex hinschreiben konnte, die Betriebsysteme noch sehr, sehr übersichtlich waren und als es noch möglich war, in einer Stunde einen Bug aus der Anwendung bis runter in die Hardware zu verfolgen...
Datum:
Jo, arch muss administriert werden. Jedoch passiert das mit den neuen
Configs nur selten, bzw. brauchst du sie ja eh nur mergen, wenn du
selbst daran was geaendert hast. Sehr kritische Sachen, die auch mal ein
paar handgriffe des admins abverlangen stehen step-by-step in den news,
die man via rss oder mailinglist abonieren kann.
>bei einer Kiste, die einfach flutschen muß, geht das nicht.
Ich bin der auffassung das jedes system nach updates hier und da
manchmal ein paar Eingriffe erfordert. Arch ist und bleibt aber auch
eine fortgeschrittene Distribution.
Gibt sogar lts kernel fuer arch in den repos, damit haben viele ihren
server laufen, das "flutscht" auch wie du so schoen sagst xD
Nja, wenn du keinen Sinn darin siehst zu wechsel und mit Ubuntu
gluecklich bist, ist ja alles gut ausgegangen.
MFG Max.
Datum:
max schrieb: > Ich bin der auffassung das jedes system nach updates hier und da > manchmal ein paar Eingriffe erfordert. Also offen gesagt: Das Einzige, was ich seit Ubuntu 9.04 nach Kernel-Updates machen mußte, war, ein paar Module für den VMware Server neu zu compilieren. Das geht mit einem Script, das ein paar bestätigende Eingaben anfordert und hinterher einen Boot braucht. Ansonsten war da nie was zu machen. Allerdings bleibt das System auch auf dem jeweiligen Release-Stand und degenieriert halt so langsam vor sich hin, bis der Wunsch aufkommt, diese Altererscheinungen los zu werden. So weit ist es bei meinem Ubuntu 10.04 schon seit einiger Zeit. (Wobei einiges an Krankheiten von besagtem VMware Server kommt, dem mittlerweile die Haare und Zähne restlos ausgefallen sind und anderes - z.B. der Administrationszugang - auch schon weggefault ist.) > mit Ubuntu gluecklich bist Nein, das bin ich nicht. Aber das Ding ist einfach das kleinere Übel, oder ich kenne im Moment kein noch kleineres... Trotzdem vielen Dank für die Hilfe.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten