Mise à niveau Ubuntu interrompue : comment récupérer

Mise à niveau Ubuntu interrompue : commencez par identifier le symptôme

Une mise à niveau de version Ubuntu échouée de 24.04 vers 26.04 laisse le serveur dans l’un de quatre états, et chacun nécessite une correction différente. Le processus de mise à niveau peut encore s’exécuter dans une session screen dont vous avez perdu le contact. dpkg peut avoir été interrompu alors qu’un paquet était partiellement configuré, et apt refuse alors toutes les commandes. Les sources apt peuvent indiquer 26.04 alors que les paquets installés sont encore ceux de 24.04. Enfin, le serveur peut ne plus démarrer du tout. Déterminez lequel de ces cas vous concerne avant de saisir quoi que ce soit, car la correction adaptée à un état peut aggraver un autre état.

Une règle s’applique aux quatre cas. Ne redémarrez pas tant que vous ne savez pas dans quel état se trouve dpkg. Un redémarrage au milieu du remplacement de paquets peut transformer une interruption dpkg récupérable en serveur qui ne démarre plus, comme décrit vers la fin de ce guide. Ne lancez pas non plus un deuxième processus apt ou dpkg tant que le premier pourrait encore être actif, car deux processus qui écrivent simultanément dans la base de données des paquets peuvent la corrompre.

Ce guide suppose que vous avez suivi le guide de mise à niveau de 24.04 vers 26.04 et créé un snapshot avant de commencer. Si ce n’est pas le cas, tenez-en compte dans la section consacrée au démarrage : le snapshot permet de résoudre le cas le plus grave.

La mise à niveau est-elle toujours en cours ?

De nombreuses mises à niveau signalées comme ayant échoué sont toujours en cours. La session SSH a été interrompue, le terminal est devenu vide, mais le programme de mise à niveau a continué sans vous.

do-release-upgrade est conçu pour cela. Lorsqu’il s’exécute avec son interface texte, comme c’est le cas sur un serveur, il s’exécute dans une session GNU screen. La mise à niveau survit ainsi à la perte du terminal qui l’a lancée. Par ailleurs, lorsqu’il détecte qu’il a été lancé depuis une session SSH, il propose de démarrer un second sshd sur un autre port (1022 par défaut). Vous pouvez ainsi toujours vous connecter si le daemon SSH principal tombe en panne pendant le remplacement des paquets. Ces deux points sont importants maintenant.

Reconnectez-vous en SSH et recherchez la session screen. Le programme de mise à niveau s’exécutait sous sudo. Sa session screen appartient donc à root, et un simple screen -ls exécuté avec votre propre utilisateur ne l’affichera pas.

sudo screen -ls

screen -ls indique si chaque session est attachée ou détachée. Si une session est listée, rattachez-vous-y. Si elle est toujours marquée comme attachée parce que la connexion SSH interrompue ne l’a jamais libérée, -d détache d’abord cette ancienne connexion.

sudo screen -d -r

Si plusieurs sessions sont listées, placez le nom de session indiqué par screen -ls après -r. Relancer sudo do-release-upgrade fonctionne également : le programme de mise à niveau recherche sa session screen existante et s’y rattache au lieu de lancer une nouvelle exécution. Dans les deux cas, vous revenez à la mise à niveau en cours. Elle attend généralement une réponse concernant un fichier de configuration modifié ou le redémarrage d’un service. Répondez, puis laissez-la se terminer.

Si vous avez lancé la mise à niveau dans tmux, comme le recommande le guide de mise à niveau, rattachez-vous d’abord à tmux avec tmux attach. La session screen s’exécute dans cette fenêtre tmux. La mise à niveau s’affiche donc directement. Si la fenêtre affiche uniquement une invite shell, le programme de mise à niveau ne s’y exécute plus. sudo screen -ls est alors la vérification suivante.

Si le port SSH principal refuse la connexion, essayez le port de secours : ssh -p 1022 user@host. Ce daemon n’existe que pendant la mise à niveau. Si vous ne pouvez vous connecter sur aucun des deux ports, utilisez plutôt la console de votre fournisseur. Depuis la console, sudo ss -ltnp indique sur quels ports un processus sshd est en écoute. sudo ufw status indique si le pare-feu autorise le passage du port de secours.

