Mettre à niveau Ubuntu 24.04 vers 26.04 sur un VPS

Quand pouvez-vous mettre à niveau Ubuntu 24.04 vers 26.04 ?

Vous pourrez mettre à niveau Ubuntu 24.04 vers 26.04 sur un VPS dès la publication de la version corrective 26.04.1, prévue le 27 août 2026. D’ici là, un serveur 24.04 ne proposera pas la nouvelle release, intentionnellement. Ubuntu 26.04 LTS (Resolute Raccoon) est sorti le 23 avril 2026, mais Canonical n’ouvre la mise à niveau d’une LTS vers une autre qu’à la première version corrective, car celle-ci regroupe les corrections des problèmes d’installation et de mise à niveau détectés pendant les premiers mois.

Exécutez la vérification sur un serveur 24.04 au début du mois d’août 2026 pour obtenir ceci :

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Ce n’est pas un problème sur votre serveur. /etc/update-manager/release-upgrades contient Prompt=lts sur Ubuntu Server. Cela signifie que l’outil propose uniquement la prochaine release avec support à long terme, et seulement lorsque sa version corrective .1 existe. Définir Prompt=normal vous ferait passer successivement par 24.10, 25.04 et 25.10, des releases intermédiaires qui sont toutes arrivées en fin de vie. Laissez lts et attendez. Le calendrier de Canonical peut changer. Vérifiez donc de nouveau si la date passe sans que la mise à niveau soit proposée.

Chaque commande ci-dessous doit être exécutée par vos soins, sur votre propre serveur, dans l’ordre indiqué. Une mise à niveau de release ne peut pas être répétée à blanc sur la machine que vous mettez à niveau. Elle remplace le kernel et la bibliothèque C, puis nécessite un reboot pour se terminer.

Faut-il vraiment effectuer la mise à niveau ?

Ubuntu 24.04 reçoit des mises à jour de sécurité standard jusqu’en 2029. Un serveur de production fonctionnel n’est donc soumis à aucune urgence. Effectuez la mise à niveau pour bénéficier d’un élément inclus dans 26.04 : PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 ou le kernel 7.0. « Le numéro a augmenté » ne justifie pas de modifier une machine qui sert vos clients.

N’effectuez pas de mise à niveau sur place dans les cas suivants :

• Vous n’avez jamais ouvert la console de votre fournisseur (VNC ou série) ni essayé de vous y connecter. Cette console est le seul moyen de reprendre l’accès au serveur si SSH ne fonctionne plus. Découvrir qu’elle ne fonctionne pas alors que vous êtes bloqué dehors arrive trop tard.
• Vous ne pouvez pas vous permettre une heure d’interruption et vous n’avez aucun plan de rollback.
• Votre stack dépend d’un dépôt tiers qui n’a pas encore publié de version pour resolute.
• Le serveur a été configuré manuellement il y a plus de deux ans et personne ne sait précisément ce qui s’y trouve.

L’autre solution est souvent préférable : créez un VPS 26.04 neuf, installez votre stack et restaurez les données, puis basculez le DNS lorsque le nouveau serveur répond correctement. Vous pouvez laisser l’ancien serveur fonctionner jusqu’à ce que le nouveau ait fait ses preuves. Le rollback consiste alors à modifier le DNS, plutôt qu’à restaurer une sauvegarde. Si vous choisissez cette méthode, commencez par les dix premières minutes sur un nouveau VPS et configurez correctement le nouveau serveur.

Étape 1 : créez une sauvegarde à partir de laquelle vous pouvez restaurer

Utilisez deux niveaux, car ils échouent de manière différente. Un snapshot du provider couvre l’intégralité du disque et permet une restauration en quelques minutes, mais il est créé pendant que vos bases de données écrivent. Il est donc cohérent après incident, et non cohérent au niveau applicatif. Une sauvegarde au niveau des fichiers avec restic, stocké hors du serveur vous donne accès à des fichiers individuels et à une copie qui reste disponible même si votre compte est verrouillé.

Effectuez d’abord les dumps des bases de données manuellement. Un dump est la seule sauvegarde d’une base de données à laquelle vous pouvez faire confiance sans arrêter celle-ci.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction fournit un dump cohérent uniquement pour les tables InnoDB. Les tables MyISAM nécessitent l’arrêt de la base de données. L’archive tar /etc est celle que vous utiliserez réellement, car elle contient tous les fichiers de configuration sur lesquels la mise à niveau va vous demander des réponses.

