Mettre à niveau Ubuntu 24.04 vers 26.04 sur un VPS

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

Vous pouvez maintenant mettre Ubuntu 24.04 à niveau vers 26.04 sur un VPS. Depuis le 29 septembre 2026, date à laquelle Canonical a activé les mises à niveau depuis 24.04 LTS, do-release-upgrade sur un serveur 24.04 propose 26.04.1. Ubuntu 26.04 LTS (Resolute Raccoon) est sorti le 23 avril 2026, mais Canonical n’ouvre le chemin de mise à niveau d’une version LTS vers une autre qu’après la sortie de la première version intermédiaire. Celle-ci regroupe les bugs d’installation et de mise à niveau détectés pendant les premiers mois. Cette fois, l’attente a dépassé la sortie de cette version : 26.04.1 est sorti le 27 août 2026, puis Canonical a encore retardé la mise à niveau de quelques semaines pour intégrer des backports prévus, qui corrigent des régressions dans une version récente de rust-coreutils. Si cette numérotation vous est inhabituelle, 26.04.1 n’est pas une version Ubuntu différente, mais la même version 26.04 avec quatre mois de correctifs intégrés à l’image, ce qui explique précisément pourquoi Canonical la propose en premier aux serveurs existants.

Jusqu’au 29 septembre, l’exécution de la vérification sur un serveur 24.04 affichait ceci :

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Ce résultat n’indiquait pas un problème sur le serveur. Si vous l’observez encore aujourd’hui, vérifiez le paramètre dont il dépend. /etc/update-manager/release-upgrades contient Prompt=lts sur Ubuntu Server. Cela signifie que l’outil propose uniquement la prochaine version LTS, et seulement une fois que Canonical a ouvert le chemin de mise à niveau correspondant. Laissez malgré tout ce paramètre sur lts, car, dans une version ultérieure, normal proposerait également les versions intermédiaires à support court. Pendant l’attente, Canonical proposait do-release-upgrade -d aux utilisateurs qui ne souhaitaient pas attendre. Maintenant que le chemin est ouvert, la commande simple est celle que son annonce recommande pour les serveurs. Lisez ce qui a changé dans 26.04.1 et quand le chemin de mise à niveau a été ouvert avant de commencer. Un serveur encore sous 22.04 ne peut pas effectuer directement cette mise à niveau, car l’outil de mise à niveau ne propose que la prochaine version LTS. Mettre 22.04 à niveau vers 26.04 en passant par 24.04 décrit donc la première étape et le snapshot à créer avant la seconde.

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 testée à blanc sur la machine que vous mettez à niveau. Elle remplace le kernel et la C library, et 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 manière différente. Un snapshot fourni par l’hébergeur couvre l’intégralité du disque et se restaure en quelques minutes, mais il est pris pendant que vos bases de données écrivent. Il est donc cohérent après incident, et non cohérent du point de vue de l’application. Une sauvegarde au niveau des fichiers avec restic, stocké hors du serveur vous permet de récupérer des fichiers individuels et conserve une copie si votre compte est verrouillé.

Commencez par exporter les bases de données manuellement. Un dump est une méthode de sauvegarde d’une base de données en fonctionnement.

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 des verrous pour obtenir un dump cohérent. L’archive /etc est celle que vous utiliserez réellement, car elle contient chaque fichier de configuration sur lequel la mise à niveau va vous demander des informations.

Une sauvegarde que vous n’avez jamais restaurée reste une supposition. Récupérez-en maintenant un fichier, avant d’en avoir besoin dans l’urgence.

Étape 2 : corrigez complètement 24.04 avant toute chose

do-release-upgrade refuse de s’exécuter sur un système dont l’état des paquets est incohérent, et une version 24.04 partiellement corrigée rend chaque erreur suivante plus difficile à interpréter.

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

L’absence de sortie de dpkg --audit signifie qu’aucun paquet n’est partiellement configuré. L’absence de sortie de apt-mark showhold signifie qu’aucun paquet ne fait l’objet d’un dpkg hold. Cette commande n’affiche pas les règles de préférence APT, qui constituent un mécanisme distinct et peuvent également empêcher la mise à jour d’un paquet ; l’étape 3 les vérifie. Libérez tout ce que showhold affiche avec sudo apt-mark unhold et le nom du paquet, ou admettez que le hold existe pour une bonne raison et arrêtez-vous ici.

Redémarrez si le kernel a changé, afin d’effectuer la mise à niveau depuis une machine qui exécute bien le code qu’elle pense exécuter.

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

Vérifiez ensuite l’espace disque disponible. Le programme de mise à niveau télécharge tout le nouvel ensemble de paquets avant d’en installer un seul. Il s’arrête avec un message indiquant le filesystem concerné si l’espace disponible est insuffisant.

df -h / /boot

Les anciens kernels sont généralement en cause, et sudo apt --purge autoremove les supprime.

Autre point à arrêter 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 de la 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-le une fois l’opération terminée.

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

