DNF sous Fedora : retrouver la mise à jour qui a cassé un paquet

Une mise à jour Fedora peut casser un paquet, un service ou une dépendance sans que tout le système soit inutilisable. Avant de supprimer des paquets au hasard, commencez par retrouver la transaction DNF qui a déclenché le problème. Vous pourrez ensuite tester un dnf history undo, avec une limite importante : ce n’est pas une machine à remonter le temps parfaite.

La méthode fonctionne surtout si l’historique DNF est encore disponible et si les anciennes versions des paquets existent toujours dans les dépôts configurés. La documentation officielle de DNF détaille les commandes et leurs options. Faites ces vérifications avec un compte administrateur, et évitez de lancer une nouvelle mise à jour avant d’avoir identifié la transaction fautive.

Retrouver la transaction qui pose problème

Commencez par afficher l’historique des opérations :

sudo dnf history

Chaque ligne correspond à une transaction avec un identifiant. Recherchez l’opération qui correspond à l’heure d’apparition du problème, puis affichez son détail :

sudo dnf history info ID

Remplacez ID par le numéro affiché par la première commande. Vous verrez les paquets installés, mis à jour ou supprimés. C’est ici qu’il faut vérifier que la transaction concerne bien le paquet ou la bibliothèque qui a déclenché la panne.

Vous pouvez aussi contrôler l’état actuel d’un paquet précis :

rpm -q nom-du-paquet
sudo dnf repoquery --installed nom-du-paquet

Si le paquet n’est plus installé, la seconde commande ne renverra rien. Ne confondez pas une dépendance retirée avec le paquet principal : la transaction complète est souvent plus instructive que le seul nom du logiciel qui ne démarre plus.

Tester un retour arrière avec DNF

Une fois l’identifiant confirmé, simulez d’abord l’opération :

sudo dnf history undo ID --assumeno

L’option --assumeno laisse DNF calculer les changements sans les appliquer. Lisez la liste des paquets qui seraient rétrogradés, installés ou supprimés. Si DNF propose de retirer un composant utilisé par plusieurs services, arrêtez-vous là et vérifiez les dépendances avant de confirmer.

Si la simulation reste cohérente, lancez le retour arrière :

sudo dnf history undo ID

Sur certaines versions de DNF, vous pouvez aussi rencontrer une commande de rollback. Elle vise plusieurs transactions et mérite encore plus de prudence :

sudo dnf history rollback ID

Ne l’utilisez pas pour revenir plusieurs jours en arrière sans avoir exporté la liste des transactions et vérifié les paquets concernés. Un rollback large peut toucher le noyau, les bibliothèques système ou des services qui ont été modifiés entre-temps.

Quand undo ne suffit pas

DNF ne peut pas restaurer une version absente des dépôts ou supprimée du cache local. Dans ce cas, la commande peut échouer avec une dépendance introuvable, ou proposer un résultat différent de celui attendu. Le retour arrière peut aussi être impossible si une autre mise à jour a déjà modifié la chaîne de dépendances.

Vous pouvez alors vérifier les versions disponibles :

sudo dnf list --showduplicates nom-du-paquet
sudo dnf repoquery --available --qf '%{name}-%{evr}.%{arch}' nom-du-paquet

Si l’ancienne version apparaît, une installation ciblée peut être envisagée, mais elle doit rester cohérente avec les dépendances :

sudo dnf install nom-du-paquet-version-release.arch

Ne forcez pas une version avec --allowerasing simplement pour faire disparaître un message d’erreur. Cette option peut supprimer des paquets et déplacer le problème vers un autre service.

Vérifier le système après l’opération

Après un undo ou une installation ciblée, contrôlez les paquets et relancez le service concerné :

sudo dnf check
sudo systemctl status nom-du-service --no-pager
sudo journalctl -u nom-du-service -b --no-pager

Si le souci touche le démarrage ou un service système, consultez aussi les messages du dernier boot avec journalctl sous Linux. Pour un problème de mémoire ou de dépendance provoqué par un paquet, évitez de conclure après un seul redémarrage : vérifiez le journal du service et reproduisez l’action qui posait problème.

Une mise à jour cassée ne se corrige donc pas toujours par un retour arrière. Retrouver la transaction, la simuler, vérifier les versions disponibles, puis contrôler les logs reste plus sûr que d’enchaîner les commandes DNF au hasard. Si le système est critique, faites d’abord une sauvegarde ou travaillez depuis un environnement de secours.