Lost IP address (package management/removal issue?)

6 respostas [Última entrada]
Avron
Desconectado
Joined: 08/18/2020

Sorry for a bit long message, I am trying to provide what may be relevant information to my problem.

I am using a desktop which has been permanently on for several months, I only reboot for kernel upgrades. The IPv4 address was always kept until today when I saw that network was not working (it works after invoking dhclient manually).

I saw from syslog that the IP address was removed this morning by the avahi daemon:

Feb 18 05:43:25 albert NetworkManager[852]:   [1613623405.5877] manager: NetworkManager state is now CONNECTED_SITE
Feb 18 05:43:25 albert avahi-daemon[819]: Withdrawing address record for 192.168.1.23 on ens10.
Feb 18 05:43:25 albert avahi-daemon[819]: Leaving mDNS multicast group on interface ens10.IPv4 with address 192.168.1.23.
Feb 18 05:43:25 albert avahi-daemon[819]: Interface ens10.IPv4 no longer relevant for mDNS.
Feb 18 05:43:27 albert ntpd[1365]: Deleting interface #3 ens10, 192.168.1.23#123, interface stats: received=1874, sent=1873, dropped=0, active_time=470701 secs
Feb 18 05:43:27 albert ntpd[1365]: 192.168.1.1 local addr 192.168.1.23 -> <null>

I never heard about this daemon before but I guess it did that for a reason. In the apache logs, I see records at least every 30s of requests from 192.168.1.23, so the same machine, from the seafile client, until 8s before the above log, then nothing, so this is consistent with the assumption that this is when the address was lost.

I searched the address allocation logs, the last one before that is:

Feb 18 01:23:20 albert dhclient[1202]: DHCPREQUEST of 192.168.1.23 on ens10 to 192.168.1.1 port 67 (xid=0x35e2b2ad)
Feb 18 01:23:20 albert dhclient[1202]: DHCPACK of 192.168.1.23 from 192.168.1.1
Feb 18 01:23:20 albert dhclient[4870]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): No such file or directory
Feb 18 01:23:20 albert dhclient[1202]: bound to 192.168.1.23 -- renewal in 36043 seconds.

In previous logs from dhclient, it wasn't like that:

Feb 17 05:43:24 albert dhclient[1202]: DHCPREQUEST of 192.168.1.23 on ens10 to 192.168.1.1 port 67 (xid=0x35e2b2ad)
Feb 17 05:43:24 albert dhclient[1202]: DHCPACK of 192.168.1.23 from 192.168.1.1
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6940] dhcp4 (ens10):   address 192.168.1.23
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6940] dhcp4 (ens10):   plen 24 (255.255.255.0)
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6941] dhcp4 (ens10):   gateway 192.168.1.1
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6941] dhcp4 (ens10):   lease time 86400
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6942] dhcp4 (ens10):   nameserver '192.168.1.1'
Feb 17 05:43:24 albert NetworkManager[852]:   [1613537004.6942] dhcp4 (ens10): state changed bound -> bound

So /usr/lib/NetworkManager is missing while it wasn't before. I don't know whether this explains the lost IP address but maybe I know why it is missing.

I had the rdnssd package installed before I got my computer and I don't know the reason for that, but since I don't know the reason for any other packages anyway, I thought I should keep it and update it like all others.

This package was marked as "kept back" at all recent upgrades, which worried me. I searched and found answers saying that this happened when an updated package had more dependencies than the installed version, in which case it was necessary to use "apt install" as if it would not already be installed, so I did that.

For some reason, this has removed a number of packages:

network-manager-pptp:amd64 (1.2.6-1)
gnome-control-center:amd64 (1:3.28.2-0ubuntu0.18.04.6)
network-manager-gnome:amd64 (1.8.10-2ubuntu3)
network-manager:amd64 (1.10.6-2ubuntu1.4+9.0trisquel2)
network-manager-openvpn:amd64 (1.8.2-1)
network-manager-openvpn-gnome:amd64 (1.8.2-1)
network-manager-pptp-gnome:amd64 (1.2.6-1)

In my recollection, apt did not ask "are you sure?" about that, so I was hoping this was ok, but perhaps I missed something. After that, I used apt autoremove and this has removed:

gkbd-capplet:amd64 (3.26.0-3ubuntu0.18.04.1)
gnome-control-center-data:amd64 (1:3.28.2-0ubuntu0.18.04.6)
libteamdctl0:amd64 (1.26-1)
libpkcs11-helper1:amd64 (1.22-4)
gnome-user-docs:amd64 (3.28.2+git20180
715-0ubuntu0.1+9.0trisquel2)
apg:amd64 (2.2.3.dfsg.1-5)
openvpn:amd64 (2.4.4-2ubuntu1.3),
ubuntu-system-service:amd64 (0.3.1)
pptp-linux:amd64 (1.9.0+ds-2)
gnome-settings-daemon:amd64 (3.28.1-0ubuntu1.3)
libwhoopsie-preferences0:amd64 (0.19)
whoopsie-preferences:amd64 (0.19)
libndp0:amd64 (1.6-1)
libnss-myhostname:amd64 (237-3ubuntu10.43)
libcolord-gtk1:amd64 (0.1.26-2)
gnome-control-center-faces:amd64 (1:3.28.2-0ubuntu0.18.04.6)
pulseaudio-module-bluetooth:amd64 (1:11.1-1ubuntu7.11)
libgnomekbd8:amd64 (3.26.0-3ubuntu0.18.04.1)
system-config-printer-common:amd64 (1.5.11-1ubuntu2+9.0trisquel1)

