Maybe ifplugd is putting your network down because it can't detect the link. I would try disabling ifplugd, you can do it from VasmCC, Services, Services, Run Level of your choice (I would turn it off on all of them) and uncheck ifplugd.Let us know how it goes.

I can't find anything relating to VasmCC, just vasm, which doesn't have anything like Services, Services, Run Level, just PASSWD, XWMSET, SKEL, SUPER, EXIT

Sorry Martin109, I read wrong your VectorLinux version, vasmCC was relased for 5.9Run vasm, super, service, srvset, and disable ifplugd un-checking it on the desired runlevel. Your default runlevel is 4, but I like to set same services for all runlevels if possible.

Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."Jorge Luis Borges, Avatars of the Tortoise. --Jumalauta!!

Having followed your advice and run vasm and disabled ifplugd at all levels, I have run the boot sequence several times and observed the screen messages together with the little green light on my 3Com adapter, which tells me when it's active.

The adapter comes on at the same time as the following appears on the screen:

Entering runlevel 2rc.M - Going multiuser

Now I had already acted on this post upthread, and amended my rc.M file

I had the same problem of not being able to start the network at boot up and having to use VASM to get it started. After much research and experimentation I also reached the stage of successfully starting the network by manually running "/etc/rc.d/rc.inet1 start". This implied that there was nothing wrong with the rc.inet1 script but rather it wasn't being called. What I eventually found was that in my /etc/rc.d/rc.M file a large chunk of code which starts the network was commented out! I don't know how or why this was so, but when I uncommented it the network started on the next reboot. This makes sense as inspection of the code shows that /etc/rc.d/rc.inet is called for each network interface. Hope this helps.

A short while later in the boot sequence the 3Com's light goes out again, around the time the following is being echoed to the screen:

Initialising network

That's puzzling to me, that the adapter seems to be disabled when the system is supposed to be initialising the network.

So I arrive at the command prompt and log in. I wondered for a while whether the adapter would just then come on by itself, as I have always seemed eventually to find it on. Is it coming on spontaneously, or in response to something I do?

I have tried various things after each boot sequence. I thought I had found it when I tried logging on as root with 'su root' and typing 'ifplugd'. The adapter's light flashed with a beep from the system each time and it then came on constantly, and I was able to execute the '/etc/rc.d/rc.inet1 start' command! Ahh! I thought... I've found what I have to do... but no, the next time I tried booting and doing the same thing, nothing happened! The next time I booted, logged on as usual, and then typed 'startx' to start the windows manager, and the adapter came on then!

So, in summary, I can see from the echo to screen from rc.M that the command '/etc/rc.d/rc.inet1 start' is being executed by the script, but it's not getting inet1 up, as the adapter isn't on. It's not clear why this is occasionally coming on when it does, and not coming on when it doesn't!

Just to double check that the /etc/rc.d/rc.inet1 script is being called you might like to amend it as follows:

#!/bin/sh# This file is supposed to be created by vnetadd# and modified by vnetset.# You can modify it by hand, but be careful ;-)## GNU GPL (c) Eko M. Budi, 2004# (c) Vector Linux, 2004#BOOT_SCRIPTS_LOG=/var/log/boot_scripts.logecho "rc.inet1: begin" >> $BOOT_SCRIPTS_LOGecho "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG############################################################# The settingsDEVICE=eth0DHCP=yesIPADDR=127.0.0.1NETMASK=255.255.255.0GATEWAY=PROBE=no

############################################################# The script

## You may make customized script here## If not, source the standard network . /etc/rc.d/functions-network "$@"

echo "rc.inet1: end" >> $BOOT_SCRIPTS_LOG

The change is everything to do with BOOT_SCRIPTS_LOG. If you reboot and then inspect /var/log/boot_scripts.log you'll see whether or not rc.inet1 is being called as well as the parameter i.e. start/stop. As I mentioned in my earlier post, I did a fair bit of research and experimentation on this topic. I used this log file method with other "boot time" scripts and found very it enlightening as to what is actually happening. For the record my network connection continues to start automatically at every boot.

Just to double check that the /etc/rc.d/rc.inet1 script is being called you might like to amend it as follows:

#!/bin/sh# This file is supposed to be created by vnetadd# and modified by vnetset.# You can modify it by hand, but be careful ;-)## GNU GPL (c) Eko M. Budi, 2004# (c) Vector Linux, 2004#BOOT_SCRIPTS_LOG=/var/log/boot_scripts.logecho "rc.inet1: begin" >> $BOOT_SCRIPTS_LOGecho "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG############################################################# The settingsDEVICE=eth0DHCP=yesIPADDR=127.0.0.1NETMASK=255.255.255.0GATEWAY=PROBE=no

############################################################# The script

## You may make customized script here## If not, source the standard network . /etc/rc.d/functions-network "$@"

echo "rc.inet1: end" >> $BOOT_SCRIPTS_LOG