Une sauvegarde que vous n’avez jamais restaurée reste une supposition. Restaurez maintenant un fichier à partir de cette sauvegarde, avant d’en avoir besoin sous pression.

Étape 2 : appliquer d’abord tous les correctifs de 24.04

do-release-upgrade refuse de s’exécuter si l’état des paquets du système est incohérent. Une version 24.04 partiellement mise à jour rend chaque erreur suivante plus difficile à analyser.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Si dpkg --audit n’affiche rien, aucun paquet n’est dans un état de configuration incomplète. Si apt-mark showhold n’affiche rien, aucun paquet n’est verrouillé sur une version qui empêcherait la mise à niveau. Libérez chaque paquet listé avec sudo apt-mark unhold et le nom du paquet, ou considérez que le verrouillage est volontaire et arrêtez-vous ici.

Redémarrez si le kernel a changé. Vous effectuerez ainsi la mise à niveau sur une machine qui exécute réellement le code qu’elle croit exécuter.

[ -f /var/run/reboot-required ] && sudo reboot

Vérifiez ensuite l’espace disque disponible. Le programme de mise à niveau télécharge l’ensemble des nouveaux paquets avant d’en installer un seul. S’il manque de la place, il s’arrête en indiquant le système de fichiers concerné.

df -h / /boot

C’est généralement sous environ 5 GB libres sur / que le problème survient. Un /boot de moins de 300 MB échoue plus tard, pendant l’installation du kernel, avec No space left on device. Les anciens kernels sont généralement en cause, et sudo apt --purge autoremove permet de les supprimer.

Arrêtez également un autre service avant de commencer : si les mises à jour de sécurité automatiques se déclenchent pendant l’opération, elles verrouillent dpkg et le programme de mise à niveau s’arrête avec Could not get lock /var/lib/dpkg/lock-frontend. Exécutez d’abord sudo systemctl stop unattended-upgrades, puis relancez l’opération une fois terminé.

Étape 3 : vérifier les dépôts tiers et les paquets épinglés

do-release-upgrade désactive toutes les sources apt qui ne proviennent pas d’Ubuntu, car un paquet compilé pour noble peut rendre un système resolute instable. L’outil réactive ensuite celles qu’il reconnaît et laisse les autres commentées. Identifiez ce que vous utilisez avant de laisser l’outil décider à votre place.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 utilise deux formats dans ce répertoire : les anciens fichiers .list sur une seule ligne et les fichiers .sources au format deb822, avec les champs Types: et Suites:. La mise à niveau désactive les deux formats. ubuntu-security-status --thirdparty répertorie les paquets installés qu’aucune archive Ubuntu ne fournit. Il indique donc précisément ce que vous avez ajouté au système. Tout ce qui se trouve dans /etc/apt/preferences.d/ correspond à un pinning. Un pinning écrit pour noble continuera de sélectionner un ancien paquet dans la nouvelle version.

Pour chaque dépôt tiers, vérifiez que l’éditeur a publié une version pour le nouveau codename avant de commencer. Les suites de Docker sont répertoriées à l’emplacement https://download.docker.com/linux/ubuntu/dists/, et les autres éditeurs exposent un répertoire similaire. Une source qui pointe vers une suite inexistante produit ce message lors du premier apt update après la mise à niveau :

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Laissez cette source désactivée jusqu’à la publication de la version par l’éditeur. Modifier le codename pour utiliser une version effectivement publiée par l’éditeur peut installer des paquets liés aux mauvaises bibliothèques système.

Étape 4 : exécutez la mise à niveau dans tmux, pas dans un shell SSH classique

Si votre connexion est interrompue pendant que do-release-upgrade s’exécute dans un shell de connexion classique, le processus reçoit SIGHUP et s’arrête pendant le décompactage. dpkg reste alors partiellement configuré, et le serveur peut ne plus disposer d’une pile réseau fonctionnelle pour accepter une nouvelle connexion. Exécutez plutôt la commande dans un multiplexeur de terminal. Le processus restera ainsi actif sur le serveur si votre client se déconnecte.

sudo apt install -y tmux
tmux new -s upgrade

Dans cette session :

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Le programme de mise à niveau démarre un second daemon SSH sur le port 1022 avant de modifier quoi que ce soit. Il vous en informe :

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Il n’ouvre pas ce port dans votre firewall, car ouvrir une règle sans vous le demander serait inattendu. Ouvrez vous-même le port 1022 avant de commencer, puis refermez-le lorsque vous avez terminé avec sudo ufw delete allow 1022/tcp. Votre fournisseur peut également utiliser un second firewall dans son panneau de contrôle, en dehors du serveur.

