After installing Debian stable (squeeze) I found that eth0 is not coming up, when I bring it up with "ifconfig eth0 up" only IPv6 is configured. Installation did happen in a network with IPv6 enabled through a tunnel and a radvd router. Which makes me think it may have decided to disable IPv4, don't know how or why.
I have done many installations in an IPv6 enabled network like this one and Debian (or Ubuntu) would always be able to use IPv4, given all drivers and configurations are correct.
The motherboard is a VIA e-900 mini-ITX. Ethernet is a realtek 8168B device:
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
I am pretty sure the hardware is recognised, since "ifconfig -a" shows eth0, "ifconfig eth0 up" brings it up and IPv6 is available. I also made sure to get the right firmware, syslog does not report problems loading it. During installation network was working fine and the installer was happily downloading packages. I pretty much did everything I always do when installing, when IPv4 is working afterwards.
/etc/network/interfaces looks like this:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.2.2.9
netmask 255.255.255.0
broadcast 10.2.2.255
network 10.2.2.0
gateway 10.2.2.1
I removed network-(mis)manager. Though that didn't fix it.
Any idea what may be wrong? Is there some special setting I overlooked which may fix this?
Update: To make clear, it does actually get an IP from a radvd router on the network and I can ping6 2001:500:88:200::10 (example.com), I can also ssh into the machine through its IPv6 address. So it's clear something is preventing networking to come up at boot. I think I will have to look into if any modules are not being loaded.
Update2: Manually adding the IPv4 configuration using the "ip" commands works and then IPv4 is up too.
I think the problem is related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611954 so it's specific to the realtek ethernet device. I have to add "ifup eth0" to an init script (rc.local for now) to actually get networking up fully at boot.
So it seems to be a bug in the firmware-realtek package, probably even upstream.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610302 suggests to try a newer kernel version. This helps a bit, in the sense that will load firmware patch, but the problem remains.
To illustrate, kernel 2.6.32-5:
In this case kernel is trying to load rtl8168e-1.fw and succeeding. I assume it didn't succeed with regards to the initramfs and that's why it's loading it later when "ifup" was run.
Kernel 3.2.0-0.bpo.2:
In this case firmware patch rtl8168e-1.fw was successfuly loaded during boot, however networking still didn't come up.
To be clear, both kernel version have a working network connection if you run something like "ifup ethX".
I guess I'll have to live with the work around until this is fixed.
I have almost the same issue. The only difference is that it works nice with the default squeeze amd 64 CD install kernel 2.6, and with the latest squeeze amd 64 kernel 2.6 available for update. If then I move to a kernel 3.x, I can't get an IPV4 address.
It looks to have nothing to do with the firmware (works with and without on kernel 2.6 and never works with or without with a kernel 3.x). Furthermore, I tried to install the driver available at realtek, but with no success too.
So, I'll end to think there's a bug between this realtek card way to work and the linux kernel 3.x way to manage network.
I'll try to check this week-end if I can make it work with static IP if I have enough time to manage all my network to work without DHCP.
Finally, and a bit out of topic, but not needless to say as my point of view. Years ago when we bought a motherboard, we had to choose our sound card and our network card. Nowadays ALL motherboards provide a sound card and a network card, and we very OFTEN have issues (in the linux world), with this providen chips. So it was just to say I really prefer to choose all my components on my own...