Pourquoi do-release-upgrade ne trouve aucune version

Pourquoi do-release-upgrade indique qu’aucune nouvelle version n’est disponible

do-release-upgrade se terminant par No new release found. n’indique presque jamais un outil défectueux. Le chemin demandé est fermé à ce moment-là, et l’outil le signale de la manière la plus concise possible. Cinq éléments peuvent le fermer : le paramètre Prompt dans /etc/update-manager/release-upgrades, le verrou de la point release lors des mises à niveau LTS (long term support), les dépôts tiers, les paquets bloqués ou partiellement configurés, et une version qui n’est plus supportée.

Traitez-les dans cet ordre. Pour chacun, une commande permet de vérifier s’il s’applique à votre serveur. Vous n’avez donc jamais à deviner lequel des cinq cas vous rencontrez.

Ce que l’option de vérification seule indique

sudo do-release-upgrade -c
echo $?

-c effectue uniquement une vérification. La commande lit les métadonnées de version de Canonical via HTTPS (hypertext transfer protocol secure), puis affiche le résultat. Elle ne télécharge aucun outil de mise à niveau et ne réécrit aucun fichier de sources. Deux résultats sont importants :

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Le code de sortie fournit le même résultat aux scripts. Il vaut 0 lorsqu’une version est disponible et 1 lorsqu’il n’y en a aucune. C’est l’inverse de la convention habituelle du shell. Vérifiez donc ce point avant de baser une vérification dessus.

Si votre bannière de connexion affiche encore l’ancien résultat, celui-ci est mis en cache. Cette ligne provient de /etc/update-motd.d/91-release-upgrade, qui affiche un résultat enregistré au lieu d’interroger le réseau. Actualisez-le avec sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd ou faites simplement confiance à -c. La bannière ne fait que répéter le résultat de la dernière vérification exécutée.

La vérification doit également pouvoir joindre changelogs.ubuntu.com. Sur un serveur situé derrière un pare-feu sortant strict ou un proxy que l’outil ne peut pas utiliser, la commande ne peut pas effectuer la requête. Elle ne peut donc rien détecter.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Une ligne HTTP/2 200 signifie que le serveur peut accéder aux métadonnées. Une ligne curl: (28) Connection timed out signifie que vos règles de trafic sortant sont la cause réelle. Modifier les fichiers APT (advanced package tool) ne changera pas le résultat.

Si la commande est totalement absente, elle se trouve dans ubuntu-release-upgrader-core. Certaines images cloud minimales n’incluent pas ce paquet.

sudo apt install ubuntu-release-upgrader-core

Consultez /etc/update-manager/release-upgrades avant toute modification

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Le fichier contient sa propre documentation sous forme de commentaires. Trois valeurs sont valides :

• never : ne jamais rechercher ni autoriser la mise à niveau vers une nouvelle version.
• normal : proposer la version prise en charge qui suit immédiatement la version en cours d’exécution.
• lts : proposer la première version LTS qui suit la version en cours d’exécution.

Prompt=never est la plus facile des trois à diagnostiquer, car l’outil indique dans sa sortie le nom du fichier et celui du paramètre :

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

Les hébergeurs et les outils de gestion de configuration définissent délibérément never afin d’empêcher un parc de se disperser entre plusieurs versions. Si vous trouvez cette valeur, quelqu’un l’a choisie. Remplacez-la par lts pour un serveur que vous voulez maintenir sur la branche de support à long terme, puis rétablissez l’ancienne valeur si votre automatisation l’attend.

Un détail de ces commentaires piège souvent les administrateurs. Lorsque Prompt=lts est défini et que la version en cours d’exécution n’est pas elle-même une version LTS, l’outil de mise à niveau interprète ce paramètre comme normal. Sur une machine en 25.10, les deux valeurs se comportent de la même manière. Sur une machine en 24.04, elles se comportent différemment. C’est l’objet de la section suivante.

Pourquoi une mise à niveau LTS vers LTS attend la première version intermédiaire