Si la connexion est malgré tout interrompue, reconnectez-vous et exécutez tmux attach -t upgrade. La mise à niveau a continué pendant votre absence.

Étape 5 : répondez délibérément aux invites des fichiers de configuration

dpkg ne vous invite à choisir que pour les fichiers que vous ou un script avez modifiés. Chaque invite concerne donc un fichier que vous avez modifié volontairement. Appuyer sur Entrée pour la faire disparaître peut ainsi transformer discrètement un serveur renforcé en serveur configuré par défaut.

Configuration file '/etc/ssh/sshd_config'
 ==> 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.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Appuyez d’abord sur D, à chaque fois. Lisez les changements, puis conservez votre version avec N. La réponse par défaut est déjà N. C’est la réponse sûre, car votre fichier fonctionne actuellement et la version fournie par le paquet n’a jamais été exécutée sur cette machine.

Conserver votre fichier a un coût : vous ne récupérez pas les nouveaux paramètres par défaut. Faites la comparaison ensuite, une fois le serveur opérationnel et sans contrainte de temps.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Chaque fichier que liste /etc/ssh/sshd_config est la version du mainteneur, enregistrée à côté de la vôtre. Comparez-les un par un et recopiez les paramètres importants. Deux fichiers nécessitent une attention particulière : /etc/ssh/sshd_config, car une mauvaise réponse met fin à votre session, et la configuration de votre serveur web, car une mauvaise réponse rend les sites indisponibles.

La mise à niveau vous demande également quels services redémarrer, via needrestart. Acceptez la liste complète. Un daemon qui continue d’utiliser un fichier de bibliothèque partagée supprimé du disque peut s’arrêter lors d’une requête ultérieure, alors que vous ne surveillez pas le serveur.

Étape 6 : redémarrez, puis vérifiez la machine

sudo reboot

Une fois la machine redémarrée :

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a doit indiquer Release: 26.04 et Codename: resolute. uname -r doit afficher un kernel 7.0. systemctl --failed doit lister zéro unité. Toute unité listée constitue votre prochaine tâche. Le dernier apt update récupère les mises à jour publiées depuis la création des images de release.

PostgreSQL 16 vers 18 : le cluster qui reste discrètement en arrière

Ubuntu 24.04 fournit PostgreSQL 16 et 26.04 fournit PostgreSQL 18. La mise à niveau installe 18 à côté de 16 et ne déplace pas vos données. La couche Debian postgresql-common crée un nouveau cluster vide pour la nouvelle version majeure sur le prochain port disponible. La version 16 conserve le port 5432 avec toutes vos données, tandis que la version 18 reste vide sur le port 5433. Votre application continue de communiquer avec le port 5432 et rien ne semble anormal. C’est pourquoi ce problème est souvent découvert plusieurs mois plus tard.

pg_lsclusters

La présence de deux clusters indique que la migration n’a pas été effectuée. Faites-la lorsque vous pouvez arrêter l’application :

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Supprimez d’abord le cluster 18 vide, car pg_upgradecluster n’écrit pas dans un cluster cible qui existe déjà. La méthode par défaut exporte le cluster 16, puis le recharge dans le cluster 18. Vous avez donc besoin d’un espace disque libre correspondant environ à la taille de la base de données. -m upgrade utilise plutôt pg_upgrade et est beaucoup plus rapide avec une base de données volumineuse. À la fin, consultez la colonne Port : le nouveau cluster récupère le port 5432 et l’ancien reste arrêté. Exécutez vous-même l’opération analyze, car un cluster nouvellement chargé ne contient encore aucune statistique et les premières requêtes seront lentes.

Testez l’application avec le nouveau cluster pendant quelques jours. Supprimez seulement ensuite l’ancien cluster :

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Le répertoire de données de l’ancien cluster est votre solution de rollback la plus rapide. Ne le supprimez pas le jour de la mise à niveau.

MySQL 8.0 vers 8.4 : l’option supprimée qui empêche le serveur de démarrer

26.04 fait passer MySQL de 8.0 à 8.4 LTS, et deux changements peuvent bloquer les serveurs.

Premièrement, mysqld refuse de démarrer lorsque sa configuration contient une option supprimée dans la nouvelle version. default_authentication_plugin est la plus courante, car de nombreux anciens guides recommandent de la définir. Le service échoue, et journalctl -u mysql -n 50 indique directement la variable inconnue. Supprimez cette ligne du fichier situé sous /etc/mysql/mysql.conf.d/, puis sudo systemctl start mysql.