Par défaut, do-release-upgrade met en commentaire toutes les sources APT qui ne proviennent pas d’Ubuntu, car un paquet conçu pour noble peut rendre un système resolute instable. Son option --allow-third-party les laisse activées, avec exactement ce risque. Vérifiez ce que vous conservez 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:. Une mise à niveau standard désactive les deux. ubuntu-security-status --thirdparty répertorie les paquets installés qu’aucune archive Ubuntu ne fournit. C’est le nombre exact de paquets que vous avez ajoutés. Un fichier dans /etc/apt/preferences.d/ n’est lu comme un fichier de pinning que si son nom n’a pas d’extension ou se termine par .pref et contient uniquement des lettres, des chiffres, des traits d’union, des underscores et des points ; APT ignore tout autre fichier, généralement en affichant un message. Un pin qui référence noble peut maintenir un paquet dans une ancienne version après la mise à niveau, selon les versions encore disponibles et la priorité définie par le pinning. Lisez donc chaque fichier et décidez s’il est toujours nécessaire.

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 listées dans https://download.docker.com/linux/ubuntu/dists/, et les autres éditeurs exposent le même répertoire. 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.

Docker publie désormais une suite resolute. Laissez désactivée toute source dont la suite n’existe pas jusqu’à sa publication par l’éditeur. Modifier le codename pour utiliser une suite effectivement publiée par l’éditeur revient à installer des paquets liés aux mauvaises bibliothèques système.

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

Le programme de mise à niveau du serveur s’exécute normalement dans GNU screen et permet de se rattacher à la session après une coupure de connexion. La perte de la connexion SSH n’interrompt donc pas à elle seule la mise à niveau. Exécutez-la également dans votre propre session tmux afin de disposer d’une session nommée à laquelle vous pourrez vous reconnecter.

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 firewall, 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. Votre fournisseur peut également exécuter 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. 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, récupérer une mise à niveau de version ayant échoué explique comment réparer l’état des paquets et déterminer quand arrêter les réparations pour restaurer plutôt le snapshot.

Étape 5 : répondre avec attention aux demandes concernant les fichiers de configuration

dpkg vous demande uniquement quoi faire pour les fichiers que vous ou un script avez modifiés. Chaque demande concerne donc un fichier que vous ou un script avez modifié. Appuyer sur Entrée conserve la version actuelle 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. Examinez les modifications, puis décidez de conserver votre version avec N ou d’installer la version du mainteneur. La valeur par défaut est déjà N, mais conserver l’ancien fichier n’est pas sûr pour tous les paquets : certaines modifications de configuration sont nécessaires au fonctionnement du système mis à niveau.

Conserver votre fichier a un coût : vous ne bénéficiez pas des nouvelles valeurs par défaut. Faites la mise en cohérence ensuite, une fois le serveur opérationnel et sans pression temporelle.

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

Pour chaque fichier concerné, la version du mainteneur est enregistrée à côté de la vôtre. Comparez-les une par une et reportez les paramètres importants. Deux fichiers méritent 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 met les sites hors service.

Depuis Ubuntu 24.04, needrestart redémarre automatiquement les services concernés par défaut. Si vous avez rétabli son mode interactif, acceptez la liste complète. Un daemon qui utilise encore une ancienne bibliothèque partagée reste exposé aux bugs corrigés par la mise à jour tant qu’il n’a pas redémarré.

Étape 6 : redémarrer, puis vérifier la machine

sudo reboot

Au redémarrage :

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 afficher 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 devient votre prochaine tâche. Le dernier apt update actualise les index des paquets. apt full-upgrade installe ensuite les mises à jour publiées depuis que la mise à niveau a récupéré ses paquets.

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

Ubuntu 24.04 fournit PostgreSQL 16 et Ubuntu 26.04 fournit PostgreSQL 18. La mise à niveau installe PostgreSQL 18 à côté de PostgreSQL 16 et ne déplace pas vos données. La couche postgresql-common de Debian crée un cluster principal lors de l’installation du paquet serveur uniquement lorsqu’aucun cluster n’existe encore. Un cluster PostgreSQL 16 existant n’entraîne donc pas automatiquement la création d’un cluster PostgreSQL 18 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

Une entrée correspondant à la version 16 signifie que ce cluster utilise toujours PostgreSQL 16. Si pg_lsclusters affiche également un cluster 18 main, vérifiez qu’il est vide avant de le supprimer avec sudo pg_dropcluster --stop 18 main, car pg_upgradecluster n’écrira pas dans un cluster cible qui existe déjà. Effectuez la migration lorsque vous pouvez arrêter l’application :

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

La méthode par défaut sauvegarde PostgreSQL 16, puis recharge les données dans PostgreSQL 18. Vous avez donc besoin d’un espace disque libre correspondant approximativement à la taille de la base de données. -m upgrade utilise à la place pg_upgrade et est beaucoup plus rapide avec une base de données volumineuse. Une fois l’opération terminée, consultez la colonne Port : le nouveau cluster récupère le port 5432 et l’ancien reste arrêté. Le hook de mise à niveau des paquets exécute automatiquement une passe d’analyse. La commande ci-dessus la répète explicitement.