Lorsqu’aucune session screen n’existe et que rien n’attend sur la console, la mise à niveau s’est réellement arrêtée. Vérifiez qu’aucun processus ne travaille encore sur la base de données des paquets avant d’intervenir :

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Un résultat vide signifie que dpkg est inactif et que vous pouvez passer à sa réparation. Un processus dpkg ou apt dont le temps d’exécution est long, sans session screen à laquelle se rattacher, est bloqué. Attendez quelques minutes, vérifiez si une question debconf sans réponse s’affiche sur la console, puis tuez le processus seulement à ce moment-là. Ne supprimez jamais les fichiers de verrouillage sous /var/lib/dpkg/ ou /var/lib/apt/lists/ lorsqu’un processus les détient. Le verrou est le seul élément qui empêche deux processus d’écriture de corrompre la base de données des paquets.

dpkg a été interrompu et apt refuse de s’exécuter

Lorsque dpkg est arrêté entre le dépaquetage d’un paquet et l’exécution de son script de configuration, il enregistre cet état incomplet dans /var/lib/dpkg/status. Toutes les commandes apt suivantes lisent cet état et s’arrêtent, car apt ne peut pas s’appuyer sur une base de données contenant des opérations inachevées. Quel que soit le message affiché par apt lorsqu’il refuse de continuer, la première étape est la même.

sudo dpkg --configure -a

Cette commande termine la configuration de tous les paquets qui ont été dépaquetés mais jamais configurés. Elle exécute les maintainer scripts dans l’ordre des dépendances. Sur un système dont la mise à niveau est incomplète, cela peut prendre longtemps. Laissez-la s’exécuter jusqu’à son terme. Si elle s’arrête sur un paquet, elle affiche le nom du paquet et le script qui a échoué. Notez ce nom. C’est le paquet qui a interrompu la mise à niveau. La section suivante explique comment lire son erreur.

Laissez ensuite apt réparer les dépendances que l’interruption a laissées non satisfaites, car certains paquets ont été mis à niveau alors que les paquets dont ils dépendent ne l’ont pas été.

sudo apt --fix-broken install

Terminez ensuite la mise à niveau que l’outil de mise à niveau avait commencée :

sudo apt update
sudo apt full-upgrade

Utilisez full-upgrade plutôt que upgrade, car une mise à niveau de version supprime des paquets, tandis que upgrade refuse d’en supprimer. Lisez le récapitulatif affiché par apt avant de confirmer. Une courte liste de suppressions est normale. En revanche, une liste qui supprime ubuntu-server, systemd, openssh-server ou votre paquet de noyau ne l’est pas. Répondez non et cherchez pourquoi apt veut effectuer ces suppressions avant de continuer.

Vérifiez le résultat avant toute autre opération :

sudo dpkg --audit
sudo apt-get check

dpkg --audit liste tous les paquets dont l’état est encore incorrect, et apt-get check signale les dépendances non satisfaites. Les deux commandes doivent rester silencieuses. Si c’est le cas, exécutez sudo apt autoremove pour supprimer les paquets 24.04 dont plus rien ne dépend. Confirmez ensuite la version avec cat /etc/os-release, puis exécutez sudo update-initramfs -u -k all et sudo update-grub. Redémarrez seulement après ces étapes.

Comment lire /var/log/dist-upgrade pour trouver le paquet qui a interrompu la mise à niveau

L’outil de mise à niveau écrit toutes ses informations dans /var/log/dist-upgrade/. Si vous l’avez exécuté plusieurs fois, il déplace les journaux des tentatives précédentes dans un sous-répertoire dont le nom contient un horodatage. Consultez donc d’abord ls -la /var/log/dist-upgrade/ et lisez le répertoire correspondant à l’exécution qui a échoué.

main.log est le journal détaillé de l’outil de mise à niveau. Il indique dans quelle phase l’exécution se trouvait et les décisions prises concernant vos sources de paquets. Si l’outil de mise à niveau lui-même a planté, la trace Python s’y trouve également. Lisez ce fichier en partant de la fin : les dernières lignes indiquent la phase dans laquelle il s’est arrêté. La présence d’une trace à cet endroit signifie que l’outil a échoué, et non un paquet.

apt.log contient le raisonnement du résolveur de dépendances. Il est verbeux. Il est utile lorsqu’apt a refusé de calculer la mise à niveau, avant même qu’un paquet ait été modifié. Si la mise à niveau est allée jusqu’à l’installation de paquets, vous pouvez généralement l’ignorer.

