Ubuntu 26.04.1 : qu’est-ce qu’une version intermédiaire ?

Ce qu’est une version intermédiaire d’Ubuntu

Une version intermédiaire d’Ubuntu, comme 26.04.1, correspond à la version que vous utilisez déjà, avec toutes les mises à jour publiées depuis sa sortie intégrées à de nouveaux supports d’installation. Ce n’est pas une nouvelle version. L’archive depuis laquelle elle est installée ne change pas, pas plus que le nom de la suite dans vos sources apt. Un serveur installé et à jour n’a donc rien à télécharger lorsqu’une version intermédiaire paraît.

Deux éléments sont publiés ce jour-là. Les supports sont reconstruits : de nouveaux fichiers ISO et de nouvelles images cloud sont générés à partir de l’état de l’archive cette semaine-là. La chaîne de version évolue également : lsb_release -a commence à renvoyer 26.04.1 LTS alors qu’il renvoyait auparavant 26.04 LTS.

Tout le reste était déjà présent sur votre système. Ubuntu publie en continu les correctifs dans les poches -security et -updates d’une même suite : resolute pour 26.04 et noble pour 24.04. Une version intermédiaire est un instantané de ce flux. Il n’existe aucune destination distincte vers laquelle migrer.

Pourquoi votre serveur à jour n’a rien à télécharger

Le numéro de version corrective se trouve dans un petit paquet. Exécutez ceci :

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S répond à base-files: /etc/lsb-release. Le paquet base-files fournit les fichiers qui contiennent votre chaîne de version. Lorsqu’une version corrective est publiée, un nouveau base-files arrive dans le pocket -updates, puis votre prochain sudo apt upgrade l’installe. Ce paquet constitue tout l’effet visible d’une version corrective sur une machine en fonctionnement. Tout le reste qu’il contient a été installé plusieurs semaines auparavant sous forme de mises à jour ordinaires.

Il existe une cause fréquente de retard. Le /etc/apt/apt.conf.d/50unattended-upgrades par défaut active l’origine -security dans son bloc Allowed-Origins et laisse la ligne -updates commentée. Une machine qui utilise uniquement les mises à jour automatiques installe donc les correctifs de sécurité, mais ignore le reste. Elle continue de signaler un ancien numéro de version corrective pendant des mois. C’est normal, car ces paquets ne sont réellement pas installés. Ouvrez le fichier et vérifiez quelles lignes sont commentées : comment les mises à jour automatiques sont configurées sur Ubuntu examine ce bloc ligne par ligne.

À la sortie de la prochaine mise à jour intermédiaire

Retenez la cadence, pas la date. La première mise à jour intermédiaire d’une version LTS sort quelques mois après la version initiale d’avril. Les suivantes paraissent ensuite à environ six mois d’intervalle, en suivant chaque version intermédiaire. Les dates peuvent changer. Canonical avait annoncé la première mise à jour intermédiaire de 26.04 pour le début du mois d’août 2026, puis l’a repoussée. C’est courant et ce n’est pas un signe inquiétant. Consultez la date sur la page du cycle de publication d’Ubuntu ou dans les notes de version de 26.04 LTS, plutôt que dans un article, y compris celui-ci.

Pourquoi 24.04 ne propose pas 26.04 avant la première mise à jour intermédiaire

L’invite de mise à niveau est configurée pour attendre. Vous pouvez consulter cette configuration sur votre propre serveur.

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

Les commentaires du fichier fourni sont plus longs que cet extrait et méritent d’être lus en entier. Prompt=lts est la valeur par défaut sur une installation LTS et remplit deux fonctions : il limite la proposition aux versions LTS et envoie la vérification vers une autre liste.

Cette liste est indiquée dans un second fichier :

cat /etc/update-manager/meta-release

URI pointe vers https://changelogs.ubuntu.com/meta-release et URI_LTS pointe vers https://changelogs.ubuntu.com/meta-release-lts. Avec Prompt=lts, l’upgrader lit la liste LTS. La nouvelle LTS n’y est pas proposée comme cible de mise à niveau avant la publication de sa première mise à jour intermédiaire. Récupérez la liste et vérifiez par vous-même :

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

Chaque version forme un bloc de lignes Dist:, Version:, Supported: et UpgradeTool:. L’upgrader a besoin de ce bloc avant de pouvoir vous proposer une version. Canonical énonce la même règle en toutes lettres dans l’annonce de publication de 26.04 LTS : les utilisateurs de 24.04 LTS reçoivent la proposition de mise à niveau automatique lors de la publication de 26.04.1.

Ainsi, sur un serveur en 24.04 avant cette mise à jour intermédiaire :

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

