Print

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

[Martin109]

Thanks, but could you specify more precisely the steps I need to follow to disable ifplugd?  You have to remember you're dealing with a Vectorbie here!

[bigpaws]

The directions from the previous response were about as clear
as they can be.

There is an icon on your desktop named VasmCC, use that, and
follow the directions.

Bigpaws

[Martin109]

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

[Martin109]

If I type vasmcc as root on the command line, it states: bash: vasmcc: command not found

[rbistolfi]

Sorry Martin109, I read wrong your VectorLinux version, vasmCC was relased for 5.9
Run 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.

[Martin109]

Thanks rbistolfi.

This is all very curious.

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 2
rc.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!

Curiouser & curiouser...!

[scrambled_egg]

Hi Martin109,

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.log
echo "rc.inet1: begin" >> $BOOT_SCRIPTS_LOG
echo "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG
###########################################################
## The settings
DEVICE=eth0
DHCP=yes
IPADDR=127.0.0.1
NETMASK=255.255.255.0
GATEWAY=
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.

[Martin109]

Many thanks for this - looks very useful indeed.

I'm away from my Linux machine at the moment, but should have time to explore this at the weekend.  I'll post again when I've done that.

Thanks again.

[Martin109]

Hi Martin109,

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.log
echo "rc.inet1: begin" >> $BOOT_SCRIPTS_LOG
echo "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG
###########################################################
## The settings
DEVICE=eth0
DHCP=yes
IPADDR=127.0.0.1
NETMASK=255.255.255.0
GATEWAY=
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: begin
rc.inet1: called with parameter stop
rc.inet1: end
rc.inet1: begin
rc.inet1: called with parameter start
rc.inet1: end
rc.inet1: begin
rc.inet1: called with parameter start
rc.inet1: end
rc.inet1: begin
rc.inet1: called with parameter start
rc.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?

[scrambled_egg]

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.

[uelsk8s]

try adding "ifconfig eth0 up" to your /etc/rc.d/rc.inet1 script

Code: [Select]

#!/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.log
echo "rc.inet1: begin" >> $BOOT_SCRIPTS_LOG
echo "rc.inet1: called with parameter" $@ >> $BOOT_SCRIPTS_LOG
###########################################################
## The settings
DEVICE=eth0
DHCP=yes
IPADDR=127.0.0.1
NETMASK=255.255.255.0
GATEWAY=
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 "$@"

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

[Martin109]

Many thanks for the help so far.

I can't find any consistency to this!

1.  Use of 'ifconfig eth0 up'

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

stop
stop
start
start

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:

stop
start
start

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:

stop
start
start


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.

Another check of /var/log/boot_scripts.log revealed 4 instances again!

stop
stop
start
start

Another use of ps xl | grep dhcpcd produced:

0  1828  3488  3429  15  0 1880  604  pipe_w S+    grep: dhcpcd

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:

Boot
Logon (not as root!)
Startx
Wait a bit (don't know why, more of an incantation!)
Quit xfce
Switch to root
Type  'ifplugd'  (most of the time, this gets the adapter going, light comes on)
Type '/etc/rc.d/rc.inet1 start' (connected!)
Come out of root
startx
Start using internet

I'd like some logic!

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


 

[scrambled_egg]

Hi Martin109,

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:

1     0  2641     1  15   0   1584   352 -      Ss   ?          0:36 dhcpcd -t 10 -h cwl.littlefield.net -d eth0
0     0 18605  6362  18   0   1952   620 pipe_w S+   pts/0      0:00 grep dhcpcd

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

[Martin109]

Hi Martin109,

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:

1     0  2641     1  15   0   1584   352 -      Ss   ?          0:36 dhcpcd -t 10 -h cwl.littlefield.net -d eth0
0     0 18605  6362  18   0   1952   620 pipe_w S+   pts/0      0:00 grep dhcpcd

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

I see you're down under.  I'm in the UK.  Have a good night's sleep!

[Martin109]

While the Australians were sleeping, I was working!

Another thing, run "ps xl | grep dhcpcd" to see if dhcpcd is running.

The command "ps ax" will list all the running processes.

In my previous post, I reported the result of the first command, and there's no output relating to 'dhcpcd'.

Running the second produced a screen of text, including a line about dhcpcd.

Combining the two, I typed 'ps ax | grep dhcpcd' and got the output:

 3523 ?        Ss     0:00 dhcpcd -t 10 -h vector.linux.net -d eth0
 3674 tty1     S+     0:00 grep dhcpcd

Not sure what the difference is between 'ps xl' and 'ps ax', but the second seems to be producing the output you were after, indicating that dhcpcd IS running.