Thanks for mentioning me in the script. Kinda cool.
]]>In the network script, in the ifdown() section, it read:
if [ -f /etc/dhcpc/dhcpcd-${1}.pid ]; then
/bin/kill `cat /etc/dhcpc/dhcpcd-${1}.pid`
which basically just deletes the .pid file without dhcpcd actually releasing anything. Bad way to do it.
I changed it to read:
if [ -f /etc/dhcpc/dhcpcd-${1}.pid ]; then
/sbin/dhcpcd -k
which causes dhcpcd to release and then delete the .pid and .cache files.
Problem solved.
]]>I did look at how Mepis is doing it, their startup scripting is different which makes comparison different. There is no rc.conf that I can find.
I watched the start up message sequence and it's pretty close to what I have with Arch now, but still something isn't quite right because the problem still exists.
I feel that it is in the network script itself, but I'm not spotting the problem when looking through it.
I do appreciate all the suggestions and assistance.
]]>I ran /etc/rc.d/network start after booting up and exact same problem, network fails to start.
If I run dhcpcd eth0 then it assigns the IP.
Then run /etc/rc.d/network start and it starts fine.
??????????????
I know I must be missing something simple.
]]>I also booted a LiveCD a few times and connection was no problem.
Adding axnet_cs to the modules array did stop the modprobe -r error message on shut down, but still having the same dhcp problem on start up.
I'm at a loss here now. Using SimplyMepis it works perfectly, so I know it isn't a hardware issue, but rather a scripting or config error but so far no luck finding it.
]]>My advice still is, don't use dhcp on the machine, set the nic up with a static ip. See if things work then. If they do, progress on dhcp, if not, check your machine. Ok, you can still mix all up and see no end. A structured procedure is better, as far as I am concerned.
yeah, good idea... seeing as there's no where else to go from here... all you have to do is use the value in rc.conf for a static ip and make sure your IP is outside the dhcp range (to be safe). Then try rebooting
]]>Perhaps this is preventing dhcp from releasing the lease and clearing associated files, causing an error on restart?
*Scratching head*
In most cases leases last for several days, so machines in a large net will not be mixed up again and again. If you have not changed the lease times, there will be a lease time about a week or so.
My advice still is, don't use dhcp on the machine, set the nic up with a static ip. See if things work then. If they do, progress on dhcp, if not, check your machine. Ok, you can still mix all up and see no end. A structured procedure is better, as far as I am concerned.
]]>boot
...
# dhcpcd eth0
# ifconfig eth0 down
# modprobe -r axnet
# modprobe axnet (?)
# dhcpcd eth0
I'm really at a loss here... did you try adding the axnet module to the module arrays?
]]>Well, if it has nothing to do with modules/pcmcia, then why do you have to remove/reinsert the card to get it working?
Once you boot, try not touching the card and running "dhcpcd eth0" and see if that works...
Just a quick and easy way to reinitialize dhcpcd. If I run "dhcpcd eth0" it assigns an IP quickly. Pretty much the same as removing and reinserting the card.
maybe try upping the dhcp timeout
OK, tried upping the timeout to 60 seconds. No better result. The router normally assigns an IP in about 10 seconds or so when everything is working properly.
can you compare the lsmod before and after you do the boot-remove-reinsert process?
Exactly the same.
I am thinking the problem may be in the shutdown process. I watched the messages during shutdown and when it tries to modprobe -r the axnet module it errors saying the axnet module is still in use. Perhaps this is preventing dhcp from releasing the lease and clearing associated files, causing an error on restart?
*Scratching head*
]]>It things go well then, the problem is your router, If not, the problem is on your machine.
]]>