# no network after new baselayout (1.11.13)

## skeimer

hi,

I've updated a server to baselayout 1.11.13 and have changed the eth0 and route entries in conf.d/net .

After reboot I don't get access to the internet (what is indeed a problem, because the server is located out there).

Have there any other changes been made to the net.eth0/net.lo script and config? Do I need to have the network driver as a module instead of having it built into kernel?

Any other ideas what could have happened?

----------

## jamapii

Reemerge wireless-tools, hotplug, coldplug(?), wpa_supplicant(!) and possibly some more wireless related stuff. They changed some paths from /usr/sbin -> /sbin and /usr/bin -> /bin and hardcoded them in baselayout.

----------

## mneisen

Hello,

I think I encountered a similar problem. When trying to start /etc/init.d/net.eth0, I get

```

samsumm ~ # /etc/init.d/net.eth0 start

 * Starting eth0

 *   Cannot default to dhcp as there is no dhcp module loaded

 *   No configuration for eth0

```

My /etc/conf.d/net is empty so that DHCP should be the default behavior. It all worked before updating baselayout. I re-emerged both dhcpcd and hotplug - but it still tells me that there is no dhcp module loaded.

What do I do wrong?

Thanks in advance!

Kind regards

Martin Eisenhardt

----------

## paddler

 *Quote:*   

> Reemerge wireless-tools, hotplug, coldplug(?), wpa_supplicant(!) and possibly some more wireless related stuff. They changed some paths from /usr/sbin -> /sbin and /usr/bin -> /bin and hardcoded them in baselayout.

 

Wow, are you serious? I can't believe we need to start re-installing packages just because someone decided to switch some paths around? How does this work? Is there a central clearing house for upgrades like the recent baselayouts? Do they hold meetings about possible effects on the system or can anyone just decide to re-arrange things to fit their particular needs? I'd be interested to know the steps an upgrade like this goes through, what quallity controls cover its release.

 On the positive side it has taught me to stop trying to be so bleeding edge and blindly updating my system all the time. I have learned to wait a week or so and see what screws up other peoples systems (just like I always do before performing Windows updates). 

I have to laugh when people say they put emerge --update --deep world in a cron job. Without these forums I suspect gentoo would soon become unusable for mere mortals.

I apologize... didn't mean to hijack your thread. Just trying to understand why this stuff happens...

----------

## skeimer

hi,

@jamapii

do you really think, that re-emerging coldplug and htoplug would change anything? The driver for the network card is built into the kernel. Wireless things are not needed, because the box doesn't have any wireless interface.

I think after work I will give the hot/coldplug reinstall a try.

@paddler:

I use the glsa-check proggie to check if there are any security-relevant updates, additional I update any "hot" package like sudo or pam and every service that is listening outside like apache or ssh if there are severe bugs removed in the update (where "severe" is package-dependent).

The kernel was still 2.6.9 (...), because I didn't dare to install a newer one. Meanwhile the kernel is up to date again...

Concerning the quality controls and update steps I agree with you: There should no update be possible to run (especially in an emegre -u X chain) that would urge user intervention without stopping update chains and displaying clearly what has changed and what to do now (the postinst message is nearly frequently useless, even if one is able to read it through an update chain).

Even better would be if one gets notified in prior to the update.

But I have still the problem that I cannot reach the server except it's minimalistic backup gentoo installation from which I can chroot the actual system.

----------

## jamapii

All the wireless tools, wpa_supplicant etc. lived in /usr/bin and /usr/sbin. They moved it to /sbin and /bin, probably to be able to start wireless before mounting /usr, then possibly mounting a NFS /usr over WLAN.

I think they should have changed baselayout to handle both paths, or to not hardcode the paths at all, to avoid these problems. But they haven't.

But your problem may be entirely different because wireless is not involved... skeimer, the changes in conf.d/net might be the problem. For mneisen, the "dhcp module" is a "baselayout networking module", not a kernel module. Maybe create a config_eth0=( "dhcp" ) entry and see what happens. Emerge "pump" and other dhcp alternatives. And if you revert to the previous baselayout, does it work again?

And... did you do etc-update / dispatch-conf correctly? For all files in /etc/init.d, choose the new version (unless you know very well why not). For files in /etc/conf.d, choose your old version. If they are long and complex scriptsthat you didn't write, choose the new version. /etc/rc.conf - possibly merge it.

----------

## skeimer

hi,

@jamapii:

The server is using a static ip-address, so i cannot use dhcp. After every update I run etc-update and replace / merge the new files.

The strange thing is, that when I chroot from the rescue system and run the net.eth0 by hand, everything is working fine. But if I boot the ordinary image, eth0 does not come up.

net.eth0 is linked into the default runlevel, coldplug into boot, hotplug into default, the nic driver is compiled into the kernel, routes and ip config are set up correctly in conf.d/net.

Is there a way to make init or the init.d - scripts log what it they are doing at startup?

----------

## Henk Poley

Maybe this will help? I'm testing it one my own system now:

https://forums.gentoo.org/viewtopic-p-2596380.html#2596380

[Edit]

Also emerging baselayout says:

```
 * WARNING: You have older net.eth* files in //etc/init.d/

 * They need to be converted to symlinks to net.lo.  If you haven't

 * made personal changes to those files, you can update with the

 * following command:

 *

 *   # /bin/ls /etc/init.d/net.eth* | xargs -n1 ln -sfvn net.lo

```

----------

## jamapii

 *skeimer wrote:*   

> The strange thing is, that when I chroot from the rescue system and run the net.eth0 by hand, everything is working fine. But if I boot the ordinary image, eth0 does not come up.

 

Maybe you can use the rescue system's kernel (and /lib/modules/...)

Try building the driver as a module

Look in /var/log/syslog, compare successful and unsuccessful tries

----------

