Mettre à niveau Ubuntu 24.04 vers 26.04 sur un VPS

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

Vous pouvez mettre à niveau Ubuntu 24.04 vers 26.04 sur un VPS dès que la version corrective 26.04.1 sera publiée, ce qui est prévu pour le 27 août 2026. D’ici là, un serveur 24.04 ne verra volontairement pas la nouvelle version. Ubuntu 26.04 LTS (Resolute Raccoon) est sortie le 23 avril 2026, mais Canonical n’ouvre le chemin de mise à niveau d’une version LTS vers une autre qu’à partir de la première version corrective. Cette version regroupe les bugs d’installation et de mise à niveau détectés pendant les premiers mois. Si cette numérotation vous est inhabituelle, 26.04.1 n’est pas une Ubuntu différente, mais la même 26.04 avec quatre mois de correctifs intégrés au support d’installation, ce qui explique pourquoi il s’agit de la première version que Canonical proposera à un serveur existant.

Exécutez la vérification sur un serveur 24.04 au début du mois d’août 2026 et vous obtenez 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. L’outil ne propose donc que la prochaine version LTS, et uniquement lorsque sa version corrective .1 existe. Définir Prompt=normal vous ferait passer successivement par 24.10, 25.04 et 25.10, des versions intermédiaires qui sont toutes arrivées en fin de vie. Laissez lts et attendez. Le calendrier de Canonical peut changer. Vérifiez donc à 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 version 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. Elle nécessite un redémarrage 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 parce que vous avez besoin de ce que 26.04 fournit : PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 ou le noyau 7.0. « Le numéro a augmenté » ne justifie pas de toucher à 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 ouvert une session via celle-ci. 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 ne disposez d’aucun plan de retour arrière.
• Votre pile logicielle 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 qu’il contient.

L’alternative est souvent préférable : créez un VPS 26.04 neuf, installez votre pile logicielle et restaurez les données, puis basculez le DNS dès que le nouveau serveur répond correctement. Vous laissez l’ancien serveur fonctionner jusqu’à ce que le nouveau ait fait ses preuves. Le retour arrière consiste alors à modifier le DNS, et non à 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 que vous pourrez restaurer

Utilisez deux niveaux, car ils échouent de différentes manières. Un snapshot du fournisseur couvre l’intégralité du disque et se restaure 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ée hors du serveur vous permet de récupérer des fichiers individuels et conserve une copie 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 l’arrêter.

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 au sujet desquels la mise à niveau va vous poser des questions.

Une sauvegarde que vous n’avez jamais restaurée reste une hypothèse. Restaurez-en maintenant un fichier, avant d’en avoir besoin dans l’urgence.

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

do-release-upgrade refuse de s’exécuter sur un système dont l’état des paquets est incohérent. Une version 24.04 partiellement mise à niveau rend aussi toutes les erreurs suivantes plus difficiles à interpréter.

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 partiellement configuré. Si apt-mark showhold n’affiche rien, aucun paquet n’est verrouillé sur une version qui bloquerait 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 justifié et arrêtez-vous ici.

Redémarrez si le noyau a changé. Vous effectuerez ainsi la mise à niveau depuis une machine qui exécute effectivement le code qu’elle considère comme actif.

