The GUI will fail with the libglx.so issue (probably unrelated to networking). To fix this:
sudo ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so /usr/lib/xorg/modules/extensions/libglx.so
(then run “sha1sum -c /etc/nv_tegra_release” again to see if all files are ok)
It is possible for networking to be up and functioning with DNS failing to resolve named addresses (this is not a network failure, but networking would look like it failed if DNS is failing). If “ifconfig” showed an address then when there is a failure you should first try a dotted-decimal format address for any testing. An example is that host lookup of “nvidia.com” (“host nvidia.com” command) shows as 126.96.36.199, so you could “ping 188.8.131.52” and see if this works; if this works then try “ping nvidia.com”; if this fails, then it is a DNS issue instead of a network up/down/fail issue. If ping of the dotted-decimal format address fails, then the issue is a true network failure. Can you “ping 184.108.40.206”? Can you see a response from the query command “host 220.127.116.11”?
Within a private network (addresses you see on your router which the outside world does not see), then you have some added complications if you use a named address such as “tegra-ubuntu”. Having more than one Jetson with each one trying to use “tegra-ubuntu” makes it mandatory that no more than one Jetson can respond to this (the router cannot give the same name to two devices). None of those issues are specific to a Jetson, or even to Linux. So without seeing “ifconfig”, and without knowing how dotted-decimal format addresses respond, it isn’t possible to know if it is a network issue or a DNS issue. If it is a DNS issue there are yet more debug steps compared to a plain network failure. Other computers on your private network depend on the router to convert “tegra-ubuntu” named addresses, so this is equivalent to DNS internal to the private network. Accessing a Jetson by anything but a dotted-decimal address implies a router issue when named addresses fail.
So far there is no information given as to whether a failure you’ve seen is from outside the Jetson to the Jetson, versus inside the Jetson to the outside, and whether named address format is used versus dotted-decimal format. In the case of going from Jetson to outside the Jetson debugging would also require knowing if the destination is part of the private network or if the destination is the outside world. For “apt-get upgrade” to work I will guess that the failures involve going from one computer to another within the private network, and that outside of the private network the internet works (which in turn implies a router issue with network being fully functional and DNS being functional).