You are not logged in.
Friends:
Issue on hand.
I upgraded Arch which is running as guest inside VirtualBox.
When machine boots up I don't have access to network.
I cant ping yahoo or google or any site.
The following steps work for regaining network access back
cat /run/dhcpcd.pid
180
kill -2 180
dhcpcd
now ping yahoo.com works fine
So not sure why this problem.
I am willing to put out any log information. I don't know what to look for.
Please help.
-N
Last edited by savithari (2013-06-26 03:52:52)
Offline
First of all, the "please help" in your title is a bit annoying. Most of the threads here are for help, you're not going to get better responses with that.
So how is your VM connecting to the internets in the first place.
Offline
I kill the proc id in the /run/dhcpcd.pid.
Once I do that and I run dhcpcd then the network works.
After that I have full access to internet.
Arch is running inside the VirtualBox NAT mode.
Offline
I think we have a complete failure to communicate here. I was asking how that pid is showing up in the first place. You know that run is a volatile filesystem, right? So anything that is there will not survive a reboot as it is created dynamically. So that pid file means that there is a dhcpcd process that relates to it that is running. So how is that dhcpcd process getting started? It isn't just magically creating a pid file for nothing.
Offline
I am not sure where the original dhcpcd is getting started from.
All I know is if I reboot, then I see
journalctl -b -p err
dhcpcd[170] no valid interfaces found
Please see the following link. (I know images are a big turn off but this is the only way I can show what is going on)
http://i.imgur.com/zZwCw93.png
As you can see it says "no valid interfaces found"
So if there are places where I can dig for more info and post back here, I will do so if I can get some hints on how to do this.
Regards
-N
Offline
I'm not sure where the idea to get the pid to kill dhcpcd came from - it seems a very roundabout way of doing the following
# killall dhcpcd
# dhcpcd <interfacename>
However this is a bit beside the point. dhcpcd looks like it is starting from a dhcpcd .service file and failing there. When you restart it, you do so without specifying any interface name and it works. This suggests to me that the service file is using a interface name, and an incorrect one at that.
This is all just suspicion to be verified:
1) you have dhcpcd@eth0.service enabled
2) you have "predictable interface names" ... which ironically means I can't predict what they'd be, but it would start with something like enpS***.
If correct, there are three possible solutions (choose only one):
1) revise the service to not specify an interface,
2) revise the service to specify the correct interface which you can determine from the output of `ip link`
3) use the udev rule to keep "old" style interface naming.
(edit: as an aside, I had the same reaction as WW to the "please help" in the title)
Last edited by Trilby (2013-06-23 21:12:04)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I would imagine that if you are using the dhcpcd.service (which the output would seem to indicate), the service is starting before the interface/device is properly initialized. So if you take Trilby's advice above and instead use the dhcpcd@.service, specifying the name of the service you want it to work on (in Trilby's exampe is point #1 was eth0), that service file uses the BindsTo= function to ensure that the interface is up before starting the service, thus ensureing you don't just get a timeout like you are experiencing.
(edit: as an aside, I had the same reaction as WW to the "please help" in the title)
I'd like to just repeat that again, since you didn't seem to get the message there.
Offline
Trilby wrote:(edit: as an aside, I had the same reaction as WW to the "please help" in the title)
I'd like to just repeat that again, since you didn't seem to get the message there.
I've put us all out of our collective misery...
Offline
2) you have "predictable interface names" ... which ironically means I can't predict what they'd be, but it would start with something like enpS***
Interface link name is enp0s3
If correct, there are three possible solutions (choose only one):
1) revise the service to not specify an interface,
2) revise the service to specify the correct interface which you can determine from the output of `ip link`
3) use the udev rule to keep "old" style interface naming.
How do you do the above steps, any link would be of great value
WW & jason, sorry I did not realize the help thing in the subject line, kindly excuse
Offline
All three options are covered in the wiki: please make some attempt to help yourself.
Offline
I am sure most of the folks in these posts are smart.
I am unable to find info for this
All three options are covered in the wiki: please make some attempt to help yourself.
I tried but I am not sure in what context I should be looking for.
netcfg or dhcpcd. Where should I be looking under ?
I know you folks know but help out a fellow noobie.
-N
Offline
On the Networking page...
Offline
Folks thank you for the help. It looks like I had to do some cleanup and based on jason's answers I got my issue resolved.
I had to go to
/etc/systemd/system/multi-user.target.wants
folder.
Under that I had to clean out aka remove the *dhcpcd* links.
I then did a
systemctl start dhcpcd@enp0s3
This started the network.
I followed this with
systmectl enable dhcpcd@enp0s3
After this I rebooted twice and made sure it is all working as in the network comes up and I can do
ping www.yahoo.com
So a big Thank You goes out to jasonwryan.
-N
Offline