[ -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 n’y a pas assez d’espace, il s’arrête en indiquant le système de fichiers concerné.

df -h / /boot

Le problème survient généralement lorsque / dispose de moins d’environ 5 GB libres. Un /boot inférieur à 300 MB échoue plus tard, pendant l’installation du noyau, avec No space left on device. Les anciens noyaux sont généralement en cause, et sudo apt --purge autoremove permet de les supprimer.

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

Étape 3 : vérifiez 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 conçu 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 le laisser 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. C’est le décompte réel de ce que vous avez ajouté au système. Tout ce qui se trouve dans /etc/apt/preferences.d/ est un pin. Un pin écrit pour noble continuera à 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’adresse https://download.docker.com/linux/ubuntu/dists/. 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 revient à 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 au milieu de la décompression. dpkg reste alors partiellement configuré, et le serveur peut ne plus disposer d’une pile réseau fonctionnelle pour vous reconnecter. Exécutez plutôt la commande dans un multiplexeur de terminal. Le processus reste ainsi actif sur le serveur lorsque 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, et l’indique :

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 pare-feu, car ouvrir une brèche sans vous le demander serait un comportement 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. N’oubliez pas que votre fournisseur peut gérer un second pare-feu dans son panneau de contrôle, en dehors du serveur.

Si la connexion est tout de même interrompue, reconnectez-vous et exécutez tmux attach -t upgrade. La mise à niveau a continué pendant votre absence. Si ce n’est pas le cas et que vous retrouvez un dpkg partiellement configuré ou des sources apt qui sont en partie noble et en partie resolute, la section récupération après l’échec d’une mise à niveau de version explique comment réparer l’état des paquets et déterminer quand arrêter les réparations pour restaurer plutôt l’instantané.

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

dpkg vous demande uniquement quoi faire 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 est le moyen pour qu’un serveur renforcé redevienne discrètement un serveur utilisant les valeurs 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 différences, puis conservez votre version avec N. La réponse par défaut est déjà N. C’est la réponse la plus sûre, car votre fichier fonctionne aujourd’hui 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 bénéficiez pas des nouvelles valeurs 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'

Pour chaque fichier qui est listé, il s’agit de la version du responsable de la maintenance, enregistrée à côté de la vôtre. Comparez-les un par un et reportez 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 finira par planter lors d’une requête ultérieure, à un moment où vous ne surveillerez pas le serveur.

Étape 6 : redémarrez, puis contrôlez 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 noyau 7.0. systemctl --failed doit afficher zéro unité. Toute unité affichée est votre prochaine tâche. Le dernier apt update récupère les mises à jour publiées depuis la création des images de la 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, mais ne déplace pas vos données. La couche postgresql-common de Debian crée un nouveau cluster vide pour la nouvelle version majeure sur le prochain port disponible. Ainsi, 16 conserve le port 5432 avec toutes vos données et 18 reste vide sur 5433. Votre application continue de communiquer avec 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 16, puis recharge les données dans 18. Vous avez donc besoin d’un espace disque libre correspondant à peu près à 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 reprend le port 5432 et l’ancien reste arrêté. Exécutez vous-même la passe analyze, car un cluster fraîchement chargé ne possède 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 le moyen le plus rapide de revenir en arrière. Ne le supprimez pas le jour de la mise à niveau.

MySQL 8.0 à 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 si 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 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 la situation tant que vous êtes encore sous 8.0 :

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

Avant la mise à niveau, faites migrer tous les comptes affichant mysql_native_password, 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 sa suppression, car ce plugin sera entièrement retiré.

PHP 8.3 à 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 réécrit 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 502 et le journal d’erreurs nginx indique :

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 n’est plus installé.

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 de réglage 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 utilise les valeurs par défaut. Comparez les deux fichiers et recopiez les valeurs manuellement. Remplacer entièrement le nouveau fichier par l’ancien réintroduit 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 n’est tout simplement plus installée.

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 actif. Si un hook appelle un nom de service ou un binaire qui a changé, l’échec se produit ici, sous vos yeux, plutôt que silencieusement dans 60 jours. Certbot avec Let’s Encrypt sur nginx explique à quoi ces hooks doivent ressembler.

SSH : l’échec qui met fin à la session dans laquelle vous travaillez

Le prompt sshd_config est l’endroit où l’on se retrouve bloqué dehors. 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 autorise uniquement un port personnalisé et que la configuration fournie é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. Sur 24.04, /etc/ssh/sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf, et OpenSSH conserve la première valeur lue pour chaque paramètre. Un drop-in inclus au début prend donc le dessus sur tout ce qui suit. Déplacez vos paramètres dans un fichier dont dpkg n’est pas propriétaire :

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’aucun élément de /etc/ssh/sshd_config ne vous appartient, ce prompt n’a plus d’importance : les deux réponses conservent vos paramètres, puisqu’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à où vous le pensez :

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

Le ListenStream= vide est obligatoire. Il efface la valeur héritée. Sans lui, le socket écoute sur 22 et 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 dans laquelle vous vous trouvez :

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

Ouvrez ensuite un deuxième terminal sur votre propre machine et reconnectez-vous. Un shell fonctionnel dans ce deuxième terminal est la seule preuve qui compte. Gardez la première session ouverte jusque-là. Renforcer la sécurité de SSH sur un VPS détaille les paramètres qu’il est utile de conserver dans ce 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 à cette console, corrigez la configuration, exécutez sudo sshd -t, puis redémarrez le service. Cette console explique précisément pourquoi il faut tester l’accès à la console avant une mise à niveau, et non pendant celle-ci.

FAQ

Pourquoi do-release-upgrade indique-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 version 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 le remplacer par 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 noyau, une nouvelle bibliothèque C et un nouveau système d’initialisation. 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 noyau et systemctl --failed pour repérer les services qui n’ont pas redémarré.

Dois-je mettre le serveur à niveau sur place 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 pile logicielle, 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 consiste alors à modifier le DNS plutôt qu’à restaurer une sauvegarde. Effectuez la mise à niveau sur place lorsque le serveur contient un état difficile à transférer, lorsque le fournisseur facture chaque machine ou lorsque vous disposez d’un snapshot et d’un accès console testé. La mise à niveau sur place est une procédure bien établie, mais elle est irréversible pendant l’heure où elle s’exécute.

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 à moitié configuré. Lancez-le dans tmux ou screen. Le processus survivra, vous pourrez vous reconnecter et exécuter tmux attach -t upgrade pour reprendre la procédure. Le programme de mise à niveau démarre également un daemon SSH de secours sur le port 1022, comme seconde méthode d’accès. Il n’ouvre toutefois pas le pare-feu pour ce port. Autorisez donc vous-même le port 1022 avant la mise à niveau, 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, tandis que votre virtual host 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, le correctif équivalent consiste à exécuter sudo a2dismod php8.3, puis sudo a2enmod php8.5, et à redémarrer Apache.