Prompt détermine le fichier de métadonnées que lit l’outil de mise à niveau. Les adresses se trouvent dans /etc/update-manager/meta-release :

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts lit meta-release-lts. Prompt=normal lit meta-release. Les deux fichiers décrivent chaque version dans un petit bloc de clés. L’outil de mise à niveau ne propose une version que lorsque son indicateur Supported: vaut 1. Vous pouvez consulter ces fichiers directement depuis le même serveur :

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Vérification effectuée le 13 août 2026 : les deux fichiers ne donnent pas la même information pour Ubuntu 26.04. Le fichier LTS indique :

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

Le fichier standard indique :

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Cette valeur Supported: 0 dans le fichier LTS constitue le blocage. Un serveur 24.04 utilisant la valeur par défaut Prompt=lts lit ce fichier, ne trouve aucune version LTS plus récente marquée comme disponible et affiche No new release found. Rien ne fonctionne mal sur votre machine. Canonical n’a pas encore ouvert le chemin de mise à niveau.

L’indicateur passe à 1 lorsque la première version intermédiaire est publiée. Ubuntu 26.04.1 est prévue pour le 27 août 2026, mais le calendrier des versions peut changer. Consultez donc les métadonnées plutôt que de vous fier à une date. Ce délai est volontaire : les premiers utilisateurs identifient les blocages, qui sont ensuite corrigés avant que la population beaucoup plus importante de serveurs LTS ne suive.

Deux options sont donc possibles. Attendre la version intermédiaire est le choix recommandé pour un serveur que vous préférez ne pas surveiller. Vous pouvez aussi définir Prompt=normal, qui dirige le même outil vers meta-release, où 26.04 est déjà marquée comme prise en charge. Cette deuxième méthode vous met à niveau vers la version publiée 26.04, et non vers une version de développement. Elle peut donc se justifier sur une machine que vous pouvez restaurer à partir d’un snapshot. Rétablissez la valeur lts lorsque vous avez terminé. La procédure complète, étape par étape, se trouve dans le guide complet de mise à niveau d’un serveur 24.04 vers 26.04.

Dépôts tiers et PPA qui bloquent la mise à niveau

Le programme de mise à niveau réécrit vos sources APT pour les faire pointer vers la nouvelle version. Il ne peut le faire que pour un dépôt qui publie des paquets pour cette version. Tous les autres dépôts sont donc commentés. Les raisons sont affichées une par entrée et sont précises : was disabled (unknown mirror), was disabled (unknown dist) et was disabled (no Release file).

Un PPA (personal package archive) conçu pour noble ne possède pas de répertoire pour resolute sur le serveur. Le programme de mise à niveau ne peut donc pas récupérer de fichier Release pour la nouvelle série et désactive l’entrée. Il s’agit généralement d’un avertissement que vous pouvez accepter. La situation devient bloquante lorsqu’un dépôt tiers fournit un paquet que la nouvelle version fournit également. Le calcul de la mise à niveau dispose alors de deux candidats et ne peut pas satisfaire les deux dépendances.

Prenez vous-même cette décision avant de commencer, au lieu de laisser l’outil la prendre pendant une longue exécution sans surveillance.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy appliqué à un nom de paquet affiche le dépôt d’origine de chaque version installée. Vous pouvez ainsi voir exactement quels paquets dépendent de la source que vous allez désactiver. La suppression de la source ne rétrograde aucun paquet. Un paquet installé depuis un PPA conserve donc sa version provenant du PPA et peut être plus récent que la version fournie par la nouvelle version. Si cela pose problème, supprimez également le paquet, puis réinstallez-le depuis l’archive après la mise à niveau. Pour un dépôt que vous prévoyez de réactiver, comme celui de Tailscale, vous devez mettre à jour son codename vers celui de la nouvelle version avant de pouvoir réinstaller le paquet. C’est la cause de la plupart des erreurs d’installation de Tailscale sur Ubuntu.

Il existe un flag pour faire le choix inverse. La page de manuel décrit --allow-third-party ainsi : "Try the upgrade with third party mirrors and repositories enabled instead of commenting them out." Utilisez-le uniquement après avoir vérifié que le dépôt publie déjà des paquets pour la version cible. Dans le cas contraire, vous demandez à APT de résoudre un graphe de dépendances pour une série que ce dépôt n’a jamais compilée.

