# Upgrade after 2 weeks dhcpcd cannot get address from router

## agent_jdh

Hi,

Am hoping someone can help me here as I'm leaving home in a couple of hours for at least 2 weeks working away, and I'd really like to get this fixed before I leave.

Have been away for 2 weeks; powered up Gentoo server and proceeded to update it, as well as my Gentoo workstation.  Everything was working as I'd left it.

The server (hardened amd64) update has not gone well - brief synopsis -

Update world, which included shorewall and gcc (4.5.x -> 4.6.x). Unmerged gcc-4.5.x using depclean, rebuild world with new gcc.  Make clean in kernel dir, make && make modules_install.  Rebuilt my initrd.  Before I rebooted, I restarted shorewall just in case I'd mucked up updating the config files, but all seemed OK.

Rebooted, system comes up fine (it's a raid array, so always a bit nervous when anything kernel or initrd related happens).

However, when net.eth0 starts (using dhcp with a wired connection to my Netgear router), it tells me the link is up and it broadcasts for a lease but finds nothing, and times out.  I've tried with -zeroconf USE flag and also the clientid option in dhcpcd.conf, but no joy.  Have stopped shorewall (even though I was getting no output in dmesg indicating anything was being blocked), and tried restarting eth0.  The only config files updated in the whole procedure were the shorewall ones.

Maybe gcc related?  I've looked through elogv to try and see something obvious network related that was updated, but nothing leaps out.

Has something changed in the last 2 weeks that I have missed by being away?

My Gentoo workstation is now connected to the Netgear using the cable from the server, and it gets an ip fine, so it's not cable/hardware related.  Am using this to post here now.

Would really appreciate some help.

----------

## Jaglover

Why not use static setup, considering it's a server. DHCP is merely a configuration helper, pretty useless unless you have some mobile device and connect to different networks.

----------

## agent_jdh

I use a static ip on eth1 where the server connects to the local network, but dhcp to connect to my netgear router. I don't know if I can use a static ip with it. I'm approximately 250 mil.es away from it all now,so it will have to wait

----------

## MrDuck

I have the exact same problem, although I believe it is not related to gcc, but to the migration from module-init-tools to kmod. Everything still worked fine after upgrading gcc, but since the upgrade to kmod, the eth0 link is up, but does not receive an ip address. I enabled the DEVTMPFS filesystem (and devtmpfs automount), as suggested after emerging kmod, but it still doesn't work.

----------

## alacheesu

I don't know if it will help you guys, but I upgraded/rebooted my server today and also found that I no longer got an IP from my router (dhcpcd). I eventually found that eth0 and eth1 had changed places for some reason. Switching the cables got everything working correctly again.

----------

## agent_jdh

 *alacheesu wrote:*   

> I don't know if it will help you guys, but I upgraded/rebooted my server today and also found that I no longer got an IP from my router (dhcpcd). I eventually found that eth0 and eth1 had changed places for some reason. Switching the cables got everything working correctly again.

 

I'd figured it was this - iirc udev got updated, so it's probably a straightforward issue of persistent devices getting wiped. For me, eth0 is actually a pci nic, and eth1 is onboard, so I just need to reconfigure the custom settings I must have created at some point in the past. Or swap the cables, but I want to keep the onboard pcie gbit one for my local net. This is probably solved, but I can't test it now.

----------

## alacheesu

We have basically the same setup. I spent far too much time on this, so hopefully I can save you some time. This is with udev-197-r3.

1. Switching cables worked great until I noticed my other NIC was 100mbit.

2. Changing eth0 to eth1 and vice versa in /etc/udev/rules.d/70-persistent-net.rules had no effect. udev didn't seem to care about this file at all.

3. Apparently deleting this file will force it to be regenerated on the next reboot. This didn't happen either. I found instructions on the internet for regenerating this file, but none of them worked. 

4. I found some relevant bugs on bugzilla: 453030 and 453494. Apparently this renaming business was never supposed to be done anyway, but it worked until udev-197 put an end to it.

I finally gave up and just grep'ed all my scripts and config files for ethX and changed them accordingly. It seemed like the least painful solution. If you find a better solution please let me know.

----------

## lost+found

 *alacheesu wrote:*   

> ...
> 
> I finally gave up and just grep'ed all my scripts and config files for ethX and changed them accordingly. ...

 

Hi,

I did the same, but there's no guarantee the kernel will give the same device names every boot. I'm going to try compile one network driver into the kernel (so it might be the fastest to get eth0), and another one as a module...    :Smile: 

Yesterday, renaming worked again:

```
Jan 22 10:45:11 [kernel] systemd-udevd[184]: renamed network interface eth0 to eth1
```

I guess another "update" ruined it ...

```
1358874969: Started emerge on: Jan 22, 2013 18:16:08

1358874969:  *** emerge --newuse --deep --update @world

1358875012:  >>> emerge (1 of 3) sys-fs/udev-init-scripts-19-r1 to /
```

 :Evil or Very Mad: 

----------

## MrDuck

It turned out my problem was caused by a mix-up of the two onboard ethernet devices as well. I was also able to solve it (at least temporarily) by starting /etc/init.d/net.eth1 instead of eth0.

I guess I could add both net.eth0 and net.eth1 to the default runlevel, and use the one that works, although it won't be a very nice "solution" for the problem.

----------

## alacheesu

 *lost+found wrote:*   

> I did the same, but there's no guarantee the kernel will give the same device names every boot. I'm going to try compile one network driver into the kernel (so it might be the fastest to get eth0), and another one as a module...    

 

A good idea, but I ended up changing to the new device names that we're apparently going to migrate to at some point anyway, as explained here and in this gentoo bug. It looks like the best long term solution. 

I found the instructions in /etc/udev/rules.d/80-net-name-slot.rules.backup and it was a 5 minute job to set it up.

----------

