[GUIDE] Ubuntu 18.04 to 20.04 upgrade guide

SYSTEM INFORMATION (after the upgrade)
Ubuntu Linux 20.04.3
Perl version 5.030000
Python version 3.8.10
BIND version 9.11
Postfix version 3.4.13
Apache version 2.4.41
PHP versions 7.2.34, 7.3.33, 7.4.27, 8.0.14, 8.1.2
Webalizer version 2.23-08
Logrotate version 3.14.0
MySQL version 8.0.27-0ubuntu0.20.04.1
ProFTPD version 1.35
SpamAssassin version 3.4.4
ClamAV version 0.103.5

In essence I used this guide to upgrade.
https://www.cyberciti.biz/faq/upgrade-ubuntu-18-04-to-20-04-lts-using-command-line/
The difference is that in the beginning, this command was giving me problems, since I am on a digitalocean droplet.
sudo do-release-upgrade -d

Invalid package information

After updating your package information, the essential package
'ubuntu-minimal' could not be located. This may be because you have
no official mirrors listed in your software sources, or because of
excessive load on the mirror you are using. See /etc/apt/sources.list
for the current list of configured software sources.
In the case of an overloaded mirror, you may want to try the upgrade
again later.


Restoring original system state

Aborting
      g package lists... 2%
*** Collecting problem information

The collected information can be sent to the developers to improve the
application. This might take a few minutes.
Reading package lists... Done
Building dependency tree
Reading state information... Done
................
=== Command terminated with exit status 1 (Wed Jan 26 18:03:00 2022) ===

So I had to use this command instead:
sudo RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1 do-release-upgrade

During the upgrade process, all files that were detected to have been modified, I kept them as they were, by clicking ‘No’ to their replacement by newer version default files.
After a reboot, I check the cd /etc/apt/sources.list.d/ folder and found 2 sets of files for each repository. The files ending in .distUpgrade are just backups of the original file. I checked all .list files and found that all but one were correctly modified during the upgrade to point to ‘focal’ sourses.
The faulty one was mssql-release.list which contained a commented out source:
# deb [arch=amd64] https://packages.microsoft.com/ubuntu/18.04/prod bionic main
which I think has to be modified to
deb [arch=amd64] https://packages.microsoft.com/ubuntu/20.04/prod focal main

I then did

sudo apt update
sudo apt upgrade

I went into Virtualmin and was greeted by a message on the dashboard informing me that the OS was upgraded and urging me to click a button to update this in the system, which I did.
I also run:
sudo update-grub and rebooted.
Then I went in Virtualmin System Settings > Re-Check Configuration.

All seems OK. CPU & RAM usage seems to have increased by about 10% judging by the charts.

