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:
1
kernel: [ 15.215072] 8139too: 8139too Fast Ethernet driver 0.9.28
2
kernel: [ 15.215110] 8139too 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>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.
15 Sekunden nach dem Systemstart sollte das doch eigentlich festliegen,
oder? (Ich habe aber auch vom Netz-Restart Logeinträge mit derselben
Zuordnung.)
>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.
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.
>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
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.
>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
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
>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.
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.
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 ;)
>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)
/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
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
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:
1
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.
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...
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...
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...
>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.
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.
>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.
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.
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.
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...
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.
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.
Thread beobachten
Seitenaufteilung abschalten