Issue Upgrading from Ubuntu 20.04 to 22.04: failed reboot

[Oscar Segura]

Server operating system version

Ubuntu 20.04 LTS

Plesk version and microupdate number

18.0.57 #5

Followed the steps of the this Plesk Guideline and landed to a failed reboot on step 18: Dist-upgrade from Ubuntu 20 (Focal Fossa) to Ubuntu 22 (Jammy Jellyfish)

• After forcing machine restart, it all seemed to work out. Although, the plesk panel changed language from English to French by its own.

The question is if this failed reboot was expected and if I should be concerned that something went amiss that could compromise the integrity of OS server.

Details on some steps

Before step 16 I checked what mysql version is

# mysql -V
mysql  Ver 15.1 Distrib 10.3.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

• Notice that mistaking the command in this step will lead to an error later, on step 21 (where plesk installed is updated: Failed to start mysql.service: Unit mysql.service not found.Unit mysql.service could not be found). So it woudl be worth mentioning this.

So I finally opted for this command (mariadb-server-10.6) on step 16:

# aptitude install base-files linux-generic libc6 python3 mariadb-server-10.6

• the above matches the expected removal of packages as per the main guideline.

At some stage got prompted with the below and answered 'yes':

Configuration file '/etc/mysql/mariadb.cnf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** mariadb.cnf (Y/I/N/O/D/Z) [default=N] ? Y

After DB install, I checked the status of the service and it was updated, up and running:

systemctl status mysql

​

At step 16 (install modern kernel, libc6, python3 packages): you are prompted to confirm an override of PAM etc files. Specifically when the libpam-systemd package is updated, I was prompted to confirm an override of PAM files in /etc. I answered 'yes'.

• This is a brand-new installation. I am upgrading to Ubuntu 22.04 LTS because the provider was offering only 20.04 LTS to be installed to the virtual server.

After step 18 (reboot), the server did not start-up. Could access the machine and got the below:



So I forced the start-up of the virtual server (as if powering off and on). From there on everything seemed to work perfectly.
After the latest reboot of the steps

root@id27111:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

---

Research

I have researched a bit on the reboot error

/shutdown: error while loading shared libraries: libsystemd-shared-245.so

Case 1
A comment on this post suggests to give information on the below:

root@id27111:~# find / -name libsystemd-shared-245.so
/snap/core20/2015/usr/lib/systemd/libsystemd-shared-245.so
/snap/core20/2105/usr/lib/systemd/libsystemd-shared-245.so
root@id27111:~# ldd /lib/systemd/libsystemd-shared-245.so
ldd: /lib/systemd/libsystemd-shared-245.so: No such file or directory

This reflects that version 245 is very old (2015)

Case 2
Found also this short article about this error: The Mysterious Case of /shutdown (Feb 2023).
The author tries to dig in to find the source of the problem and lands to a commit message (2021-07-29) on this bugtracker for finalrd, titled Improve library detection in finalrd.sh.

rebooting failed [..] turned out to be becausethe dynamic linker path with my snapshot did not match the regexp infinalrd.sh [..] let's justuse a more reliable way to get the dependencies of a binary

In the article, the author mentions that the command below worked out to remove the problem (although had copied the missing libraries first):

touch /run/initramfs/shutdown

Case 3
This other thread asks for the info below to see if there are some old binaries

• The thread goes on and on trying to figure out how some binaries got different versions, although in this case the solution was just removing those bindaries from /usr

root@id27111:~#  ls -l /usr/bin/systemd-machine-id-setup \
        /bin/systemd-machine-id-setup \
        /usr/lib/systemd/libsystemd-shared* \
        /lib/systemd/libsystemd-shared*
-rwxr-xr-x 1 root root   18928 Sep 19 17:57 /bin/systemd-machine-id-setup
-rw-r--r-- 1 root root 2840280 Sep 19 17:57 /lib/systemd/libsystemd-shared-249.so
-rwxr-xr-x 1 root root   18928 Sep 19 17:57 /usr/bin/systemd-machine-id-setup
-rw-r--r-- 1 root root 2840280 Sep 19 17:57 /usr/lib/systemd/libsystemd-shared-249.so

There seems to be a double-up, although versions match one another; yet 249 is not the version of the expected library: libsystemd-shared-245.so

It somehow tries to find an old version (245), while a newer one is installed (249)

My guess is that this has to do with the order of the steps? as apt-get dist-upgrade is only ran later on step 23

So to say, we can just ignore this, although if so, shouldn't this be specified in the steps?