apt-term.log est le fichier à consulter en cas d’échec lié à un paquet. Il contient la sortie du terminal de dpkg pendant la mise à niveau, c’est-à-dire le même texte qui aurait défilé à l’écran. Le dernier paquet mentionné avant la fin est celui que dpkg traitait lorsque la mise à niveau s’est arrêtée. Si un maintainer script a échoué, le message d’erreur de dpkg se trouve à cet endroit, juste au-dessus de l’erreur générée par le script.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Vérifiez ces informations dans /var/log/dpkg.log, qui enregistre chaque changement d’état effectué par dpkg avec un horodatage. tail -n 30 /var/log/dpkg.log indique le dernier paquet traité par dpkg et l’opération effectuée. Vous obtenez ainsi la même réponse à partir d’une seconde source.

À ce stade, la plupart des échecs sur un serveur ont l’une de quelques causes courantes. Un service redémarré par le postinst du paquet ne démarre pas à cause d’un fichier de configuration que vous avez personnalisé. Les commandes systemctl status et journalctl -xeu exécutées pour ce service indiquent alors la ligne qu’il refuse. Un système de fichiers est plein, le plus souvent /boot à cause d’anciens noyaux ou /var à cause du cache de paquets d’apt. df -h / /boot /var permet de le vérifier. sudo apt clean vide le cache même lorsqu’apt est autrement bloqué. Un disque indiqué comme plein alors que du ne le montre pas obéit à une autre explication. Un paquet provenant d’un dépôt tiers désactivé par l’outil de mise à niveau dépend d’une bibliothèque que 26.04 ne fournit plus. Un paquet bloqué (apt-mark showhold) a empêché une dépendance d’évoluer. Corrigez la cause, puis exécutez de nouveau sudo dpkg --configure -a. La commande reprend là où elle s’était arrêtée.

Si un paquet refuse de se configurer quoi que vous fassiez et qu’aucun élément important n’en dépend, supprimez-le puis réinstallez-le une fois la mise à niveau terminée :

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Utilisez cette commande uniquement pour un paquet dont vous pouvez expliquer le rôle et nommer la cause du problème. Ne l’utilisez jamais pour une bibliothèque ni pour un élément de la chaîne de dépendances ubuntu-server, car une suppression forcée ignore les contrôles qui vous indiqueraient ce qui risque de ne plus fonctionner.

Les sources ont été modifiées, mais pas les paquets

Le programme de mise à niveau réécrit vos sources APT au début de l’opération, avant de télécharger les paquets. S’il est interrompu après cette étape, les sources indiquent 26.04 alors que les paquets installés sont mélangés. Cette incohérence perturbe les outils. C’est pourquoi do-release-upgrade peut maintenant indiquer qu’aucune nouvelle version n’est disponible.

Comparez les deux emplacements qui indiquent la version utilisée. /etc/apt/sources.list.d/ubuntu.sources est le fichier de sources au format deb822 introduit par 24.04. Ses lignes Suites: contiennent le nom de code de la version. /etc/os-release est généré par le paquet base-files et indique la version réellement installée.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Trois combinaisons sont importantes. Si les sources indiquent toujours 24.04 (nom de code noble) et que os-release indique également 24.04, la mise à niveau n’a pas dépassé ses vérifications. Vous pouvez relancer sudo do-release-upgrade après avoir consulté main.log pour comprendre pourquoi elle s’est arrêtée. Si les sources indiquent le nom de code de 26.04 alors que os-release indique encore 24.04, le remplacement des paquets a commencé puis a été interrompu. La réparation de dpkg décrite dans la section précédente, qui se termine par apt full-upgrade, permet de terminer l’opération. Si les sources indiquent 26.04 et que os-release indique 26.04, base-files fait partie des paquets qui ont été installés. Le système se déclare alors en 26.04, même si la plupart de ses paquets ne le sont pas.

Cette dernière combinaison est le piège. do-release-upgrade détermine la version utilisée à partir des mêmes informations que celles contenues dans os-release. Si celles-ci indiquent déjà 26.04, l’outil recherche une version plus récente que 26.04, n’en trouve aucune et indique qu’aucune nouvelle version n’est disponible. L’outil répond à une question concernant os-release, mais os-release contient une information incorrecte. N’utilisez plus le programme de mise à niveau. Terminez l’opération avec APT : sudo apt update, puis sudo apt full-upgrade, qui met à niveau chaque paquet encore dans sa version 24.04, puis sudo apt autoremove. Les autres raisons pour lesquelles do-release-upgrade n’indique aucune nouvelle version, par exemple une invite LTS qui attend la première mise à jour intermédiaire, doivent être écartées si os-release indique encore 24.04.

