Site Navigation
I had discovered some problems with upgrades that were run remotely using SSH. For desktops, there may have been communication issues with some component of the display manager. For servers it may have been due to losing the connection during update of a key component of SSH. The way that I addressed these issues was to make sure that I used a plain terminal to run the upgrade. For servers this meant connecting some form of virtual or physical console to the server. Usually I disabled crontab, because there would probably be background tasks that should be disabled until the upgrade had been successful. Then I would stop apache2, and postgres, create a pg_dump backup of all of the data using the "script" option. Note: This is the default, but It is important to make sure that you use the "script" option. So I usually check the file when the backup has completed and confirm that is indeed a script rather than the binary backup.
Then restart the server from the console and do the following:
- Bring up the Ubuntu grub menu while it is re-booting.
- Select "Advanced options for Ubuntu"
- Select the latest kernal (recovery mode)
- Bring up networking
- Drop to a root shell
- Run do-release-upgrade
In each case, the upgrade ran smoothly and after reboot, it seemed Ok ... Except that I found that apache2 would not start because of a missing PHP mod. 24.04 uses PHP 8.3 and the 8.1 mod was missing from "mods-available". The way that I remedied this was to manually remove the PHP 8.1 symbolic links from the "mods-enabled" folder in /etc/apache2, confirming that libapache2-mod-php was installed with APT, and then bringing it up using "a2enmod". An example is shown below:
cd /etc/apache2/mods-enabled rm php8.1.conf php8.1.load apt install php libapache2-mod-php a2enmod php_module systemctl start apache2 |
After this, apache2 should start OK.
Because the servers I dealt with had a lot of legacy code, I would
carefully examine any proposed configuration changes where I was given a
choice between the maintainer's version and the existing version. Usually I
would opt to keep the existing version (most often this was the default). I
also found that the upgrade would keep postgres 14, even though it was
deprecated, and I would be left with the problem of upgrading. However I found
upgrading postgres in TEST with the pg_upgrade utility quite complex and
time-consuming. I decided that the easiest way to upgrade to version 16 was to
completely remove postgres using APT with the "purge" option. Then, remove all
copies of the config and data files and reinstall postgres. If you import the
backup that you created above, this is easy. And it leaves you with a fresh
new v16 cluster. An example is shown below:
# As Application owner [if you have one --- Otherwise use postgres owner] BACKUP=~/bak/backup.sql pg_dump -d db_name >$BACKUP # Examine the file and verify OK # Stop postgres [As root] systemctl list-units --type=service | grep -i postgres # If you've recently upgraded, you might see something like this: # postgresql.service loaded active exited PostgreSQL RDBMS # postgresql@14-main.service loaded active running PostgreSQL Cluster 14-main # postgresql@16-main.service loaded active running PostgreSQL Cluster 16-main # # Shut them all down # # Keep copies of version 14 config files ... for later systemctl stop postgresql.service postgresql@14-main.service postgresql@16-main.service mkdir ~/confbak cp -ip /etc/postgresql/14/main/* ~/confbak/ # Get a list of installed postgres packages dpkg -l | grep postgres # Remove them all with the "purge" option apt-get purge postgresql postgresql-14 postgresql-16 \ postgresql-client-14 postgresql-client-16 \ postgresql-client-common postgresql-common # Review and remove any existing folders in /etc/postgresql and /var/lib/postgresql ... e.g.: rm -Rf /etc/postgresql/14 # Reinstall postgres packages apt-get install postgresql postgresql-client-common postgresql-common # Connect as postgres and check OK, create app owner roles, if required. su - postgres createdb db_name psql show data_directory; -- -- Note: Inside psql, you should see: -- data_directory -- ----------------------------- -- /var/lib/postgresql/16/main -- -- Next, create roles ... Substitute the name of your application owner, if you have one: create role app_owner with createdb createrole login; grant all on schema public to app_owner; alter database db_name owner to app_owner; \q BACKUP=/home/app_owner/bak/backup.sql psql -d db_name -f $BACKUP # # Fix the PGDATA and PGLIB environment variables in .bashrc for postgres and the application owner # # Then, as root, examine the differences you observed in the version 14 config files # Apply similar changes to your version 16 config files # Restore crontabs and reboot ... And you should be good to go. |
As ever, YMMV ... If you have a huge installation consisting of multiple DBs, with complex customised parm files, you may be better off upgrading the v14 cluster. On the other hand, if you have a small to medium size installation with only one DB, simple config files that only differ slightly from the maintainer's recommendations, then the above approach will be easier, because it will remove the version 14 packages, and create a clean, brand new de-fragmented version 16 cluster.
And, unless you are the sort of person who likes to go sky-diving without checking that your parachute has been packed correctly, or drive on rural back roads without fastening your seatbelt in a car with faulty air-bags, you might consider checking that all of your proposed changes work in TEST, before attempting to run them in PROD.