I recently upgraded my server from 22.04 to 24.04 and almost all went well. All default requests were accepted on request. The one issue I had was on apache2. It started and several of my services worked (e.g. unifi) but bareos and munin did not. On research, I found that the mods-enabled of php8.1.conf and php8.1.load had not been changed to php8.3.conf and php8.3.load. After I made this change, all worked well.
So my question is was this something I missed in the questions asked in the upgrade or is it intentional to make the user figure this out separately?
I just did a clean server install of 22.04, and added apache2 and php - which gave me php8.1.
I then did all the software updates, and ran do-release-upgrade which successfully upgraded to 24.04.
However, it broke the upgrade. In contrast to yours, mine actually removed php8.1 and installed php8.3.
# dpkg -l php* | grep ^ii
ii php 2:8.3+93ubuntu2 all server-side, HTML-embedded scripting language (default)
ii php-common 2:93ubuntu2 all Common files for PHP packages
ii php8.3 8.3.6-0ubuntu0.24.04.3 all server-side, HTML-embedded scripting language (metapackage)
ii php8.3-cli 8.3.6-0ubuntu0.24.04.3 amd64 command-line interpreter for the PHP scripting language
ii php8.3-common 8.3.6-0ubuntu0.24.04.3 amd64 documentation, examples and common module for PHP
ii php8.3-opcache 8.3.6-0ubuntu0.24.04.3 amd64 Zend OpCache module for PHP
ii php8.3-readline 8.3.6-0ubuntu0.24.04.3 amd64 readline module for PHP
It left me with a broken apache configuration.
# systemctl status apache2 | cat
× apache2.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Tue 2024-12-24 13:02:08 UTC; 4min 42s ago
Docs: https://httpd.apache.org/docs/2.4/
Process: 327 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
CPU: 41ms
Dec 24 13:02:08 genuine-bullfrog systemd[1]: Starting apache2.service - The Apache HTTP Server...
Dec 24 13:02:08 genuine-bullfrog apachectl[353]: apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php8.1.load: Cannot load /usr/lib/apache2/modules/libphp8.1.so into server: /usr/lib/apache2/modules/libphp8.1.so: cannot open shared object file: No such file or directory
Dec 24 13:02:08 genuine-bullfrog systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
Dec 24 13:02:08 genuine-bullfrog systemd[1]: apache2.service: Failed with result 'exit-code'.
Dec 24 13:02:08 genuine-bullfrog systemd[1]: Failed to start apache2.service - The Apache HTTP Server.
It didn’t migrate the config, and actually removed the running php8.1 which broke the apache server configuration.
popey, I guess I did not describe all of the details. It also removed my php-8.1 and installed 8.3
So as my original post indicated I needed to upgrade the apache2 configuration removing the php-8.1 and enter the php-8.3, which fixed my apache2 setup
I seem to have a similar problem, my apache2 has stopped working, I believe following an upgrade to 24.04.
systemctl status apache2.service includes this error message -
apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php8.1.load: Cannot load /usr/lib/apache2/modules/libphp8.1.so into server: /usr/lib/apache2/modules/libphp8.1.so: cannot open shared object file: No such file or directory
It is correct that /usr/lib/apache2/modules/libphp8.1.so has gone and been replaced with /usr/lib/apache2/modules/libphp8.3.so
What do I need to do to get it to work again?
Thanks
Mick
Yes, it was just the sudo a2enmod php8.3 that was needed. Should that have happened as part of the upgrade?
Thanks for your help, my system now works again!!
Mick
This is kind of hard to answer, typically packages should not blindly transition user created configs to a new release (you might not have used a2enmod, but created a config manually with personal quirks and adjustments originally, a package update just overwriting your changes would be a no-go here)
OTOH php8.1 is dead and gone on your system, so remaining configs can indeed cause havoc … but you might also want to transition your potential local config modifications to the new version