Testez l’application avec le nouveau cluster pendant quelques jours. Supprimez 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 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 ce point tant que vous êtes encore en 8.0 :

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

Basculez chaque compte affichant 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 fixez-lui une date de fin, car MySQL a supprimé le plugin dans 9.0.

PHP 8.3 à 8.5 : vos vhosts 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 vhost nginx contenant fastcgi_pass unix:/run/php/php8.3-fpm.sock; pointe désormais vers un socket qu’aucun processus ne crée. Chaque requête PHP renvoie donc 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 stack LAMP sur Ubuntu 24.04, vérifiez ces deux chemins. Le guide vous laisse avec un nom de module versionné et un socket versionné.

Les réglages de votre php.ini ne sont pas conservés non plus. memory_limit, upload_max_filesize et 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. 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 est simplement absente.

Les certificats nécessitent une vérification distincte. Exécutez sudo certbot renew --dry-run --run-deploy-hooks après la mise à niveau. Cette commande teste l’ensemble du 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 dont le nom a changé échoue à ce moment-là, sous vos yeux, au lieu d’échouer silencieusement lors du prochain renouvellement. Certbot avec Let’s Encrypt sur nginx explique à quoi ces hooks doivent ressembler.

SSH : l’erreur qui met fin à la session sur laquelle vous travaillez

L’invite sshd_config est l’endroit où l’on se retrouve bloqué hors du serveur. Répondre Y installe le fichier du mainteneur, ce qui supprime vos PermitRootLogin, PasswordAuthentication, AllowUsers, Port et toutes les autres lignes que vous avez ajoutées. Si votre firewall autorise uniquement un port personnalisé et que la configuration fournie écoute sur 22, la connexion suivante est refusée. La session dans laquelle vous êtes devient 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, pour la plupart des paramètres, OpenSSH conserve la première valeur lue. Un fichier drop-in inclus en haut de la configuration est donc prioritaire sur le même paramètre défini plus bas. Quelques mots-clés font exception : Port et ListenAddress acceptent plusieurs valeurs. Une ligne Port dans un fichier drop-in ajoute donc un port au lieu de remplacer celui défini plus bas. Déplacez vos paramètres dans un fichier que dpkg ne gère pas :

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 fichier de /etc/ssh/sshd_config ne vous appartient, cette invite ne pose plus de problème : 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 que vous pensez :

systemctl is-enabled ssh.socket

Si cette commande affiche enabled, c’est systemd qui ouvre le port en écoute, et non sshd. Ubuntu utilise l’activation par socket pour sshd depuis 22.10. Sur 24.04, un générateur systemd lit les paramètres Port et ListenAddress dans la configuration de sshd et les transforme en adresses d’écoute du socket, mais uniquement lorsque systemd recharge ses unités. C’est pourquoi une modification de Port 2222 semble ne rien faire : elle prend effet après sudo systemctl daemon-reload && sudo systemctl restart ssh.socket, et le fichier sshd_config fourni contient désormais une note qui l’indique. Pour définir directement le port sur l’unité socket, utilisez plutôt 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 également sur 22, en plus de 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 êtes :

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 connectez-vous de nouveau. Un shell fonctionnel dans ce deuxième terminal est la seule preuve valable. Gardez la première session ouverte jusque-là. Renforcer la sécurité de 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 à cette console, 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 ?

Depuis le 29 septembre 2026, ce message ne devrait plus s’afficher, car Canonical a activé ce jour-là les mises à niveau d’Ubuntu 24.04 LTS vers 26.04.1. Avant cette date, le message était attendu : Ubuntu 26.04 LTS est sorti le 23 avril 2026, 26.04.1 a suivi le 27 août, et la mise à niveau est restée bloquée quelques semaines supplémentaires, le temps que Canonical rétroporte les correctifs liés aux régressions de rust-coreutils. Si le message s’affiche encore, vérifiez que /etc/update-manager/release-upgrades contient Prompt=lts, la valeur par défaut d’Ubuntu Server, qui ne propose que la prochaine version LTS. Laissez cette valeur sur lts.

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 de l’opération. 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 contrôler le nouveau kernel 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 vierge ?

Créez un serveur vierge lorsque c’est possible. Un nouveau VPS permet d’installer la stack, de restaurer les données et de tout tester pendant que l’ancien serveur continue de traiter le trafic. Le rollback se résume alors à modifier le DNS, au lieu de restaurer une sauvegarde. Faites une 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 une procédure éprouvée, 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 ?

L’upgrader du serveur utilise normalement GNU screen. Une interruption de la connexion SSH n’arrête donc pas la mise à niveau à elle seule. Si vous l’avez lancée dans la session tmux nommée plus haut, reconnectez-vous et exécutez tmux attach -t upgrade pour la reprendre. L’upgrader démarre également un daemon SSH temporaire sur le port 1022 comme seconde méthode d’accès. Il n’ouvre toutefois pas le firewall pour ce port. Autorisez donc d’abord le port 1022, puis refermez-le après l’opération.

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 log d’erreur nginx indique 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.