# "eth0: link is not ready" after kernel upgrade - [Solved]

## Knaprigt

Just upgraded from grentoo-sources-2.6.37 to 2.6.38, used pretty much the same kernel configuration and built the new kernel without a problem.

However, every time I boot my system after the upgrade i keep having problems with my network interface.

From the start the NIC (a wired Realtek 8169 Gb ethernet) was known as eth1 due to an old udev rule from a time when I had two NICs.

The first thing I did was getting rid of this rule and reverted back to just having eth0, but this didn't do anything to solve my problem.

When I boot the system it tries to bring eth0 up using /etc/init.d/net.eth0 but times out and dmesg returns stuff like:

```
[   49.985587] r8169 0000:02:00.0: eth0: link down

[   49.985592] r8169 0000:02:00.0: eth0: link down

[   49.985684] ADDRCONF(NETDEV_UP): eth0: link is not ready

[   52.369662] r8169 0000:02:00.0: eth0: link up

[   52.369776] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   62.530005] eth0: no IPv6 routers present
```

My /etc/conf.d/net file is blank so /etc/init.d/net.eth0 defaults to dhcp, which it should.

What confuses me a bit here is that once it's timed out (twice), I can actually bring it up manually by first doing "# ifconfig eth0 up" and then "# dhcpcd eth0".

Why /etc/init.d/net.eth0 doesn't just bring up the interface this way, I don't know, but then again I'm no expert when it comes to these things.

Any ideas on what might be wrong here would be really appreciated since it's a bit of a fuss having to bring the system online using the above mentioned method.Last edited by Knaprigt on Mon Apr 11, 2011 4:18 pm; edited 1 time in total

----------

## BradN

Can you verify for sure that it still works with the old kernel and that it wasn't a different upgrade that caused it to break?  If it's a kernel bug, then that's a good candidate for doing a bisection test (at least if the problem exists in vanilla-sources).

Bisection test = using kernel.org's git server and some special git commands to fetch a midpoint kernel between the last known working and first known failed versions, which you compile and test.  Then you run git again, telling it if that kernel worked or not, and it makes another source tree with all the changes halfway between the one you just tested and the one known to have the opposite result.

Long story short, you compile and test around the neighborhood of 10 kernels and it'll tell you the exact change made to the kernel that broke things, which makes for a nice bug report that's usually easy to fix for the developers.

That all said, 8169 is an extremely common driver, I wouldn't expect to see kernel breakage there.  That's why I suggest double checking that an older kernel does work as expected  :Wink: 

----------

## rherbert

Okay, I cheated by joining this forum, because I don't use Gentoo Linux, but Slackware.  Same problem, though, since upgrading to 2.6.38.  I can confirm that the problem wasn't present with kernel 2.6.37.4, but occurred immediately after upgrading to 2.6.38.  I run "clean" kernels by compiling the tarball after running a "make silentoldconig" using the previous kernel's .config file, so it's possible that something that got carried forward is causing the problem.  What I don't understand is the new message regarding the inability to locate the firmware files rtl8168d-1.fw and rtl8168d-2.fw.  These files don't exist on my system, and I can't find any reference to them in gconfig.

Like the OP, I can establish an Internet connection by running "dhcpcd eth0" at a command prompt once I've logged in.  The strange thing is that without running the previous command, I can start a Windows XP session via VirtualBox and access the Internet from within it.

----------

## Knaprigt

Well, it turns out I solved my problem by upgrading dhcpcd from 4.x to 5.2.10. Now /etc/init.d/net.eth0 works as it should at boot.

No idea why my new kernel didn't like the old version, but I guess my dhcpcd could use an upgrade anyway.

Oh and "rherbert", I marked this thread as solved since the problem seems to at least be sorted on Gentoo systems by upgrading dhcpcd.

Give it a try on your Slackware system, might work there too!

----------

## rherbert

 *Knaprigt wrote:*   

> Well, it turns out I solved my problem by upgrading dhcpcd from 4.x to 5.2.10. Now /etc/init.d/net.eth0 works as it should at boot.
> 
> No idea why my new kernel didn't like the old version, but I guess my dhcpcd could use an upgrade anyway.
> 
> Oh and "rherbert", I marked this thread as solved since the problem seems to at least be sorted on Gentoo systems by upgrading dhcpcd.
> ...

 

Thanks very much for the heads up, "Knaprigt".  Upgrading to dhcpcd 5.2.11 on my end solved the problem.

Thanks for tolerating my intrusion of your forum; it was the only place I found my particular problem mentioned.

Richard

----------

## BradN

Just don't start asking car questions  :Wink: 

----------

## cach0rr0

 *Knaprigt wrote:*   

> Well, it turns out I solved my problem by upgrading dhcpcd from 4.x to 5.2.10. Now /etc/init.d/net.eth0 works as it should at boot.
> 
> No idea why my new kernel didn't like the old version, but I guess my dhcpcd could use an upgrade anyway.
> 
> 

 

if you're curious:

https://forums.gentoo.org/viewtopic-t-841280.html#6399368

----------

## Sannin

I dont know if it really is relevant, but here is a bug report that looks like this one: 

https://bugs.gentoo.org/show_bug.cgi?id=359671

----------

