@mannohneschuh:
doch doch, die Netzwerkkarte wird erkannt: 
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Das Gateway unter Windows ist 192.168.2.1, aber auch wenn ich das nicht übernehmen können sollte, also 192.168.0.1 lasse, geht es aber nicht 🙂

Und die Mac-Adresse hab ich nur aus Faulheit einfach mit xx besetzt 😛 wollt nicht abschreiben...

@GerBra:
# dhcpcd -k eth0 gibt: 
dhcpcd: sending signal 1 to pid 1972
dhcpcd: waiting for pid 1972 to exit
#dhcpcd -d eth0 gibt: 
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0:  sending DHCP_DISCOVER (xid 0x2b728093), next in 3.92 seconds
dhcpcd: eth0: offered 192.168.2.2 from 192.168.2.1
dhcpcd: eth0: sending DHCP_REQUEST (xid 0x2b728093), next in 3.37 seconds
dhcpcd: eth0: acknowledged 192.168.2.2 from 192.168.2.1
dhcpcd: eth0: checking for 192.168.2.2
dhcpcd: eth0: sending ARP probe (1 of 3), next in 1.06 seconds
dhcpcd: eth0: sending ARP probe (2 of 3), next in 1.32 seconds
dhcpcd: eth0: sending ARP probe (3 of 3), next in 2.00 seconds
dhcpcd: eth0: leased 192.168.2.2 for infinity
dhcpcd: eth0: adding IP address 192.168.2.2/24
dhcpcd: eth0: adding route to 192.168.2.0/24
dhcpcd: eth0: adding default route via 192.168.2.1
dhcpcd: eth0: writing lease '/var/lib/dhcpcd/dhcpcd-eth0.lease'
dhcpcd: eth0: executing '/usr/lib/dhcpcd/dhcpcd-run-hooks', reason BOUND
dhcpcd: eth0: MTU set to 1492
dhcpcd: forking to background
boar war das jetzt ne Arbeit, das abzutippen 😃

statische IPs würd ich nur ungern vergeben, da ich öfters mal ne LAN bei mir veranstalte und da immer mal andere Leute dabei sind! es muss doch auch ohne gehen...

Wenn ich den Router jetzt anpinge, kommt nur 
connect: Network is unreachable
macht es da einen Unterschied ob ich eine statische IP vergebe?

Danke für die Antworten und LG Daniel
Also dein dhcpcd -d Ausgabe sieht gut aus, du bekommst vom DHCP-Server 192.168.2.1 eine IP zugewiesen (192.168.2.2.), ebenso werden die Routen gesetzt.

Hast du gleichzeitig noch Networkmanager oder ein anderes Tool laufen?

laß dir nochmal der dhcpcd (erst -k dann -d, wie beschrieben) nochmal ne IP geben und pinge dann nochmal die 192.168.2.1 an. Wenn wieder die fehlermeldung kommt, dann bitte auch nochmal so:
ping -I eth0 192.168.2.1

Sind nach dem dhcpcd oben die Routen gesetzt?
route -n
Stehen dort zwei Einträge die in der Iface-Spalte eth0 haben? (Mußt nicht abtippen ;-) )
ich habe noch nichts installiert, das System befindet sich im Grunde im Ausgangszustand der Core-Installation! Ausser die paar config-Sachen der Installation!

# ping 192.168.2.1 bringt wieder network unreachable und # ping -l eth0 192.168.2.1 gibt: 
ping: bad preload value, should be 1..65536
# route -n gibt wieder nur ne leere Tabelle aus...
Hmm,

Welcher Kernel läuft bei dir? (uname -a sagt dir das).

Kannst du dein wireless Device abschalten am laptop(z.B. per Schalter)? Wenn ja versuch es mal ohne.

bad preload irritiert mich hier gewaltig. Evtl. verliert dein eth0 dauernd den Link zum Router (Kabel, ...)
Melde dich zum Bsp. auf ALT+F2 auch mal als root an und laß dort mal laufen:
mii-tool -vw
eth0 sollte dort auftauchen mit "link ok".

