Join Log in
Score:0
Bruce Adams avatar Ubuntu

Ubuntu 22.04 LTS: understanding how the network setup works - network only works if enabled from recovery console (after attempting to install cuda)

gb flag
Bruce Adams

Summary

I have got my Ubuntu 22.04LTS desktop system into a situation where the network works provided I enable it from recovery mode and then resume boot normally.

If I boot normally the network connection is 'activated' but I cannot actually connect to the internet.

I need help trying to understand and diagnose the problem and restore network functionality.

Symptoms

Networking fails when I boot into ubuntu (without first enabling network in recovery mode)

  • The IP address selected is correct.
  • The gateway is correct.
  • The DNS servers are correct.

(Correct meaning they are the same for a working network connection as for when it not working)

But I cannot access anything on the internet. There is a "question mark" overlaid on the network icon.

  • I cannot ping 8.8.8.8, 127.0.0.1 or the nameservers.
  • nslookup fails to resolve as well

The network manager log includes:

> journalctl -x -v _SYSTEMD_UNIT=NetworkManager.service
device (enp0s31f6): Activition: successful, device activated.

How I broke it

I wanted to experiment with cuda on my system so I installed the cuda packages via the instructions here

As part of doing this it installed version 520 of the nvidia drivers.

This resulted on booting reporting "NVRM: supported through the NVIDIA Legacy 470 drivers." and hanging forever at "Continuing probe..."

I disabled fastboot to get to grub, booted to recovery and installed version 470.

The system now boots again but the network does not work. I have both a wired and wireless connection and neither work.

I'm not sure why this has happened is as while my graphics card is Nvidia my network cards are not. What in the installation needed to affect the network setup?

The wired connection is listed as connected. It has the expected IP address and gateway.

The GUI reports "Activation of network connection failed" but this seems to be for the wifi only. If I disable that this goes away.

I was able to get the wifi into the same "question mark" mode as the LAN connection at one point but I not managed to connect to my SSID since.

I can't see anything obvious in the network manager log.

I ran a successful distribution upgrade from 20.04 a while ago if that is relevant.

What I have tried so far

systemctl restart NetworkManager
systemctl restart systemd-networkd

alternately disabling IP6 and IP4 but so far nothing works.

reinstalling network manager

I tried switching off the firewalld via systemctl.

uninstalling everything related to nvidia 470. This results in the graphic display having a lower than desired resolution but, perhaps unsurprisingly, has no effect on the network.

uninstalling everything obviously related to cuda.

> dpkg -l | grep cuda | xargs sudo apt remove -f

Questions

Q What does "Activation of network connection" actually mean here?

Q What needs to happen beyond "activating the network connection" for the network to actually work?

Q What does a question mark over the network icon mean?

Q What else can I try to diagnose and fix it?

One critical difference in the working case is this line from route:

default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6

See below for more details

Not working case:

> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 854001sec preferred_lft 854001sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:fe:8d:1b:aa brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

# inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB driver: r8188eu

# netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    27075      0      0 0          1608      0      0      0 BMRU
lo       65536     5441      0      0 0          5441      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 virbr0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

Working case after:

  • boot in recovery mode
  • enable networking
  • resume normal boot

New output:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp0s31f6
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
192.168.123.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

$ netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0   1500        0      0      0 0             0      0      0      0 BMU
enp0s31f  1500    85232      0      1 0         46876      0      0      0 BMRU
lo       65536     4250      0      0 0          4250      0      0      0 LRU
virbr0    1500        0      0      0 0             0      0      0      0 BMU

$ inxi -N
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e
  Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB
    driver: r8188eu

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:4d:7b:64:62:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 862734sec preferred_lft 862734sec
    inet6 fe80::ba46:11c7:b4d1:16b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlx503eaa945dc9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 50:3e:aa:94:5d:c9 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ed:8b:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:05:f9:90:04 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
250
0 + 3
cc flag
ubfan1
You can edit your original question rather than deleting it and posting again. Pretty mysterious, but probably related to some dependency problem -- there are answers on this site to install CUDA from the Nvidia .run script and avoid the dependency mess.
0
Reply
Bruce Adams avatar
gb flag
Bruce Adams
I may try that (carefully) after I've fixed the network / dependency mess.
0
Reply
Bruce Adams avatar
gb flag
Bruce Adams
I asked a related question on [unix stackexchange](https://unix.stackexchange.com/q/722929/162453) which now has a bounty attached as an incentive (though I have had little luck with bounties being enough to trump obscure and arcane questions in the past).
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.