Deuxièmement, le plugin mysql_native_password n’est plus activé par défaut dans 8.4. Un compte qui l’utilise encore ne peut donc plus se connecter. Vérifiez les comptes pendant que vous utilisez encore 8.0 :

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Faites migrer tous les comptes qui affichent mysql_native_password avant la mise à niveau, puis mettez à jour le mot de passe dans la configuration de votre application :

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Si une bibliothèque cliente est trop ancienne pour utiliser caching_sha2_password, vous pouvez réactiver l’ancien plugin dans 8.4 en ajoutant mysql_native_password=ON sous [mysqld]. Considérez cette solution comme temporaire et prévoyez de la supprimer, car ce plugin sera entièrement abandonné.

PHP 8.3 vers 8.5 : vos virtual hosts pointent vers un socket qui n’existe plus

24.04 fournit PHP 8.3 et 26.04 fournit PHP 8.5. Les paquets s’installent dans des chemins versionnés et rien ne modifie automatiquement la configuration de votre serveur web. Un virtual host nginx contenant fastcgi_pass unix:/run/php/php8.3-fpm.sock; pointe maintenant vers un socket qu’aucun processus ne crée. Chaque requête PHP renvoie donc une erreur 502 et le journal d’erreurs nginx contient :

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Pointez-le vers le nouveau socket, testez la configuration, puis rechargez nginx :

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Avec Apache et mod_php, le symptôme est différent : Apache ne démarre plus du tout et sudo apache2ctl -t indique qu’il ne peut pas charger libphp8.3.so, car le fichier n’existe pas. Le module activé est un lien symbolique vers un paquet qui a été supprimé.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Si vous avez installé le serveur en suivant une pile LAMP sur Ubuntu 24.04, vérifiez ces deux chemins. Le guide vous laisse avec un nom de module versionné et un socket versionné.

Votre configuration d’optimisation php.ini n’est pas conservée non plus. memory_limit, upload_max_filesize et tous les autres paramètres que vous avez définis se trouvent dans /etc/php/8.3/, tandis que la nouvelle arborescence repart des valeurs par défaut. Comparez les deux fichiers et recopiez les valeurs manuellement. Ne remplacez pas le nouveau fichier complet par l’ancien : cela réintroduirait les valeurs par défaut de 8.3 dans une installation 8.5. Exécutez ensuite php -m et comparez les résultats : une extension installée sous le nom php8.3-redis nécessite son paquet php8.5-. Si elle provenait d’un PPA, le programme de mise à niveau a désactivé cette source et l’extension est tout simplement absente.

Les certificats nécessitent une vérification spécifique. Exécutez sudo certbot renew --dry-run après la mise à niveau. Cette commande teste tout le processus de renouvellement, y compris le hook de rechargement du serveur web, sans modifier le certificat actuellement utilisé. Un hook qui appelle un nom de service ou un binaire modifié échoue ici, sous vos yeux, au lieu d’échouer silencieusement dans 60 jours. Certbot avec Let’s Encrypt sur nginx explique à quoi ces hooks doivent ressembler.

SSH : l’erreur qui met fin à la session en cours

L’invite sshd_config est l’endroit où l’on se retrouve le plus souvent sans accès. Répondre Y installe le fichier du mainteneur et supprime vos PermitRootLogin, PasswordAuthentication, AllowUsers, Port ainsi que toutes les autres lignes que vous avez ajoutées. Si votre pare-feu n’autorise qu’un port personnalisé et que la configuration fournie par le paquet écoute sur 22, la connexion suivante est refusée. La session dans laquelle vous vous trouvez est alors la dernière dont vous disposez.

