Dist-upgrading Ubuntu Server 18.04 located in remote site?
Robert Heller
heller at deepsoft.com
Sun Feb 6 21:08:14 UTC 2022
At Sun, 06 Feb 2022 21:00:24 +0100 bo.berglund at gmail.com, "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
>
> 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?
Probably. So long as nobody yanks the power. Is there noone local who can
babysit the machines?
>
> 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?
apt autoremove
Then,
apt purge linux-image-4.15.0-XXX-generic
where XXX is the version number of the unused kernel(s) [159, 161, 162, and
166, assuming 167 is the running kernel].
The 18.04 initrd.img files are 59M, the vmlinuz files are 8.1M and the System.map
files are 3.9M. The 20.10 (I don't have a 20.04 machine) file sizes are 59M
for the initrd.img file, 15M for the vmlinuz file, and 5.7M for the System.map
file. I am guessing that the 20.04 kernel files are similarly sized, so
freeing up one or two older kernels should free up enough disk space (and
freeing up 4 is even better).
You should be sure to do 'apt full-upgrade' and reboot before doing the
release upgrade. And do 'apt autoremove'.
It also can't hurt to clean out /var/cache/apt/archives/ and any other cruft
that might be under /var/cache, just to be sure you have enough free disk
space. Maybe do some housecleaning under /var/log as well.
>
>
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller at deepsoft.com -- Webhosting Services
More information about the ubuntu-users
mailing list