Le programme de mise à niveau désactive également les sources tierces dans /etc/apt/sources.list.d/ et conserve une copie de sauvegarde de chaque fichier modifié, en ajoutant un suffixe au nom d’origine. Exécutez ls -la /etc/apt/sources.list.d/ et diff sur chaque fichier d’origine et sa sauvegarde pour voir exactement les modifications effectuées. Laissez les entrées tierces désactivées jusqu’à ce que les paquets Ubuntu soient cohérents. Réactivez ensuite chaque entrée uniquement après avoir vérifié que l’éditeur fournit des paquets pour 26.04. Si apt update signale qu’une source est configurée plusieurs fois, une ancienne entrée sources.list et la nouvelle entrée ubuntu.sources décrivent la même suite. L’erreur de source dupliquée au format deb822 indique laquelle supprimer.

Le serveur ne redémarre pas après la mise à niveau

Un redémarrage révèle généralement le coût d’une mise à niveau incomplète. Sur un VPS, les causes probables sont un kernel installé sans son initramfs, une configuration GRUB qui n’a jamais été régénérée, un paquet resté partiellement configuré dont dépend une unité au démarrage, ou un disque arrivé à saturation pendant que dpkg écrivait.

Ouvrez la console du fournisseur avant toute autre intervention. Elle indique où le démarrage s’arrête : menu GRUB, kernel panic, vérification du système de fichiers en attente d’une réponse ou shell d’urgence systemd demandant le mot de passe root. Cette observation détermine l’étape suivante.

Si GRUB s’affiche, démarrez l’ancien kernel 24.04 depuis le sous-menu des options avancées. L’ancien kernel reste normalement installé jusqu’à l’exécution de autoremove. Une fois le système démarré avec l’ancien kernel, exécutez sudo dpkg --configure -a et le reste de la procédure de réparation de la section précédente, puis sudo update-initramfs -u -k all et sudo update-grub avant de réessayer le nouveau kernel. Récupérer un VPS qui ne redémarre pas après une mise à jour du kernel détaille la partie consacrée à GRUB et à l’initramfs.

Si vous arrivez dans un shell d’urgence, le système de fichiers root est généralement monté en lecture seule. Remontez-le, puis exécutez la même procédure de réparation :

mount -o remount,rw /
dpkg --configure -a

Si le système n’atteint aucun shell, démarrez l’image de rescue de votre fournisseur, montez le disque du VPS et effectuez la réparation depuis un chroot. Trouvez la partition root avec lsblk au lieu d’en deviner le nom.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Avant de passer une heure dans ce chroot, comparez cette approche à la restauration du snapshot. Vous en avez créé un avant de commencer, et sa restauration ne prend que quelques minutes chez la plupart des fournisseurs. Vous relancez ensuite la mise à niveau, qui prend largement moins d’une heure sur un VPS, et vous savez cette fois quel paquet corriger. La restauration est la méthode la plus rapide dans les cas suivants : vous n’avez accès ni à une console ni à une image de rescue, vous ne pouvez pas identifier le paquet qui a interrompu la mise à niveau, plusieurs paquets sont bloqués, ou le serveur héberge un service dont des utilisateurs attendent le rétablissement. La correction manuelle est plus rapide uniquement lorsque vous savez précisément ce qui a cassé et que la correction tient en une seule commande.

Copiez /var/log/dist-upgrade/ hors du serveur avant de restaurer, depuis l’image de rescue si c’est le seul moyen d’y accéder. La restauration efface ces journaux, et une deuxième tentative échouera exactement de la même manière si vous n’avez pas compris la cause de la première. Ce qu’un snapshot peut et ne peut pas restaurer mérite d’être lu avant de vous y fier. Un snapshot rétablit l’intégralité du disque, y compris les données écrites depuis sa création. C’est acceptable au milieu d’une mise à niveau, mais pas une semaine plus tard.

Trois signes indiquent qu’il vaut mieux reconstruire le système

Certaines mises à niveau ne valent pas la peine d’être récupérées. Restaurer un snapshot et relancer l’opération coûte peu de temps. Mais si l’échec vient de l’état du serveur lui-même, la seconde tentative échouera également. La bonne solution consiste alors à utiliser une image 26.04 neuve et à restaurer vos données depuis une sauvegarde. Trois signes indiquent que vous en êtes là.

Premièrement, la base de données de dpkg est endommagée. Si dpkg --audit ou apt-get check ne parvient pas du tout à lire /var/lib/dpkg/status, au lieu de signaler des paquets défectueux à l’intérieur, l’inventaire des paquets installés est perdu. Ubuntu conserve des copies quotidiennes dans /var/backups/ (ls -la /var/backups/dpkg.status*), et remplacer le fichier actuel par la dernière copie valide fonctionne parfois. Mais dès que cette copie ne correspond plus à ce qui se trouve réellement sur le disque, vous ne faites plus que supposer, et chaque exécution ultérieure d’apt s’appuie sur ces suppositions.

