[SOVLED] emerge fails/wget fails name resolution temporarily

[Hironatashima]

So I have seen this crop up on the forum a few times, and after digging around, I have found no solution to this.

I am sure that there is an issue with some sort of DNS service locally. I'm running the gentoo CLI environment inside of a VirtualBox VM. Everything up to this point has been fine. I started with a Live KUBUNTU CD and used it as my installation source, and made it through every aspect of the handbook up until this point. I even backtracked all the way to prior to the chroot, and checked all of my networking steps to make sure everything is good. As long as I am in the CHROOT environment, my networking works just perfectly. as soon as I reboot, and remove the 'live cd' image from the VM, and start up again, it looks like none of my networking is actually working. I do the ifconfig -a command, I have no actual IP Addresses, I cannot resolve, etc. I know my settings in the VM are correct, as when I boot into a installation image with the very same VM, networking is fine.

I have messed with the hosts files, the resolv.conf file, the make.conf, and the repos.conf, but the more I mess with it, the more I'm thinking that I'm missing my networking daemon somehow.

Thanks in advance for helping me out.

[Hironatashima]

I've been messing with this for a long while now. The things I've tried to this point have revealed the following facts:

* my DHCPcd was not issuing an ip address to my virtual ethernet card
* DNS seems to still be failing
* After getting an IP to my card, by setting it statically, the emerge/wget still fails to fetch things due to a DNS resolution failure.
*I discovered that I had set up a symlink to net.lo with a name of net.et0, when my ethernet interface was actually named enp0s3. I fixed this and did the rc-update accordingly.

This puts me to a point to where I'm going to try to install Gnome or KDE in a chroot environment from a liveCD, so I can try and troubleshoot through a graphical interface, provided it works.

[ct85711]

Ok, when you are troubleshooting your network issues; it is easier to ignore dns all together, until you have basic networking working. DNS converts a url like www.google.com to an ip address like 172.217.6.132; however if you can't even ping an ip address it's self, then worrying about DNS is a waste of time. This means you need to have an ip address on your interface (an 169.254.x.x is an APIPA address, meaning a trash/worthless address).

The 2 common things you use to test that your computer can communicate can communicate to the internet, is first try pinging your router (it is going to have an ip address, most commonly ending with .1; so if your ip address is 192.168.0.50, your router is would most likely be 192.168.0.1). This test makes sure you can even ping your router (usually also the default route). Next you should ping an ip address on the web, a lot of people like doing 8.8.8.8 (it's easy to remember, google's dns server). The second test makes sure your computer can ping someone else on the internet. If this works, then you look at your dns and resolv.conf. If this test doesn't work; then your computer doesn't know who to forward the packets too; which is what the default route sets up.

Typically, when you use DHCP (to get an ip address automagically), that would already be setup; and you may only need to worry about the resolv.conf. When you statically set your ip address, you also have to setup the default route too.

For reference, for setting up the ip address statically from the Installation Handbook: (be sure to change eth0 to your interface's name)

[Hironatashima]

First off, thanks very much for the response.

And now to the meat of the matter. I'm tracking all of the fun stuff with the networking. The issue that I was having trouble determining was where my issue was rooted at. At first I thought it was a DNS issue, that was at 12 this morning when I was getting delirious. After I hammered against this thing for a while, I checked my ifconfig command, and realized that my NIC wasn't drawing DHCP. I definitely do not want my system to run static IP. I want my system to draw DHCP. I think there may be a kernel config issue, or a module loading issue somewhere. any advice there? I've run through the handbook relentlessly, and can't help but think I'm missing something.

If you need any details, let me know.

[Hironatashima]

I've determined that this is no longer a fetch issue, based on the information from ct85711, and more tinkering around. It's really just getting the NIC on my VM to pull a DHCP address.

After a bunch of messing around with configurations, and files and stuff in Gentoo, I started looking at my VM Hypervisor. I turned on the DHCP server on VirtualBox, and restarted the DHCP client daemon, and magically, everything started working!

We can update this to Solved, guys! Thanks for your input ct85711! Despite the fact that I knew all the networking stuff you were telling me, your advice forced me to look at other aspects of the stuff I was working on.

Ultimately, my lesson learned here is: If you're running in a VM, you have added another dimension of complexity. You have to tell the Hypervisor how the VMs will be talking to the outside world, if they will.