Upgraded to Karmic, no internet!

[dr_voodoo]

OK, so I am having a bit of a nightmare with Karmic so far...

I have two old Dell Dimension 4600s, which were running Jaunty very well indeed, both of which I let auto-update to Karmic and now neither of them will connect to the Internet; when Firefox tries to look for updates - it crashes, Synaptic crashes. A bit annoying!

There's nothing wrong with the networking itself - I have managed to log into the admin panel of my router, but it seems that all communications out have been jammed - for Karmic, at least - I am typing this on Vista on the same network :s

[PorcelainMouse]

Can you be more specific? I think I had the same thing happen. After I let update-manager upgrade to 9.10 (from 9.04) I didn't have DNS. Now, that looks a lot like "no Internet," but you should clarify what symptoms you're experiencing.

At first, I thought there must have been an error when starting networking (service). But, I found that DHCP had given my system an IP address. (Best way to tell is to use 'ip addr list' in a command shell.) However, /etc/resolv.conf was empty. There was some warning message about not editing /etc/resolv.conf and I'm not sure if how new that is because DHCP clients have been manipulating that file for a long time.

Now, on my system, I'm used to editing /etc/network/interfaces directly. So, I won't bother mentioning what I did. (It's working now, but it's not clear why.) But, my NetworkManager applet doesn't seem to work. It says there are "No valid active connections found!" Which is inaccurate. Does your's work?

In any case, you should figure out if it's just DNS (name resolution) that isn't working or your networking.

[dr_voodoo]

I think it must be DNS since Eth0 reads 'connected', I can see my windows laptop on the network, and I can get into my router admin via the usual method... I don't know if synaptic uses DNS to find its downloads, it appears to be able to resolve the list of available programs for download but when I attempt to download them, it freezes then crashes out.
So yea, how did you manage to fix it when it happened to you?

p.s. I am still a linux n00b so if you can be verbose with full syntax for shell commands, that would help :)

cheers!

[PorcelainMouse]

Hmm, I hesitate because it doesn't seem likely that it fixed my problem. I may have done something else that fixed it w/o realizing it. But here goes:

In /etc/networking/interfaces, I had a sub-interface or virtual interface configured. So, there was eth2 and eth2:0. Well, on a whim I changed eth2 to eth2:1, thinking there might be some ambiguity. (I got this idea when using the 'ifup' and 'ifdown' commands. 'ifup eth2:0' returned "that interface is already up" when it wasn't, but eth2 was up. So, I leaped from there.)

Try this. See what's in /etc/resolve.conf. This is where all your DNS server IP addresses are kept. If there aren't any 'nameserver's listed, you're on the right track. That comes from DHCP (if you're using DHCP) so, I new something else was going on since my system got an IP address from DHCP.


> cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver <your DNS server will show here>


You can work your way out like this: You can check physical connectivity with your network equipment using 'ip link show', sort of like looking for the link LED. It'll show you all your interfaces and IP address assignments. If you don't see the network interface (which corresponds to a physical port on your system) you want, then the problem is lower than the networking subsystem; it's a hardware/kernel thing. Next, check for ip address, using 'ip addr list'. Next, 'ip route list' show your routing. That should make sense to you, if you stare at it for a bit. Next, ping your router by IP. If that works, you're networking is probably not the issue.


> ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:24:1d:1c:4a:e8 brd ff:ff:ff:ff:ff:ff
3: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:24:1d:1c:4a:ea brd ff:ff:ff:ff:ff:ff
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 36:3d:96:d1:24:34 brd ff:ff:ff:ff:ff:ff
> ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
...


Now, you probably don't need to do this from the shell. My networkManager applet isn't working, but it sounds like your's is working. I suggest cleaning out everything from there and setting it up again from scratch. That would be your equivalent of re-writing the /etc/networking/interfaces file, like I did.

I assume my NetworkManager doesn't work with my manual edits in /etc/networking/interfaces. But, I'd rather use the file than play with the applet so, I think I'm just going to leave it.

[PorcelainMouse]

Well, I guess I didn't fix it. After an unplanned reboot my system came up without DNS, again!

What is going on with the new networking? dhclient? What happened to dhcpcd? dnsmasq caching? I hated that in OS X. Now I'm noticing that DNS name resolution is taking a really long time.

Also, while were at it, I can't stop or restart the networking service!



> sudo service networking restart
restart: Unknown instance:
> sudo service networking status
networking stop/waiting
> sudo service networking help
Usage: /etc/init.d/networking {start|stop|restart|force-reload}
> sudo service networking restart
restart: Unknown instance:
> sudo service networking stop
stop: Unknown instance:
> sudo service networking force-reload
reload: Unknown instance:
> sudo service networking start
networking stop/waiting
> sudo service networking status
networking stop/waiting



dr_voodoo, did you find an alternate solution?