C’est un résultat normal, pas une panne. Lorsque le chemin est ouvert, la même commande indique la version et le même message apparaît dans la bannière de connexion :

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Observez la version indiquée. Vous ne mettez pas à niveau vers 26.04, puis vers 26.04.1. Vous effectuez une seule mise à niveau et arrivez dans l’état actuel de 26.04.

Deux autres situations produisent une vérification vide : Prompt=never, que certaines images de fournisseurs définissent, et un proxy ou un miroir qui ne peut pas atteindre changelogs.ubuntu.com. Un autre message, Please install all available updates for your release before upgrading, signifie que la vérification a abouti et que l’upgrader exige un système de départ entièrement mis à jour. do-release-upgrade n’indique aucune nouvelle version examine les autres causes possibles. Lorsque le chemin est ouvert et que vous êtes prêt, la mise à niveau de 24.04 vers 26.04 constitue une opération distincte, avec sa propre préparation.

L’option -d dirige la même vérification vers la liste de développement. C’est ainsi que certains effectuent la mise à niveau avant l’ouverture du chemin. Cette attente a une raison : elle permet de corriger les blocages signalés par les premiers utilisateurs. Sur un serveur que vous louez et dont vous dépendez, il est donc préférable de laisser cette attente se dérouler.

Ce que signifie le kernel HWE sur un VPS

Une LTS conserve un seul kernel pendant toute sa durée de vie : le kernel GA (general availability). Elle propose aussi une seconde branche évolutive, appelée HWE (hardware enablement). La branche HWE est distribuée par les point releases. C’est la seule partie d’une point release qui contient réellement du nouveau code, et pas seulement un reconditionnement de ce que vous utilisez déjà.

24.04 sert d’exemple. Cette version est sortie avec le kernel 6.8 et conserve 6.8 sur la branche GA pendant ses cinq années de support standard. La branche HWE a commencé avec la deuxième point release : 24.04.2 a apporté le kernel 6.11 d’Ubuntu 24.10, puis 24.04.3 a apporté le kernel 6.14 d’Ubuntu 25.04. En août 2026, ce schéma est établi, et 26.04 suit la même logique.

La branche utilisée est identifiable par le nom du package :

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

linux-generic correspond à la branche GA. linux-generic-hwe-24.04 correspond à la branche évolutive. Les installations Desktop utilisent HWE par défaut, tandis que les installations Server utilisent GA par défaut. Les images fournies par un provider pour un VPS utilisent souvent une variante encore plus ciblée, comme linux-virtual ou un linux-kvm spécifique au cloud. Vérifiez au lieu de supposer, car la valeur par défaut dépend de la personne qui a construit votre image.

Sur du matériel virtuel loué, le hardware enablement ne vous concerne généralement pas. Votre serveur voit des périphériques virtio, ainsi que les interfaces réseau et disque paravirtualisées présentées par l’hyperviseur. Ces drivers sont stables dans le kernel depuis plus de dix ans. Un laptop récent a besoin de HWE. Un VPS, presque jamais. Sur un VPS, un kernel plus récent vous apporte surtout des fonctionnalités de kernel : des améliorations récentes pour io_uring et eBPF, ou un correctif de filesystem que vous avez une raison précise de vouloir utiliser. ce qui est nouveau dans le kernel Linux 7.1 vous permet de déterminer si cela justifie les changements.

Le coût est double : des reboots et un risque accru. Le meta package HWE installe un nouveau kernel upstream environ tous les six mois. Vous acceptez donc un changement de kernel et un reboot à ce rythme. Les modules externes compilés avec DKMS, notamment ZFS, peuvent ne pas se compiler avec la nouvelle version. Vous le découvrez alors au boot. Chaque kernel conserve également son prédécesseur, ce qui peut remplir un petit /boot. Lisez supprimer les anciens kernels d’un /boot plein et choisir le kernel sur lequel votre VPS démarre avant d’en avoir besoin.

Passer à la branche HWE nécessite une commande et un reboot :

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

uname -r doit afficher la version la plus récente après le reboot. Conservez l’ancien kernel jusqu’à ce que vous ayez démarré sur le nouveau et vérifié vos services. Pour récupérer un kernel qui ne démarre pas, il faut sélectionner l’ancienne entrée dans le boot menu. Cette entrée doit donc encore exister. Dans le cas contraire, vous devez récupérer un VPS qui ne démarre plus après une mise à jour du kernel.

Il existe également une variante -edge du package HWE. Elle installe le kernel suivant avant la point release. Elle est destinée aux tests. Ne l’utilisez pas sur un serveur.

Par défaut, choisissez le kernel GA sur un serveur loué : une seule version de kernel pendant cinq ans, avec des correctifs de sécurité backportés pendant toute cette période et aucun changement de version planifié. Passez à HWE lorsque vous pouvez nommer la fonctionnalité dont vous avez besoin.

