Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Uncle Harry]

I installed VL 6.0 recently.  Every time I start up (runlevel 4), eth0 is not configured, and I have to run VASM, go to Network, and Netconf to set it up.  As soon as I do that, everything is fine.  I'm using DHCP, by the way.
How do I get it to do this automatically on boot?  I didn't see anything in VASM, and I've been plowing through the initialization files in /etc, but I'm not sure what is the correct way to proceed.   I can see that rc.M calls rc.network, which includes these lines:

for i in 0 1 2 3 4; do
  if [ -x /etc/rc.d/rc.inet$i ]; then
    echonl "Setting up basic network ..."
    /etc/rc.d/rc.inet$i start &>/dev/null

I have rc.inet0, which has this:
DEVICE="eth0"
DHCP="yes"
IPADDR=""
NETMASK=""
GATEWAY=""
PROBE="no"

I also have rc.inet1, which has this:
DEVICE='eth0'
DHCP='yes'
IPADDR='127.0.0.1'
NETMASK='255.255.255.0'
GATEWAY=''
PROBE='no'

I tried renaming rc.inet1 to see if it was overwriting the settings from rc.inet0, but still no luck.
I also have a file rc.inet1.conf, but I don't know when that is even looked at.

Here's the weird thing to me:  If, instead of going to VASM, I just go to a terminal and run rc.network as root, it sets up fine!  So why isn't rc.M's call to it working?

Thanks for your help

[bigpaws]

Wicd probably has precendence over inet.

Look at /etc/wicd/wired-settings.conf and /etc/wicd/wireless-settings.conf

You can set auto connect there, or by the wicd gui as well.

Bigpaws

[Uncle Harry]

Thanks, but this is a desktop with wired only - no wireless.  So, wireless-settings.conf is empty.

[bigpaws]

Did you check to see that the rc.network was executable?

An ugly hack would be to add the inet command to
/etc/rc.d/rc.local/.

Bigpaws

[Uncle Harry]

Yes, rc.network is executable:   -rwxr-xr-x 1 root root 384 2009-01-11 14:45 rc.network*

I AM able to simply execute it instead of going to VASM, and everything configures right.  That's what's weird - rc.M does call rc.network,
but...I don't know what happens.  Maybe I'll put some text output in rc.M and rc.network to see what's happening and where it's breaking down.  Another alternative I thought of was to put the commands directly into rc.M to see if that works.  I'll let you know.  Thanks for your help.

[Uncle Harry]

Ok, I think I got it figured out.  I removed the direction of output to /dev/null so I could see what was happening, and even added some of my own signposts at various points.  I could see that the chain from rc.M to rc.network to rc.inet0 to functions-network was working - dhcp client was getting an address.  So it was something after that that was wiping it out, and you were right - it was wicd.  But it wasn't the two files you mentioned that had the problem settings.  It was /etc/wicd/manager-settings.conf.  I changed these two settings as follows:

wired_connect_mode = 0
always_show_wired_interface = True

It seems to be good now.  I hope.
The reason it worked when I called rc.network myself was, of course, because I was running that chain AFTER wicd did it's stuff, and was not running wicd again after that.
By the way, what actually calls wicd?

Thanks again for your assistance.

[bigpaws]

Wicd uses a daemon I believe it is

/usr/sbin/wicd

That starts the daemon and then the monitors take it from there.

Wicd is a nice tool and usually works well. The problem is that
if the daemon is running and there is no wireless then the diagnosis
becomes a problem.

You can try disabling wicd by removing the executable bit on
/etc/rc.d/rc.wicd.

The time you have spent on this really helps with tracking this down. I am
sure that it will be a good resource when this problem comes up again.

Bigpaws

[gamfa]

You can try disabling wicd by removing the executable bit on
/etc/rc.d/rc.wicd.

You can also disable Wicd service through VASM.

[Uncle Harry]

Funny you mention the time spent on this, because I was going to write that I spent WAY too much time on this.  I became obsessed with tracking it down.  I just had to understand it.  But then I realized that the ability to go on this chase, to have the resources out there to help, and to end up with a much better understanding - this is partly why I'm coming back to Linux after a several-year absence.

[linux411]

If DHCP is enabled, your IPADDR and NETMASK should be null   "".

I have my main computer setup as a Windows gateway where eth0 is a crossover cable to Windows and eth1 is wireless to a router. I couldn't get Wicd to play fair, so I had to remove it. I had tried VectorLinux before and always went back to Slackware because of the Wicd issue. When eth0 was active, eth1 would disconnect and vise versa. To be honest, I'd rather edit configs than rely on Wicd. At least til it works correctly.

When VectorLinux starts, it uses the rc.inet1 file. I haven't come across a rc.inet0 file before, at least not one of use. Just my findings. I think you may have your rc.inet0 file activates, but then is immediately re-processed and overwritten by rc.inet1. Removing it won't hurt anything.