(this post was also helpful Upgrade Ubuntu 18.04 to 20.04 - #4 by QuarkSolution)

Would you please add the word “guide” to the post title so that visitors don’t mistake this for a help request?

1 Like

Good idea. Done.

Actually, now that the system has relaxed, CPU & RAM is on par with Ubuntu 18.04. No change.

I noticed soon after posting, that all my previous IPtables Firewall rules were all gone.
Only F2B had rules in my firewall - everything else was gone with the upgrade to Ubuntu 20.04 I guess.
So what I did was to restore my previous rules from backup (/etc/webmin/firewall/iptables.save) and restart F2B which brought back its own.

Another thing that created havoc for me was F2B started throwing 'Script error' all over its log file.

stderr: ‘iptables: Chain already exists.’
stderr: “iptables v1.8.4 (legacy): invalid port/service `sftp’ specified”
stderr: ‘iptables: Too many links.’
ERROR Failed to stop jail ‘postfix-sasl’ action ‘iptables-multiport’

F2B also was creating dozens of empty rules in the firewall for the sshd-dos chain.
All is documented here: Failed to execute ban jail 'ssh-ddos' action 'iptables-multiport' · Issue #3212 · fail2ban/fail2ban · GitHub
I fixed the issue by simply removing the sftp from the list of ports for jail sshd-dos and restarted F2B. All issues were gone.
Another issue was that F2B rules were being duplicated in IPTables whenever I clicked <Save Configuration>. IPtables & Fail2Ban - Apply Configuration results in duplicates - #3 by Rory_Bremner1
This was fixed in the 'Linux IPTables Firewall' configuration options I chose from the drop down list 'Configuration category:' > 'IPv4 configuration' and chose 'YES' for **Directly edit firewall IPv4 rules instead of save file?**.

1 Like

Thanks for posting. Good for others who may query the same. Would be good if you could merge the additional tasks you did to resolve back to the main post for cleanliness. :+1:

I did it the old fashioned way:

<sudo do-release-upgrade -d>

Done.

Unfortunately I cannot edit my initial post. There is no edit icon given to me for the initial post.

That command was not enough for me. I am on digitalocean which includes its own repositories instead of the official ones - that was the issue if memory serves and this is why I had to add

RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1

Another issue I found that did not exist before the upgrade was this:

systemd-udevd[378]: /etc/udev/rules.d/99-digitalocean-automount.rules:11 Invalid value "/bin/sh -c 'echo TMP_MOUNT_DIR=$(mktemp -d -p /mnt .do-first-mount-XXXXXXXXX)'" for IMPORT (char 32: invalid substitution type), ignoring, but please fix it.
systemd-udevd[378]: /etc/udev/rules.d/99-digitalocean-automount.rules:14 Invalid value "/bin/sh -c 'echo TMP_SCRIPT=$(mktemp -t .do-first-mount-XXXXXXXXX.sh)'" for IMPORT (char 29: invalid substitution type), ignoring, but please fix it.

Opened a ticket with them about it and they said that its just a warning, which of course it is. )))

Another one was this:

dovecot: config: Warning: please set ssl_dh=</etc/dovecot/dh.pem|
dovecot: config: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem|

execute this:
dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem

Add this to /etc/dovecot/conf.d/10-ssl.conf to fix warning in syslog
ssl_dh=</etc/dovecot/dh.pem

Another one with IPv6

named[705]: IPv6 socket API is incomplete; explicitly binding to each IPv6 address separately

May be related to this:

systemd-udevd[385]: Could not set WakeOnLan of ens3 to off: Operation not supported
udevadm[384]: systemd-udev-settle.service is deprecated.
systemd-udevd[388]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.

Seems like 20.04 is doing away with a delay mechanism, and drivers are not handling things properly yet? This may be of interest 20.04 - DNS server does not listen on IPv6 after a reboot - Ask Ubuntu
Currently I am not using IPv6 so I left this as is.

I am not experiencing anything weird with F2B, but this has shown up in syslog after the upgrade.
systemd[1]: /etc/systemd/system/fail2ban.service:15: PIDFile= references a path below legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → /run/fail2ban/fail2ban.pid; please update the unit file accordingly.
It is just a notice.
see here for options: https://github.com/fail2ban/fail2ban/issues/2474

Another one which appears only in 20.04 is this set of notices.

||systemd[1]: Condition check resulted in Show Plymouth Boot Screen being skipped.|
||systemd[1]: Condition check resulted in Forward Password Requests to Plymouth Directory Watch being skipped.|
||kernel: [    4.693593] systemd[1]: Condition check resulted in System Slice being skipped.|
||kernel: [    4.980208] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.|
||kernel: [    4.990001] systemd[1]: Condition check resulted in OpenVSwitch configuration for cleanup being skipped.|
||kernel: [    4.997748] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.|
||kernel: [    5.319608] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped.|
||kernel: [    5.319688] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped.|
||systemd[1]: Condition check resulted in LXD - agent - 9p mount being skipped.|
||systemd[1]: Condition check resulted in LXD - agent being skipped.|
||systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped.|
||systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped.|
||systemd[1]: Condition check resulted in Authentication service for virtual machines hosted on VMware being skipped.|
||systemd[1]: Condition check resulted in Service for virtual machines hosted on VMware being skipped.|
||systemd[1]: Condition check resulted in Process error reports when automatic reporting is enabled (file watch) being skipped.|
||systemd[1]: Condition check resulted in Timer to automatically fetch and run repair assertions being skipped.|
||systemd[1]: Condition check resulted in Unix socket for apport crash forwarding being skipped.|
||systemd[1]: Condition check resulted in Login to default iSCSI targets being skipped.|
||systemd[1]: Condition check resulted in getty on tty2-tty6 if dbus and logind are not available being skipped.|
||systemd[1]: Condition check resulted in Set the CPU Frequency Scaling governor being skipped.|
||systemd[1]: Condition check resulted in Pollinate to seed the pseudo random number generator being skipped.|
||systemd[1]: Condition check resulted in RPC Remote Quota Server being skipped.|
||systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.|
||systemd[1]: Condition check resulted in Secure Boot updates for DB and DBX being skipped.|
||systemd[1]: Condition check resulted in Automatically repair incorrect owner/permissions on core devices being skipped.|
||systemd[1]: Condition check resulted in Wait for the Ubuntu Core chooser trigger being skipped.|
||systemd[1]: Condition check resulted in Thermal Daemon Service being skipped.|
||systemd[1]: Condition check resulted in Ubuntu Advantage reboot cmds being skipped.|
||systemd[1]: Condition check resulted in Auto import assertions from block devices being skipped.|

Maybe they are also a result of an early execution at boot time?
Maybe they are skipped at the time of the warning, and later they are satisfied?
If you know more, chime in below.

I have posted this question on askubuntu: boot - Systemd[1]: Condition check resulted in <?> being skipped - Ask Ubuntu

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.