Pourquoi une nouvelle installation aujourd’hui diffère de celle du mois dernier

Les images sont reconstruites plus souvent que les versions de maintenance ne sont publiées. Ubuntu publie des images cloud marquées par un numéro de série, et chaque fournisseur actualise ses templates Ubuntu selon son propre calendrier. Ainsi, deux serveurs créés à six mois d’intervalle depuis la même entrée de menu peuvent démarrer avec des versions différentes du kernel et des versions de paquets différentes. Aucun des deux n’est incorrect.

La différence est plus importante qu’il n’y paraît. Une procédure qui indique d’exécuter cinq commandes après l’installation suppose implicitement un état initial qui n’est plus garanti. Vérifiez lsb_release -a et uname -r sur chaque machine au lieu de vous fier au libellé sélectionné, puis définissez l’état final dans le code afin que l’état initial n’ait plus d’importance. un premier playbook Ansible pour un VPS en est la version minimale réellement utile.

Faut-il migrer dès la publication de la version intermédiaire, ou attendre ?

• Si vous utilisez déjà 26.04, vous n’avez rien vers quoi migrer. Continuez à installer les mises à jour ; le numéro de version intermédiaire évoluera automatiquement.
• Si vous utilisez 24.04, le support standard court jusqu’en avril 2029. Attendre ne coûte donc pas grand-chose. La première version intermédiaire est une possibilité, pas une échéance.
• Commencez par mettre à niveau une copie. Prenez un snapshot du serveur ou recréez la même stack sur un VPS temporaire, effectuez la mise à niveau et mesurez sa durée.
• Si vous cherchez un kernel plus récent plutôt qu’une version plus récente, le canal HWE vous l’apporte sur 24.04 sans mise à niveau LTS.

La question plus générale du choix de la version à utiliser est traitée dans Versions LTS ou intermédiaires pour un serveur.

Vérifications à effectuer sur votre serveur

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Un résultat sain se présente ainsi : lsb_release -a indique votre release avec son numéro de version correctif actuel, uname -r correspond à la branche du kernel que vous aviez prévue, Prompt=lts est présent, et la vérification ne trouve rien ou indique la release qu’elle proposera. Tout autre résultat doit être compris avant la mise à niveau, et non pendant celle-ci.

FAQ

Dois-je faire quelque chose lorsqu’une version intermédiaire comme 26.04.1 sort ?

Non, à condition que le serveur utilise déjà cette version et reçoive les mises à jour. Une version intermédiaire regroupe les mises à jour déjà publiées dans un nouveau support d’installation. Une machine en fonctionnement reçoit le même contenu via apt upgrade dès sa publication, et la chaîne de version dans lsb_release -a change lorsque le paquet base-files est mis à jour. Il n’y a pas de version distincte vers laquelle migrer et aucune réinstallation n’est nécessaire.

Pourquoi mon serveur indique-t-il encore un ancien numéro de version intermédiaire après un apt upgrade ?

Le plus souvent, les mises à jour automatiques sont limitées aux correctifs de sécurité. Le /etc/apt/apt.conf.d/50unattended-upgrades par défaut active l’origine -security et laisse la ligne -updates commentée, tandis que le paquet base-files qui contient la chaîne de version provient de -updates. Exécutez sudo apt update && sudo apt full-upgrade manuellement et vérifiez si base-files apparaît dans la liste. S’il est indiqué comme conservé, un pinning ou un blocage empêche sa mise à jour.

Pourquoi la mise à niveau vers 26.04 n’est-elle pas proposée sur mon serveur 24.04 ?

Parce que Prompt=lts dans /etc/update-manager/release-upgrades est la valeur par défaut sur une LTS, et vérifie la liste des LTS à l’adresse https://changelogs.ubuntu.com/meta-release-lts. La nouvelle LTS n’y est pas proposée comme cible de mise à niveau avant sa première version intermédiaire. D’ici là, sudo do-release-upgrade -c affiche No new release found., ce qui est le comportement attendu. Cette attente est volontaire : elle laisse le temps de corriger les problèmes de mise à niveau rencontrés par les premiers utilisateurs.

Dois-je installer le kernel HWE sur mon VPS ?

En général, non. Le support matériel étendu sert à prendre en charge du matériel plus récent que la version installée, tandis qu’un VPS présente des périphériques virtio dont les pilotes sont intégrés au kernel depuis des années. Le kernel GA reste sur une même version pendant toute la durée de vie de la LTS, avec des correctifs rétroportés. Utilisez le kernel HWE uniquement si vous pouvez indiquer la fonctionnalité du kernel dont vous avez besoin, et acceptez alors une nouvelle version du kernel ainsi qu’un redémarrage environ tous les six mois.