Sur Ubuntu 24.04 et les versions ultérieures, la plupart des sources se trouvent dans /etc/apt/sources.list.d/ubuntu.sources au format deb822. Le même dépôt déclaré à la fois dans l’ancien et dans le nouveau format constitue une erreur distincte, avec son propre message. Elle est traitée dans l’erreur d’entrée de source en double au format deb822.

Les paquets retenus et partiellement configurés bloquent le calcul

Une mise à niveau de version doit déplacer presque tous les paquets du système. Si un paquet ne peut pas être mis à niveau, le calcul échoue. Le programme de mise à niveau préfère s’arrêter rapidement plutôt que de vous laisser avec un système à moitié mis à niveau. Deux commandes permettent d’en trouver la cause.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold affiche les paquets retenus, un par ligne, et n’affiche absolument rien sur un système propre. Une retenue est une instruction manuelle qui interdit toute modification de ce paquet. Quelqu’un a peut-être figé une version du kernel ou d’une base de données, puis l’a oublié. Supprimez les retenues dont vous n’avez plus besoin avec sudo apt-mark unhold, suivi du nom du paquet.

dpkg --audit liste les paquets décompressés mais jamais configurés. Cet état résulte d’une installation interrompue, le plus souvent à cause d’une session interrompue. Le programme de mise à niveau essaie de les réparer et affiche dpkg interrupted, calling dpkg --configure -a, mais lancer vous-même la réparation permet de lire l’erreur au lieu de la voir défiler. Lorsqu’un paquet ne peut pas être réparé par l’outil, le message Package in inconsistent state s’affiche. Ce paquet doit être traité avant une nouvelle tentative.

Mettez la version actuellement installée complètement à jour avant de la mettre à niveau.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

L’option des mises à jour phased est plus importante qu’il n’y paraît. Ubuntu déploie certaines mises à jour progressivement, sur un pourcentage de machines à la fois. Une commande apt upgrade simple peut donc laisser correctement certains paquets en attente, et le serveur est alors moins à jour que vous ne le pensez. Cette option installe tous ces paquets. Redémarrez ensuite si un kernel a été installé avec eux, afin d’effectuer la mise à niveau depuis le kernel réellement en cours d’exécution. Un serveur qui se maintient déjà à jour avec les mises à niveau de sécurité automatiques a moins de travail à effectuer ici, même si ce mécanisme ne franchit volontairement jamais une limite de version.

Quand la release dépasse la fin du support standard

Une release intermédiaire d’Ubuntu est prise en charge pendant neuf mois. À la fin de cette période, son indicateur Supported: passe à 0, et la procédure normale ne permet plus de la mettre à niveau. Vérifié le 13 août 2026, meta-release indique ceci pour la version 25.10 :

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

L’archive est également déplacée au même moment. Les paquets d’une release en fin de vie sont retirés de archive.ubuntu.com et conservés dans old-releases.ubuntu.com. Ainsi, apt update commence à renvoyer 404 Not Found, le système ne peut plus être mis à jour, et comme l’upgrader exige un système à jour, la procédure n’avance pas. Corrigez d’abord les sources.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Pointez archive.ubuntu.com et security.ubuntu.com vers old-releases.ubuntu.com, sans modifier le codename. Seul le nom d’hôte change.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Exécutez la même commande sur /etc/apt/sources.list si votre serveur conserve encore ses sources dans ce fichier unique. L’option -i.bak crée une copie de sauvegarde à côté du fichier original. Vous pourrez ainsi le restaurer si la modification visait le mauvais fichier. Si apt update s’exécute ensuite sans erreur, l’archive est de nouveau accessible et do-release-upgrade pourra à nouveau communiquer avec les dépôts.