Wenn du auf tty1(ALT+F1) jetzt den dhcpcd Vorgang (-k und dann -d) machst (die Ausgabe bei -d ist immer gleich der, dioe du abgeschrieben hast?, also ohne erkennbare Fehlermeldungen), hat sich dann auf ALT+F2 bei den mii-tool Ausgaben etwas geändert?

Siehst du nach dem Ping-Versuch in der Ausgabe von dmesg am Ende irgendetwas was wie ein Fehler aussieht? Also "error" oder "failed"? Mußt nicht alles abschreiben...

Edit: Hast du bei: ping -I eth0 evtl. ein kleines L (wie Ludwig) geschrieben? Der Paranmeter sollte eihn großes i (-I wie Italien) sein
Edit2: Ich solte diese Dinger in block-Quotes setzen, ist aber von der Schrift her schwer zu erkennen...
alsooooo

- der Kernel ist die 2.6.33..

- abschalten des wireless device bringt nichts

- also mii-tool -vw bringt: 
SIOCGMIIREG on eth0 failed: Input/Output error
12:17:xx eth0 negotioated 100baseTx-FD flow-control, link ok
SIOCGMIIREG on eth0 failed: Input/Output error
12:17:xx eth0: no link
und das wieder holt sich immer und immer wieder! Verändert hat sich da nix.
Genausowenig wie bei dhcpcd -d! dmesg haut auch nix raus mit Fehlermeldung oder ähnlichem!
Bin mal kurz weg.
Versuche mal ein anderes Kabel/Port am Router und schau mal ob alle Kabel richtig gesteckt sind. Auch ob an Laptop und Router duie LEDs für die Ports brennen (wenn vorhanden).

Du nutzt für die Karte das e1000e Modul, richtig? lspci -k sagt dir das bei kernel driver in use: für die Netzkarte.

Die Usache ist das der Link dauernd wegbricht (Hadware oder Modul/kernel-Problem)
jap, das e1000e-Modul! Und das ändern der Ports am Router hat nichts gebracht 🙁 Warum funzt es denn bei Ubuntu und bei Arch nicht *grrr*
Es gibt etliche Berichte über Probleme mit diversen 2.6.35 Arch-Kernelrevisionen und eine Suche nach e1000e im englischen Forum zeigen auch einige Posts mit Problemen mit dem Kernel des aktuellen Install-ISOs und diversen Chipsatz-Revisionen.

Hast du Erfahrung wie du z:b. von der Ubuntu-Live-CDs ein Chroot auf dein Archlinux machst und dort das System aktualisieren kannst? Wenn ja, dann würde ich vorschlagen auf den 2.6.36 aus testing zu aktualisieren.

Alternativ kannst du auch nochmal versuchen die MTU zu reduzieren. Also nach dem Start: 
ifconfig eth0 mtu 576
dhcpcd eth0
ping 192.168.2.1
Evtl. verhindert die kleine MTU den Linkverlust zum Router (mii-tools)

Edit: Nutzt du bei Archlinux bzw. Ubuntu i686 oder x64_86 (also 32 oder 64 bit)?
GerBra schriebEs gibt etliche Berichte über Probleme mit diversen 2.6.35 Arch-Kernelrevisionen und eine Suche nach e1000e im englischen Forum zeigen auch einige Posts mit Problemen mit dem Kernel des aktuellen Install-ISOs und diversen Chipsatz-Revisionen.

Hast du Erfahrung wie du z:b. von der Ubuntu-Live-CDs ein Chroot auf dein Archlinux machst und dort das System aktualisieren kannst? Wenn ja, dann würde ich vorschlagen auf den 2.6.36 aus testing zu aktualisieren.

Alternativ kannst du auch nochmal versuchen die MTU zu reduzieren. Also nach dem Start: 
ifconfig eth0 mtu 576
dhcpcd eth0
ping 192.168.2.1
Evtl. verhindert die kleine MTU den Linkverlust zum Router (mii-tools)
Wäre sorum nicht sinniger:
dhcpcd eth0
ifconfig eth0 mtu 576
ping 192.168.2.1
Das DHCP liefert doch einen eigenen mtu-Wert welcher dann den gesetzten überschreibt.

