Dist-upgrading Ubuntu Server 18.04 located in remote site?
Robert Heller
heller at deepsoft.com
Mon Feb 7 02:44:43 UTC 2022
At Mon, 07 Feb 2022 00:32:37 +0100 bo.berglund at gmail.com, "Ubuntu user technical support,? not for general discussions" <ubuntu-users at lists.ubuntu.com> wrote:
>
> On Sun, 6 Feb 2022 16:08:14 -0500 (EST), Robert Heller <heller at deepsoft.com>
> wrote:
>
> >> 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?
>
> Well, it is a virtual machine inside a VMWare ESX system so it won't be subject
> to any separate power fail. We had one the night of Saturday-Sunday, which
> affected the RPi units, which restarted unexpectedly whereas the servers in the
> VMWare system just continued running including my target server.
I guess I meant someone on hand at the data center to mind the VMWare host
machine.
>
> >>
> >> 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:
> >> -----
>
> I forgot to add the following command and result in my post:
>
> $ uname -r
> 4.15.0-167-generic
>
> So I am currently running 4.15.0-167-generic
>
>
> >> 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?
>
> Meanwhile I found old notes on the way to free space in /boot so I have done
> this:
> 1) List the available kernels:
>
> $ dpkg --list 'linux-image*' | grep ^ii
> ii linux-image-4.15.0-159-generic 4.15.0-159.167 amd64 Signed
> kernel image generic
> ii linux-image-4.15.0-161-generic 4.15.0-161.169 amd64 Signed
> kernel image generic
> ii linux-image-4.15.0-162-generic 4.15.0-162.170 amd64 Signed
> kernel image generic
> ii linux-image-4.15.0-166-generic 4.15.0-166.174 amd64 Signed
> kernel image generic
> ii linux-image-4.15.0-167-generic 4.15.0-167.175 amd64 Signed
> kernel image generic
> ii linux-image-generic 4.15.0.167.156 amd64 Generic
> Linux kernel image
>
> Based on this I did:
>
> $ sudo apt remove linux-image-4.15.0-159-generic
> $ sudo apt remove linux-image-4.15.0-161-generic
> $ sudo apt remove linux-image-4.15.0-162-generic
> $ sudo apt autoremove
>
> After this I got a new map:
>
> $ df -h
> Filesystem Size Used Avail Use% Mounted on
> udev 461M 0 461M 0% /dev
> /dev/mapper/agivpnserver--vg-root 28G 14G 13G 52% /
> /dev/sda1 472M 205M 243M 46% /boot
>
> /boot is now 54% free space...
>
>
> >
> >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].
>
> I did not do the purge before but when I tried it now I got this after I also
> did the remove for 166:
>
> $ sudo apt remove linux-image-4.15.0-166-generic
> $ sudo apt autoremove
>
> $ df -h
> Filesystem Size Used Avail Use% Mounted on
> udev 461M 0 461M 0% /dev
> /dev/mapper/agivpnserver--vg-root 28G 14G 14G 50% /
> /dev/sda1 472M 135M 314M 30% /boot <==
>
> $ sudo apt purge linux-image-4.15.0-159-generic
> -- succeeded
> $ sudo apt purge linux-image-4.15.0-161-generic
> -- succeeded
> $ sudo apt purge linux-image-4.15.0-162-generic
> -- succeeded
> $ sudo apt purge linux-image-4.15.0-166-generic
> .....
> Do you want to continue? [Y/n]
> (Reading database ... 151431 files and directories currently installed.)
> Purging configuration files for linux-image-4.15.0-166-generic (4.15.0-166.174)
> ...
> I: /vmlinuz is now a symlink to boot/vmlinuz-4.15.0-167-generic
> I: /initrd.img is now a symlink to boot/initrd.img-4.15.0-167-generic
> rmdir: failed to remove '/lib/modules/4.15.0-166-generic': Directory not empty
>
> Is the last message OK regarding non-empty directory?
The /lib is on the root file system, so it is not a problem at this point --
it does need to be looked into at some point.
>
> This last purge set of commands did not change the state of the disk space
> visibly by the df command.
>
> >
> >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).
>
> As described above I also dealt with 166 and this brings usage down to 30% on
> /boot.
Yes, there should be more than enough free space on /boot for the upgrade.
>
> >You should be sure to do 'apt full-upgrade' and reboot before doing the
> >release upgrade. And do 'apt autoremove'.
>
> Yes, that will be the last step before actually running the relesae-upgrade...
>
>
--
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