Ne vous attendez pas à aller très loin avec cette méthode. Ubuntu ne prend en charge qu’un seul saut de release à la fois. Un serveur ayant deux ou trois releases obsolètes de retard doit donc franchir chaque étape successivement. Chaque étape peut échouer à cause de son propre dépôt tiers ou d’un paquet marqué comme retenu. Sur un VPS, il est souvent plus rapide de créer un nouveau serveur avec la LTS actuelle, d’y transférer le service, puis de conserver l’ancien jusqu’à validation complète. Vous disposez ainsi d’un rollback, ce qu’une mise à niveau sur place ne permet jamais. Si vous devez choisir la branche à utiliser ensuite, la différence entre les releases LTS et intermédiaires sur un serveur mérite d’être lue avant de décider.

Ce que fait réellement l’option de version de développement

-d, ou --devel-release, demande à l’outil de mise à niveau de lire meta-release-development au lieu du fichier sélectionné par Prompt. La page de manuel la décrit ainsi : « Si vous utilisez la dernière version prise en charge, effectuer la mise à niveau vers la version de développement. »

Vérifié le 13 août 2026, l’entrée la plus récente de ce fichier n’est pas 26.04 :

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Ainsi, -d ne fournit pas à un serveur 24.04 la version publiée 26.04. Cette option cible 26.10, une version encore en cours de préparation. Les anciens conseils recommandant « d’ajouter simplement -d » concernaient la période précédant la publication d’une LTS. Les reprendre maintenant oriente votre serveur vers une version que vous n’aviez pas l’intention d’utiliser. Avec Prompt=lts toujours présent, l’option s’arrête et affiche son propre message :

There is no development version of an LTS available.

La documentation serveur d’Ubuntu est claire au sujet de cette option : « l’utilisation de la version de développement (ou de l’option -d) n’est pas recommandée dans les environnements de production ». Une version de développement change chaque jour et ne bénéficie d’aucune garantie de support de sécurité. Un paquet fonctionnel le matin peut donc interrompre un service l’après-midi. Utilisez-la sur une machine virtuelle de test créée pour vérifier votre propre configuration. Ne l’utilisez pas sur un serveur dont dépendent d’autres personnes. Si vous voulez obtenir une version publiée 26.04 avant l’ouverture de la période LTS, Prompt=normal est la bonne méthode.

Lancez la mise à niveau dans un environnement où une coupure SSH ne peut pas l’interrompre

Une mise à niveau de version remplace la plupart des composants du système, notamment openssh-server et systemd. Si votre session SSH (secure shell) se ferme pendant que dpkg travaille, le processus est tué alors que des paquets sont décompressés et non configurés. C’est précisément l’état qui empêche votre tentative suivante d’aboutir. Lancez toujours la mise à niveau dans un terminal multiplexer.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Si la connexion est interrompue, reconnectez-vous et exécutez tmux attach -t upgrade. La mise à niveau a continué, car elle est un processus enfant du serveur tmux et non de votre session SSH. screen -S upgrade et screen -r upgrade remplissent le même rôle si vous préférez screen.

L’outil de mise à niveau intègre une protection pour les utilisateurs qui n’emploient pas de multiplexer. Lorsqu’il détecte qu’il s’exécute dans une session SSH, il propose de lancer un second sshd sur le port 1022. Ainsi, une interruption de la session principale laisse tout de même un point d’accès. Il prend sa décision en parcourant ses propres processus parents à la recherche d’un processus nommé sshd. Dans tmux ou screen, ce parcours trouve à la place le serveur du multiplexer. La proposition n’apparaît donc jamais, et le fichier PID /var/run/release-upgrader-sshd.pid n’est écrit que lorsque le daemon supplémentaire démarre réellement. Il est normal de ne pas voir cette invite. Vous bénéficiez déjà de la meilleure protection.

Si vous acceptez la proposition, le port n’est pas ouvert automatiquement. L’outil vous le précise, car l’ouverture d’un port est une décision de sécurité qu’il ne peut pas prendre à votre place. Ouvrez-le pendant la durée de la mise à niveau, puis refermez-le.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

La plupart des fournisseurs de VPS exécutent un second firewall dans leur panneau de contrôle, en dehors du système d’exploitation. Le port 1022 doit également y être ouvert. Sinon, le listener de secours fonctionne mais reste inaccessible, ce qui est la pire situation.

