Dist-upgrading Ubuntu Server 18.04 located in remote site?

[Bo Berglund]

I am responsible for an Ubuntu Server 18.04 device inside a VMWare ESX virtual
environment. This server is operating an OpenVPN access system to the local LAN.
It is physically located in the USA whereas I live in Sweden.

I have throughout the years been on location twice yearly and could then do
sensitive maintenance work on the server, such as dist-upgrading it from 16 to
18.
Now due to COVID-19 I have been unable to travel to the server location since
autumn 2019. And every time I log on via PuTTY nowadays it nags about running
dist-upgrade to get it to level 20.

But my connection to this site is by way of an OpenVPN connection run by itself
and I obviously cannot update the OpenVPN server using it as the VPN server at
the same time, right?

Last time I did the dist-upgrade (16 => 18) I was on location and used the LAN
to connect by SSH. That worked fine in principle.

Now I need to do it over VPN and here I have a "backdoor" VPN server running on
a Raspberry-Pi device, so I can connect to the LAN using that as the server and
then SSH to the Ubuntu server. A bit scary but should work as long as it is at
all possible to do over VPN.

Question #1:
------------
Is it safe to do a dist-upgrade via SSH (PuTTY from Windows) at a distance of
some 8500 km using OpenVPN?

Question #2:
-------------
The /boot partition on this server is pretty small, just 472M with 72M freee
space...
I worry that it is not enough for what will happen on the dist-upgrade, so:

How can I safely remove all of the unused kernels to make space for new Ubuntu
20 kernels?
Again doing this at a distance.

Info:
-----
This is what I see about the drives (removed the tmpfs entries):

$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               461M     0  461M   0% /dev
/dev/mapper/vpnserver--vg-root      28G   15G   12G  55% /
/dev/sda1                          472M  376M   72M  85% /boot

So /dev/sda1 hosting /boot is the problem due to its small size...

And this is what ll lists:

$ ll /boot/
total 375518
drwxr-xr-x  4 root root     3072 2022-02-06 09:15 .
drwxr-xr-x 24 root root     4096 2022-02-06 09:14 ..
-rw-r--r--  1 root root   217432 2021-09-20 17:11 config-4.15.0-159-generic
-rw-r--r--  1 root root   217432 2021-10-15 08:16 config-4.15.0-161-generic
-rw-r--r--  1 root root   217432 2021-10-18 05:35 config-4.15.0-162-generic
-rw-r--r--  1 root root   217531 2021-12-08 11:15 config-4.15.0-166-generic
-rw-r--r--  1 root root   217531 2022-01-04 18:01 config-4.15.0-167-generic
drwxr-xr-x  5 root root     1024 2022-02-06 09:15 grub
-rw-r--r--  1 root root 60795727 2021-10-14 06:21 initrd.img-4.15.0-159-generic
-rw-r--r--  1 root root 60809700 2021-10-31 09:43 initrd.img-4.15.0-161-generic
-rw-r--r--  1 root root 60805485 2022-01-16 11:39 initrd.img-4.15.0-162-generic
-rw-r--r--  1 root root 60802475 2022-01-16 11:39 initrd.img-4.15.0-166-generic
-rw-r--r--  1 root root 60815651 2022-02-06 09:15 initrd.img-4.15.0-167-generic
-rw-r--r--  1 root root 15149612 2021-04-26 03:42 initrd.img-4.4.0-138-generic
drwx------  2 root root    12288 2018-02-23 13:23 lost+found
-rw-------  1 root root  4084049 2021-09-20 17:11 System.map-4.15.0-159-generic
-rw-------  1 root root  4084641 2021-10-15 08:16 System.map-4.15.0-161-generic
-rw-------  1 root root  4084622 2021-10-18 05:35 System.map-4.15.0-162-generic
-rw-------  1 root root  4085712 2021-12-08 11:15 System.map-4.15.0-166-generic
-rw-------  1 root root  4086497 2022-01-04 18:01 System.map-4.15.0-167-generic
-rw-------  1 root root  8453792 2021-09-20 17:25 vmlinuz-4.15.0-159-generic
-rw-------  1 root root  8453792 2021-10-15 08:19 vmlinuz-4.15.0-161-generic
-rw-------  1 root root  8453792 2021-10-18 05:37 vmlinuz-4.15.0-162-generic
-rw-------  1 root root  8461984 2021-12-08 10:53 vmlinuz-4.15.0-166-generic
-rw-------  1 root root  8466080 2022-01-04 18:13 vmlinuz-4.15.0-167-generic

Any suggestions/advice?


-- 
Bo Berglund
Developer in Sweden