Un système Kali qui refuse de terminer une mise à jour ou qui plante au boot après un apt upgrade interrompu n’est pas un système à réinstaller. Dans la grande majorité des cas, l’état dpkg est récupérable si l’on suit une séquence de diagnostic précise avant de toucher aux paquets.
Diagnostic dpkg : identifier l’état réel des paquets avant toute correction
La première commande à exécuter n’est pas apt --fix-broken install. Nous recommandons de commencer par un audit de l’état dpkg pour distinguer les paquets half-configured, half-installed et ceux marqués reinstreq.
dpkg --audit liste les paquets dans un état incohérent. dpkg -l | grep -E "^(iF|iU|rc)" complète le tableau en révélant les paquets dont la configuration a échoué ou dont les fichiers de contrôle sont absents.
Cette étape change la stratégie de réparation. Un paquet half-configured se résout souvent par dpkg --configure -a. Un paquet marqué reinstreq nécessite une purge ciblée puis une réinstallation. Traiter ces deux cas avec la même commande est la source de la majorité des boucles de dépendances que nous observons sur les retours terrain.
Vérifiez aussi le contenu de /var/lib/dpkg/info/ : si des fichiers .postinst ou .prerm sont absents pour un paquet signalé, dpkg ne pourra pas le reconfigurer. La solution est alors de récupérer ces scripts depuis le .deb original avec dpkg-deb --control avant de relancer la configuration.
Séquence de réparation apt et dpkg sur Kali
Une fois l’audit terminé, la séquence de réparation dite « safe first » s’applique dans cet ordre strict :
sudo dpkg --configure -apour finaliser la configuration des paquets en attente. Cette commande ne touche à rien si tout est propre, elle est donc sans risque.sudo apt --fix-broken installpour résoudre les dépendances non satisfaites. APT va tenter de télécharger les paquets manquants ou de retirer ceux qui bloquent.sudo apt cleansuivi desudo apt updatepour purger le cache local et recharger les métadonnées des dépôts. Un cache corrompu provoque des erreurs de hash qui miment un problème de dépendance.sudo apt autoremoveen dernier pour supprimer les paquets orphelins, seulement quand le système est stabilisé.
Inverser cet ordre (faire un apt clean avant dpkg --configure -a) est une erreur fréquente. Le nettoyage du cache supprime les .deb dont dpkg pourrait avoir besoin pour terminer une installation interrompue.
Débloquer le verrou dpkg
Si une commande apt précédente a été interrompue brutalement, le fichier /var/lib/dpkg/lock-frontend peut rester verrouillé. Avant de supprimer ce fichier, vérifiez qu’aucun processus apt ou dpkg ne tourne avec ps aux | grep -E "apt|dpkg". Une suppression du lock pendant qu’un processus écrit dans la base dpkg corrompra l’installation de façon irréversible.
Sources.list Kali : quand le dépôt est la cause réelle du problème
Un /etc/apt/sources.list mal configuré est responsable d’une part significative des installations « cassées » qui ne sont pas de vrais problèmes dpkg. Kali utilise le dépôt kali-rolling comme branche principale. Mélanger kali-rolling avec des dépôts Debian stable ou testing provoque des conflits de versions silencieux.
Ouvrez le fichier avec sudo nano /etc/apt/sources.list et vérifiez que la seule ligne active pointe vers http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware. Tout dépôt tiers (PPA Ubuntu, dépôt Debian sid, miroir non officiel) doit être commenté ou supprimé avant de relancer la séquence de réparation.
Le tracker de paquets Kali permet de vérifier si un paquet spécifique a été importé récemment dans kali-rolling. Si votre version installée est plus récente que celle du dépôt (cas fréquent après ajout temporaire d’un dépôt tiers), apt tentera de downgrader le paquet, ce qui génère un conflit de dépendances apparent.
Purger un paquet tiers bloquant
Quand un paquet provenant d’un dépôt externe bloque la résolution, apt-cache policy nom-du-paquet affiche l’origine de chaque version disponible. Identifiez la version problématique, purgez-la avec sudo dpkg --purge --force-depends nom-du-paquet, puis relancez sudo apt --fix-broken install pour que les dépendances se recalculent sur la version du dépôt officiel.
Conflits de paquets invités VirtualBox sur Kali Linux
Les outils invités VirtualBox restent un cas terrain récurrent de casse système sur Kali. L’installation des Guest Additions via le CD virtuel entre en conflit avec les paquets virtualbox-guest-* fournis par les dépôts Kali. Le résultat : des modules noyau incompatibles, un serveur X qui ne démarre plus, et un dpkg --audit qui signale plusieurs paquets en état incohérent.
La procédure de récupération passe d’abord par l’arrêt des services concernés :
sudo systemctl stop vboxadd-serviceetsudo systemctl stop vboxaddpour couper les modules invités actifs.sudo dpkg --purge virtualbox-guest-x11 virtualbox-guest-utils virtualbox-guest-dkmspour retirer proprement les paquets du dépôt.- Si les Guest Additions du CD ont été installées manuellement, exécutez
sudo /opt/VBoxGuestAdditions-*/uninstall.shavant de réinstaller les paquets officiels.
Ne jamais mélanger les deux sources d’installation (CD VirtualBox et dépôt Kali) pour les outils invités. Choisir l’une ou l’autre, exclusivement.
Mode recovery Kali : accéder au système quand le boot échoue
Si le système ne démarre plus du tout, GRUB permet d’accéder à un shell root minimal. Au menu GRUB, sélectionnez l’entrée « Advanced options for Kali » puis le noyau avec la mention « (recovery mode) ». Vous obtenez un shell root avec le système de fichiers monté en lecture seule.
Remontez la partition en écriture avec mount -o remount,rw /, puis lancez la séquence dpkg --configure -a et apt --fix-broken install. Si le réseau n’est pas disponible en mode recovery, dhclient eth0 ou ip link set eth0 up && dhclient eth0 rétablit la connectivité pour télécharger les paquets manquants.
Un système Kali qui semble irrécupérable au premier abord répond dans la plupart des cas à cette approche séquentielle. L’audit dpkg avant toute action corrective reste le réflexe qui sépare une réparation propre d’une cascade d’erreurs supplémentaires. Gardez en tête que chaque commande de forçage (--force-depends, --force-overwrite) introduit une dette technique : elle doit rester un dernier recours, pas un réflexe.