Grüße
@Bomb: hast recht!
ne, mit chrooten kenne ich mich nicht aus! Hab das zwar einmal gemacht, als ich mal gentoo installiert hatte, aber keine Ahnung mehr 🙂

Verringerung des MTU brachte auch nichts!

Evt. werde ich eben doch einfach per WLan ins Inet gehen (sofern das funzt, die Treiber waren zum Glück im Core-Image dabei) und dann hoffen dass es mit Wicd oder dem Networkmanager klappt... Wollte zwar eigentlich wissen wo der Fehler liegt und wie man ihn beheben kann, aber wenn das scheinbar nicht möglich ist 😃
Edit: Bei dem MTU-test hast hast du noch Bomb's Post gelesen? (Fehler von mir)

Wlan wäre eine Alternative (dann könntest du dein System zum einen aktualisieren (auf aktuell 2,6,35), bei Problemen ggf. auf den Testing-Kernel.

Du könntest auch den Testing-2.6.36 downloaden, auf z.B. einen USB-Stick oder CD packen, diese in Arch einhängen und den Kernel so aktualisieren. Interessant wäre ja erstmal nur, ob Kernel > 2.6.33 das Problem beheben.

http://ftp.hosteurope.de/mirror/ftp.archlinux.org/testing/os/i686/kernel26-2.6.36-3-i686.pkg.tar.xz

Hier bekommst du für i686 den Testing-kernel.

In dein Arch-System kopieren, dann ein: 
pacman -U /pfad_zum_kernel_gz/kernel26-2.6.36-3-i686.pkg.tar.xz
bzw. bei Meldungen über Abhängigkest-probleme (sollten vernachlässigbar sein)
pacman -Udf /pfad_zum_kernel_gz/kernel26-2.6.36-3-i686.pkg.tar.xz
hm okay das hat funktioniert 😃 hoffentlich macht der testing-kernel keine Probleme 🙂

Also das Problem lag nun entweder am alten Kernel oder an dem paket linux-firmware, das scheint ja einiges zu ersetzen!

na gut, dann ist das soweit gelöst; ich danke für die umfangreiche hilfe 🙂 endlich kann ich wieder arch benutzen 🙂
Freut mich!

Der Testing-Kernel sollte keine Probleme mit den "normalen" Paketen/bzw.Upgrades machen, ich schätze das er gerade wegen den Problemen mit diversen Intel-Net-Chipsätzen sowieso bald nach Core kommen wird.

Mußtest du/hast du das Firmware-Paket auch auf (testing) aktualisiert? Soweit ich weiß braucht man für den e1000e keine Firmware, bin aber nicht sicher...

Bei viel Experimentierfreude könntest du ja auch nochmal schauen, ob der core-Kernel (2.6.35) auch funktionieren würde, dann könntest du aktuell auf testing-Pakete verzichten. Aber: nur weil du den Kernel aus testing benutzt heißt nicht zwangsläufig daß du auch das testing-repo aktiviert haben mußt.

SCNR: Immerhin sind wir - mit Hilfe aller Beteiligten - unter 24h bis zur Problemlösung geblieben, also keine Regressansprüche wegen Verstöße gegen ein SLA oder schlechter Reaktionszeit....
ne, das firmware war ein community paket glaub ich! Ne den 2.6.35 will ich jetzt nicht noch probieren 🙂 wenn der 2.6.36er eh bald nach core kommt...

hehe ich weiß auch so, dass dieses forum immer hilfe bietet! und wenn man mal länger als 24h warten muss, dann kann man da imho niemandem einen vorwurf machen 🙂
Als Info nebenbei:
habe hier gerade meinen T60 mit einem Intel 82573L (deiner LM) uhnd habe mit dem e1000e keine Probleme.

Edit: Will sagen, so unterschiedlich können Chipsätze sein...