the dhcp init script is run before the net interfaces are up and this makes the init process fail because in my config it should only listen to the eth0 device. I have made another test, and if I stop /etc/init.d /net.eth0, the dhcp script fails to start until I bring eth0 up again. This situation happens at boot time because eth0 is brought up *after* net.eth0 Reproducible: Always Steps to Reproduce: 1. 2. 3.
Setting RC_NET_STRICT_CHECKING to yes solves the problem. This way the dhcpd daemon starts after all the net interfaces are up.
I figured out that myself but I wonder if this behaviour should be considered as correct.
Mass reassign wrt Bug 23718, maintainer being retired.
What version of baselayout do you have? I can't tell as you neglected to attach your emerge --info
need info
I think the current x86 stable baselayout. There is a little chance that it was the previous x86 stable version because I do not remember If this happened before the latest baselayout upgrade. I just checked and as the current baselayout was introduced in october I assume it must have been the previous one which is not in portage anymore
Well, what you are describing is correct behavour if RC_NET_STRICT_CHECKING is set to "none" or there are no net.xxx scripts in your default runlevel.
If I remember correctly the default value in the rc file is "no", which means that at least one net interface should be up (apart form lo).
That is correct. Also, we default to no net.xxxx scripts in the default runlevel which has the same effect. Do you still have this error with RC_NET_STRICT_CHECKING set to no? If so, could you test with baselayout-1.12.0_pre11-r3?
I can not reboot the computer now. If you give a couple of hours I will do it and report the results
Take as long as you like :)
Ok, just found I little time quantum to reboot. Before I did set RC_NET_STRICT_CHECKING back to "no" The dhcp server started without complaints(after both net.eth? scripts) and works. I would say this is solved and that it was a problem of the previous baselayout (the bug date is July!!) Thanks for your interesr