Quatre éléments doivent être prêts avant d’exécuter la commande :

• Prenez un snapshot ou effectuez une sauvegarde complète. Une mise à niveau de version sur place ne peut pas être annulée. C’est votre seul retour possible.
• Vérifiez que vous pouvez ouvrir la console de votre fournisseur avant d’en avoir besoin. Si le serveur ne redémarre pas après son reboot, vous n’aurez précisément plus accès à SSH. Un kernel qui ne démarre pas est un problème distinct, avec ses propres étapes de récupération, décrites dans un VPS qui ne démarre pas après une mise à jour du kernel.
• Vérifiez l’espace libre avec df -h / /boot. La mise à niveau télécharge un jeu complet de paquets, et une partition /boot contenant plusieurs anciens kernels est un emplacement fréquent de blocage.
• Lisez les notes de version des services que vous utilisez. Un saut de version majeure de PostgreSQL ou de PHP arrive avec la release, que vous l’ayez prévu ou non.

FAQ

Pourquoi do-release-upgrade indique-t-il qu’aucune nouvelle release n’est disponible sur Ubuntu 24.04 ?

La valeur par défaut de Prompt=lts dans /etc/update-manager/release-upgrades fait lire https://changelogs.ubuntu.com/meta-release-lts à l’outil. Ubuntu 26.04 conserve Supported: 0 dans ce fichier jusqu’à sa première point release. L’outil de mise à niveau ne trouve aucune release LTS plus récente marquée comme disponible et s’arrête. Vérifiez vous-même le fichier avec curl -s https://changelogs.ubuntu.com/meta-release-lts, puis consultez le dernier bloc. Au 13 August 2026, le flag était toujours 0, et Ubuntu 26.04.1 était prévu pour le 27 August 2026.

Est-il sûr de définir Prompt=normal au lieu d’attendre la point release ?

La mise à niveau vous installe Ubuntu 26.04, qui est une release publiée, et non une version de développement, car Prompt=normal lit meta-release, où 26.04 porte déjà Supported: 1. Le risque concerne le moment choisi. Vous effectuez la mise à niveau avant la correction des problèmes rencontrés par les premiers utilisateurs. Faites-le sur un serveur que vous pouvez restaurer depuis un snapshot et dont la console du fournisseur reste accessible si le redémarrage échoue. Rétablissez ensuite la valeur lts.

Le flag -d met-il mon système à niveau vers 26.04 ?

Non. -d lit meta-release-development, dont l’entrée la plus récente au 13 August 2026 était Ubuntu 26.10, une release encore en développement. Sur une machine LTS avec Prompt=lts, le flag affiche There is no development version of an LTS available., puis s’arrête. La documentation serveur officielle d’Ubuntu indique que la release de développement n’est pas recommandée en production. Utilisez donc Prompt=normal si vous voulez installer rapidement une version publiée de 26.04.

apt update renvoie des erreurs 404 sur une ancienne release. Comment la mettre à niveau ?

Cette release a atteint sa fin de vie. Ses paquets ont donc été déplacés de archive.ubuntu.com vers old-releases.ubuntu.com. Modifiez uniquement les noms d’hôte dans /etc/apt/sources.list.d/ubuntu.sources, ou dans /etc/apt/sources.list pour les anciennes structures, et conservez votre codename. Exécutez ensuite sudo apt update, puis sudo apt full-upgrade. Une fois le système à jour, do-release-upgrade peut le faire progresser d’une release à la fois.

Dois-je supprimer mes PPA avant d’exécuter do-release-upgrade ?

Ce n’est pas obligatoire, car l’outil de mise à niveau commente toute source qui ne publie pas de paquets pour la nouvelle release. Il affiche aussi une ligne telle que was disabled (no Release file) pour chacune d’elles. Il est toutefois préférable de le faire vous-même au préalable. Vous choisissez ainsi l’ordre des opérations et vous pouvez contrôler le résultat. Exécutez apt policy sur les paquets concernés pour identifier ceux qui proviennent de chaque PPA. Réinstallez-les ensuite depuis l’archive si la version du PPA est plus récente que celle disponible dans la nouvelle release.