Deuxièmement, les outils nécessaires pour réparer le système sont eux-mêmes défectueux. Si apt ou dpkg ne démarre pas parce qu’une bibliothèque partagée a été supprimée ou remplacée partiellement, ou si systemd ne peut pas démarrer les unités parce que son propre paquet est partiellement configuré, il ne reste plus de gestionnaire de paquets fonctionnel pour réparer le gestionnaire de paquets. ldd /usr/bin/apt indique si toutes les bibliothèques d’apt sont présentes. Il est parfois possible de sortir de cette situation depuis un chroot dans l’image de secours, mais cela prend généralement plus de temps qu’une reconstruction.

Troisièmement, la liste des paquets défectueux ne diminue pas. Si vous avez exécuté dpkg --configure -a et apt --fix-broken install en boucle pendant plus d’une heure, et que chaque passage révèle un nouveau paquet au lieu de corriger le précédent, le système a transporté dans la mise à niveau des problèmes qu’elle n’a pas créés : des fichiers sous /usr modifiés manuellement, des paquets épinglés ou retenus, un dépôt tiers ayant remplacé des bibliothèques essentielles, ou une mise à niveau précédente qui n’a jamais été terminée. Une image neuve ne contient pas ces problèmes, et restaurer vos données dessus prend moins de temps que de les rechercher.

Une reconstruction n’est économique que si les données se trouvent ailleurs que sur le serveur. C’est ce qui distingue un snapshot d’une sauvegarde, et la raison pour laquelle le guide de mise à niveau demande les deux.

FAQ

Puis-je simplement relancer do-release-upgrade après son interruption ?

Oui. C’est la meilleure première étape. Si l’outil de mise à niveau est toujours actif dans sa session screen, le relancer se rattache à cette session. Sinon, exécutez d’abord sudo dpkg --configure -a et sudo apt --fix-broken install, puis relancez l’outil. Il relit l’état actuel et reprend la mise à niveau. Le seul cas où cette méthode ne peut pas aider est celui où /etc/os-release indique déjà 26.04, car l’outil considère alors que la mise à niveau est terminée. Terminez plutôt avec sudo apt full-upgrade.

Pourquoi do-release-upgrade indique-t-il qu’aucune nouvelle version n’est disponible après l’échec de la mise à niveau ?

Parce que base-files, le paquet qui écrit /etc/os-release, faisait partie des paquets mis à niveau avant l’interruption. L’outil lit maintenant ce fichier, conclut que vous utilisez 26.04 et ne trouve aucune version plus récente à proposer. Comparez grep VERSION_ID /etc/os-release et grep Suites /etc/apt/sources.list.d/ubuntu.sources, puis terminez avec sudo apt update && sudo apt full-upgrade.

Est-il sûr de redémarrer un serveur Ubuntu dont la mise à niveau est incomplète ?

Pas avant que sudo dpkg --audit ne renvoie rien. Redémarrer avec un kernel décompressé mais non configuré, ou avec GRUB qui n’a pas été régénéré, est la cause la plus fréquente d’une situation où une mise à niveau réparable en dix minutes devient une intervention depuis une image de secours. Terminez la réparation de dpkg et apt full-upgrade, exécutez update-initramfs -u -k all et update-grub, puis redémarrez seulement après.

Comment trouver quel paquet a interrompu la mise à niveau ?

Lisez la fin de /var/log/dist-upgrade/apt-term.log, qui contient la sortie terminale de dpkg. Le dernier paquet mentionné avant la fin du journal est celui qui était en cours de traitement. Un script de maintenance en échec affiche son erreur juste au-dessus du message d’erreur de dpkg. tail -n 30 /var/log/dpkg.log le confirme depuis une seconde source. Si main.log se termine plutôt par une traceback Python, c’est l’outil de mise à niveau lui-même qui a planté. Aucun paquet n’est alors en cause.

Dois-je restaurer le snapshot ou continuer la réparation ?

Restaurez le snapshot si vous ne pouvez pas identifier le paquet en échec, si plusieurs paquets sont bloqués, si vous n’avez pas accès à la console ou si le serveur doit être rapidement de nouveau disponible. Continuez la réparation uniquement si vous savez précisément ce qui a échoué et si le correctif consiste en une seule commande. Copiez /var/log/dist-upgrade/ hors du serveur avant la restauration. Sinon, la deuxième tentative échouera de la même manière.