Could that explain the problem with the IP address? What should I do to avoid further trouble? Remove rdnssd and install again the packages that were removed because of it? Is there also some configuration needed?

Then the lesson to remember could be to ask here before saying "yes" to any apt operation that wants to remove something.

By the way, I also installed python-certbot-apache and seafile-gui the same day (and configured seafile to use apache and SSL, using certbot to get a certificate) used, but that hasn't removed anything.

Magic Banana

I am a member!

Desconectado
Joined: 07/24/2010

As far as I understand (little actually, when it comes to networks), the router is responsible for attributing the IP address through DHCP. See in the configuration of your router (probably through a Web interface: just type its IP address in the address bar of your Web browser) if you can define a permanent IP address based on the MAC address of your network card.

lutes
Desconectado
Joined: 09/04/2020

Synaptic informs me that the rdnssd package (1.0.3-3ubuntu2) conflicts with the network-manager package (1.10.6-2ubuntu1.4+9.0trisquel2). A well conceived package manager should thus make sure that only one of them is installed on a given system, at any given time.

> ask here before saying "yes" to any apt operation that wants to remove something.

Most advisable. And remember that entering a sudo password gives you the privilege to break your system. You can always simulate the command instead, which gives you more time to think about what you are going to do and does not require root privileges. For instance, running:

$ apt -s install rdnssd

on my system suggests that the command would do exactly the same things as it did on yours. I do not wish to uninstall network-manager, though, so I will not run it wet.

If you want network-manager back, I think you should install network-manager-gnome, it should pull all the other "removed" packages. Not sure about the "autoremoved" ones, though. You can always check with:

$ apt -s install network-manager-gnome

Avron
Desconectado
Joined: 08/18/2020

Thanks, I didn't know about this apt option, it sounds like something to always do first.

On sudo, I have been doing a lot of installation that needs it recently, this has probably affected my vigilance and your reminder is welcome. Indeed, with the level of thinking I had, I could have broken things far worse. From now on, I'll apply the "have a break with a hot drink first" principle before any sudo action.

Now, I am guessing that I should just have removed rdnssd and kept all the removed packets.

"apt -s install gnome-control-center" says it would reinstall all what was removed except:
openvpn
network-manager-openvpn
network-manager-openvpn-gnome
libpkcs11-helper1

However, I don't know in what way I should take into account the warning "Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation!".

Does it sound reasonable to remove rdnssd and install package gnome-control-center in order to get back to the previous configuration?

The last lib is a dependency of openvpn, which is an openvpn daemon, so I guess it is to use the machine as a VPN server. Although I am not using that feature, it could be better to also reinstall this?

lutes
Desconectado
Joined: 09/04/2020

I would stick with the packages that were removed by the previous command. You can add them one by one but the one I suggested should re-install them all, according to the output I got.

Autoremove is cleaning stuff that might have been sitting there for a while (but at most since you last ran the command), so it can sometimes be a bunch of packages. It is my experience that they can be removed safely. Anything you installed manually is excluded from the autoremove list. If any of these were related to network-manager, they will be automatically re-installed if needed.

> I don't know in what way I should take into account the warning "Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation!".

If no update is running at the time of the simulation, it is safe to ignore this. If it is in fact the case, then the simulation does not take it into account to generate its results, so when you run the actual command, the outcome might differ because the system state might have changed in-between. "Locking" means locking the state of the system (packages and versions) until the command has exited. So "locking is deactivated" means that another process might access the system and modify it while the simulation is running.

Avron
Desconectado
Joined: 08/18/2020

On my computer, "apt -s network-manager" said it would only reinstall 11 of them only, so I asked to install network-manager-gnome and then network-manager-openvpn-gnome, which has reinstalled them all and no other package.

This morning I had lost the IP address like yesterday and got it back with "sudo dclient ens10" (ens10 is the name of my network interface for some reason). I'll see how it is tomorrow.

I had a look at Trisquel documentation on the website (French and English mainly), the page for maintaining the system using command line just gives the essential command names (and with apt-get instead of apt) without any further explanation. Wouldn't it be good to provide more information there to help users not doing mistakes such as what I did?

I am ok to try but of course more experienced people should check. Maybe people who feel more confident with command line are a minority but it could also be because there is no easy guide

In addition, my recollection of man pages of proprietary Unix I read more than 20 years ago is that there was always an "example" section that really helped when discovering some command, while I can't see any such section nowadays.

Magic Banana

I am a member!

Desconectado
Joined: 07/24/2010

To reinstall all packages missing from the default install, you can simply install the metapackages named "trisquel" and "trisquel-recommended". They must have been removed on your system.