Évitez ce problème avant la mise à niveau. /etc/ssh/sshd_config sur 24.04 commence par Include /etc/ssh/sshd_config.d/*.conf, et OpenSSH conserve la première valeur lue pour chaque paramètre. Un fichier drop-in inclus au début prend donc le dessus sur tout ce qui suit. Déplacez vos paramètres dans un fichier qui n’appartient pas à dpkg :

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Une fois qu’il ne reste plus aucun de vos paramètres dans /etc/ssh/sshd_config, cette invite n’a plus d’importance : quelle que soit votre réponse, vos paramètres sont conservés, car ils se trouvent dans un autre fichier.

Un port personnalisé nécessite une vérification supplémentaire, car il peut ne pas se trouver à l’endroit attendu :

systemctl is-enabled ssh.socket

Si cette commande affiche enabled, systemd gère le port en écoute et la ligne Port dans sshd_config est ignorée. Ubuntu utilise l’activation par socket pour sshd depuis 22.10. C’est pourquoi une modification de Port 2222 semble ne rien changer. Définissez plutôt le port sur l’unité socket avec sudo systemctl edit ssh.socket :

[Socket]
ListenStream=
ListenStream=2222

La valeur vide ListenStream= est obligatoire. Elle efface la valeur héritée. Sans elle, le socket écoute sur 22 ainsi que sur 2222. Appliquez la modification avec sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Après la mise à niveau, avant de fermer la session en cours :

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Ouvrez ensuite un second terminal sur votre propre machine et connectez-vous à nouveau. L’obtention d’un shell fonctionnel dans ce second terminal est la seule preuve valable. Gardez la première session ouverte jusque-là. Sécuriser SSH sur un VPS présente les paramètres qu’il est utile de conserver dans ce fichier drop-in.

S’il est déjà trop tard, la console web de votre fournisseur vous permet de vous connecter sans utiliser SSH. Connectez-vous, corrigez la configuration, exécutez sudo sshd -t, puis redémarrez le service. Cette console explique précisément pourquoi vous devez tester son accès avant une mise à niveau, et non pendant celle-ci.

FAQ

Pourquoi do-release-upgrade affiche-t-il « No new release found » sur Ubuntu 24.04 ?

Parce que /etc/update-manager/release-upgrades contient Prompt=lts sur Ubuntu Server, et que ce réglage ne propose la prochaine version LTS qu’après la publication de sa première mise à jour intermédiaire. Ubuntu 26.04 LTS est sortie le 23 avril 2026, et la publication de 26.04.1 est prévue pour le 27 août 2026. Jusqu’à cette date, un serveur 24.04 ne voit aucune nouvelle version. Laissez ce réglage tel quel au lieu de passer à Prompt=normal, qui vous ferait passer par les versions intermédiaires.

Dois-je redémarrer le serveur pour terminer la mise à niveau ?

Oui. La mise à niveau installe un nouveau kernel, une nouvelle bibliothèque C et un nouveau système init. Le système en cours d’exécution continue d’utiliser les anciennes versions jusqu’au redémarrage. do-release-upgrade demande un redémarrage à la fin. Une machine laissée en fonctionnement « pour plus tard » utilise alors un mélange de deux versions. Après son redémarrage, vérifiez uname -r pour confirmer le nouveau kernel et systemctl --failed pour repérer les services qui n’ont pas redémarré.

Dois-je mettre à niveau le serveur existant ou créer un serveur 26.04 neuf ?

Créez un serveur neuf lorsque c’est possible. Un nouveau VPS vous permet d’installer la stack, de restaurer les données et de tout tester pendant que l’ancien serveur continue de servir le trafic. En cas de problème, le rollback se limite alors à une modification DNS, au lieu de restaurer une sauvegarde. Effectuez la mise à niveau sur place lorsque le serveur contient un état difficile à déplacer, lorsque le fournisseur facture chaque machine ou lorsque vous disposez d’un snapshot et d’un accès console vérifié. La mise à niveau sur place est bien documentée, mais elle est irréversible pendant toute sa durée.

Que se passe-t-il si ma connexion SSH est interrompue pendant la mise à niveau ?

Dans un shell de connexion standard, le processus reçoit SIGHUP et s’arrête en cours d’exécution, ce qui laisse dpkg partiellement configuré. Lancez-le dans tmux ou screen : le processus survivra, et vous pourrez vous reconnecter puis exécuter tmux attach -t upgrade pour reprendre la mise à niveau. Le programme de mise à niveau démarre également un daemon SSH de secours sur le port 1022. Il n’ouvre toutefois pas le firewall pour ce port. Autorisez donc d’abord le port 1022, puis refermez-le ensuite.

Mon site PHP renvoie une erreur 502 après la mise à niveau. Que s’est-il passé ?

Le chemin du socket PHP FPM a changé avec la version. Ubuntu 24.04 utilise PHP 8.3 et 26.04 utilise PHP 8.5. /run/php/php8.3-fpm.sock n’existe donc plus alors que votre vhost nginx le référence encore. Le journal d’erreurs nginx affiche connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Modifiez fastcgi_pass pour utiliser le socket 8.5, exécutez sudo nginx -t, puis rechargez nginx. Avec Apache et mod_php, la correction équivalente consiste à exécuter sudo a2dismod php8.3, puis sudo a2enmod php8.5, et à redémarrer Apache.