The change is everything to do with BOOT_SCRIPTS_LOG. If you reboot and then inspect /var/log/boot_scripts.log you'll see whether or not rc.inet1 is being called as well as the parameter i.e. start/stop. As I mentioned in my earlier post, I did a fair bit of research and experimentation on this topic. I used this log file method with other "boot time" scripts and found very it enlightening as to what is actually happening. For the record my network connection continues to start automatically at every boot.

Kind Regards.

Right... I've modified my /etc/rc.d/rc.inet1 file as detailed above, and the output recorded in /var/log/boot_scripts.log is as follows:

rc.inet1: beginrc.inet1: called with parameter stoprc.inet1: endrc.inet1: beginrc.inet1: called with parameter startrc.inet1: endrc.inet1: beginrc.inet1: called with parameter startrc.inet1: endrc.inet1: beginrc.inet1: called with parameter startrc.inet1: end

I don't know why it's being called four times; I also don't know why it's first called with 'stop' then three times with 'start' but still leaves inet1 down. Any ideas?

I don't really know what's going on with all those multiple starts. I'll have to do some more research... One possibility off the top of my head is that several services of different run levels are each trying to start the network. If you run VASM as Super/Service/Initset and select VLINT this should eliminate services being stopped and started unnecessarily. Another thing, run "ps xl | grep dhcpcd" to see if dhcpcd is running.

That's all I have right now but I'll dig a bit deeper and try to come up with something more.

#!/bin/sh# This file is supposed to be created by vnetadd# and modified by vnetset.# You can modify it by hand, but be careful ;-)## GNU GPL (c) Eko M. Budi, 2004# (c) Vector Linux, 2004#BOOT_SCRIPTS_LOG=/var/log/boot_scripts.logecho "rc.inet1: begin" >> $BOOT_SCRIPTS_LOGecho "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG############################################################# The settingsDEVICE=eth0DHCP=yesIPADDR=127.0.0.1NETMASK=255.255.255.0GATEWAY=PROBE=no/sbin/ifconfig eth0 up############################################################# The script

## You may make customized script here## If not, source the standard network. /etc/rc.d/functions-network "$@"

First, I deleted /var/log/boot_scripts.log, to make sure I was starting from scratch. Then I booted and checked the file; the parameters were

stopstopstartstart

So, I deleted /var/log/boot_scripts.log again, and added '/sbin/ifconfig eth0 up' to /etc/rc.d/rc.inet1, as suggested. I deleted /var/log/boot_scripts.log again, booted, and checked the file. The parameters this time were:

stopstartstart

So, to double-check, I commented out '/sbin/ifconfig eth0 up' in /etc/rc.d/rc.inet1 by adding '##' at the beginning of the line. I deleted /var/log/boot_scripts.log again, booted, and checked the file. The parameters this time were:

stopstartstart

2. Use of ps xl | grep dhcpcd

Output of this was:

0 1828 3473 3413 15 0 1880 604 pipe_w S+ grep: dhcpcd

When running it again after another boot, some figures reduced by 4:

0 1828 3468 3409 15 0 1876 600 pipe_w S+ grep: dhcpcd

3. I ran VASM and entered Super/Service/Initset, then selected VLINIT, as suggested. This doesn't appear to have made any difference, apart from some echoed messages on screen during boot describing switches of runlevel, from 6 to 2, and restating of runlevel2.

I'm afraid I'm as flummoxed as ever! At least I can get inet1 up and running eventually. It feels rather like waving a magic wand:

BootLogon (not as root!)StartxWait a bit (don't know why, more of an incantation!)Quit xfceSwitch to rootType 'ifplugd' (most of the time, this gets the adapter going, light comes on)Type '/etc/rc.d/rc.inet1 start' (connected!)Come out of rootstartxStart using internet

I'd like some logic!

Very many thanks for help and thoughts provided so far. Hopefully, this is useful to others.

From your last post it seems as if dhcpcd is not running. What your listing showed was just the grep process that gave the output. There should be a separate process for dhcpcd. Your output should look something like this:

The first line is the one we're after. The command "ps ax" will list all the running processes. Grep just prints the one's that meet the search term "dhcpcd". Try running this after the network is up and running to see if there's any difference. I'll try to follow up one this tomorrow, but for now it's bedtime!

From your last post it seems as if dhcpcd is not running. What your listing showed was just the grep process that gave the output. There should be a separate process for dhcpcd. Your output should look something like this:

The first line is the one we're after. The command "ps ax" will list all the running processes. Grep just prints the one's that meet the search term "dhcpcd". Try running this after the network is up and running to see if there's any difference. I'll try to follow up one this tomorrow, but for now it's bedtime!

Kind Regards

Many thanks, scrambled_egg.

Yes, I can also report that when logging off, the screen echoes something like 'Stopping network' and also **** dhcpcd: not running