Ubuntu 26.04 LTS « Resolute Raccoon » est sorti le 23 avril 2026. Pourtant, si votre serveur tourne sous 24.04 LTS, do-release-upgrade vous répond depuis quatre mois qu'aucune nouvelle version n'est disponible. Ce n'est pas un bug : Canonical n'ouvre pas le chemin de mise à niveau LTS vers LTS le jour de la sortie, mais à la première version corrective. Selon le calendrier officiel, cette version — 26.04.1 — est fixée au 27 août 2026.

Pourquoi cette attente existe

Ces quatre mois appartiennent au chemin de mise à niveau lui-même. Les blocages découverts après la sortie de 26.04 — conflits de dépendances, échecs de migration de fichiers de configuration, régressions de pilotes — sont corrigés puis intégrés aux images et à l'outil de mise à niveau de 26.04.1. Attendre la .1 n'est pas de la prudence : c'est le premier jour où ce chemin a réellement été testé.

Le calendrier mérite aussi un calcul honnête. La maintenance de sécurité standard de 24.04 LTS court jusqu'en mai 2029 : rien d'urgent. 26.04 LTS bénéficie d'une maintenance standard jusqu'en mai 2031 et d'une maintenance de sécurité étendue (ESM) jusqu'en mai 2036. Si vous êtes encore sous 22.04, la situation s'inverse : son support standard s'arrête en avril 2027, et il n'existe pas de saut direct vers 26.04 — il faut passer de 22.04 à 24.04, puis de 24.04 à 26.04, soit deux mises à niveau à planifier.

Cinq points qui comptent sur un VPS

  • Prenez un instantané réellement restaurable : si la mise à niveau échoue à mi-parcours, restaurer la machine entière est bien plus rapide que réparer les paquets à la main. Pas de fonction d'instantané ? Faites une sauvegarde complète et vérifiez la restauration — une sauvegarde non testée n'est pas une sauvegarde.
  • Gardez une porte de secours en SSH : do-release-upgrade démarre un second sshd sur le port 1022 au cas où la connexion principale tomberait. Ouvrez ce port dans votre pare-feu et votre groupe de sécurité au préalable, sinon une déconnexion vous enferme dehors. Lancez l'ensemble dans tmux ou screen pour qu'une coupure réseau ne tue pas le processus.
  • Traitez d'abord les dépôts tiers : l'outil désactive la plupart des PPA et sources apt externes, mais les dépôts que vous avez ajoutés pour Docker, Node, PHP ou une base de données méritent une vérification préalable de l'existence d'une branche 26.04, sans quoi vous terminerez avec des paquets figés sur l'ancienne version.
  • Repérez les sauts de version majeure à l'avance : franchir deux LTS peut faire changer de version majeure PHP, MySQL/MariaDB, Python et Node. Répétez la même pile sur une instance jetable facturée à l'heure, collectez la liste des erreurs, et seulement ensuite touchez à la production.
  • Évitez les heures de pointe : les invites de conflit de configuration (conserver la version locale ou prendre celle du mainteneur) demandent un jugement humain, en particulier pour nginx, sshd et postfix. À la fin, redémarrez et validez chaque service individuellement plutôt que d'accepter « la machine est revenue » comme preuve.

Il existe une option -d — ne l'utilisez pas en production

Un administrateur peut forcer une mise à niveau anticipée avec do-release-upgrade -d. Cette voie existe pour les tests, et Canonical ne la recommande pas pour les systèmes de production. Puisque le chemin normal s'ouvre de toute façon le 27 août, le risque n'a guère d'intérêt.

Traitez la mise à niveau comme un exercice

Une mise à niveau LTS vers LTS n'arrive qu'une fois tous les deux ans, et c'est précisément cette rareté qui fait échouer la première tentative. L'approche raisonnable consiste à tout exécuter d'abord sur une petite instance bon marché : même pile, même commande, notes sur chaque point exigeant une décision humaine — puis à répéter en production. SharkCloud dispose de nœuds au Japon, à Singapour, à Hong Kong et aux États-Unis, et le coût d'une instance temporaire pour la répétition reste bien inférieur à celui d'une machine de production bloquée en pleine mise à niveau.