Supprimer manuellement un paquet cassé de dpkg
Cet article a été publié il y a 7 ans 8 mois 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.Il arrive parfois qu’on fasse des trucs bêtes. En l’occurrence, c’est Arowan qui m’a appelé à l’aide après avoir essayé d’utiliser Docker sur son OpenMediaVault basé sur Debian Wheezy, et qui refuse de se désinstaller. Problème, ça bloque aussi les installations de nouveaux paquets. A situation désespérée, méthode de furieux. Voyons donc comment procéder.
Le symptôme
C’est pourtant simple au départ de supprimer un paquet :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
root@openmediavault:~# apt-get remove docker-engine Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : init-system-helpers libapparmor1 Veuillez utiliser « apt-get autoremove » pour les supprimer. Les paquets suivants seront ENLEVÉS : docker-engine 0 mis à jour, 0 nouvellement installés, 1 à enlever et 0 non mis à jour. 1 partiellement installés ou enlevés. Après cette opération, 101 Mo d'espace disque seront libérés. Souhaitez-vous continuer [O/n] ? O dpkg: erreur de traitement de docker-engine (--remove) : Le paquet est dans un état incohérent - vous devriez le réinstaller avant d'essayer de le supprimer. Des erreurs ont été rencontrées pendant l'exécution : docker-engine Creating index of upgradeable packages ... Creating index of openmediavault plugins ... E: Sub-process /usr/bin/dpkg returned an error code (1) |
Magnifiquement parlant. Ok, c’est pas grave, on tente de réinstaller :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
root@openmediavault:~# apt-get install docker-engine Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Paquets recommandés : aufs-tools cgroupfs-mount cgroup-lite Les paquets suivants seront mis à jour : docker-engine 1 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. 1 partiellement installés ou enlevés. Il est nécessaire de prendre 0 o/28,1 Mo dans les archives. Après cette opération, 116 ko d'espace disque supplémentaires seront utilisés. Sélection du paquet docker-engine précédemment désélectionné. (Lecture de la base de données... 46825 fichiers et répertoires déjà installés.) Préparation du remplacement de docker-engine 1.12.0-0~wheezy (en utilisant .../docker-engine_1.12.1-0~wheezy_amd64.deb) ... Stopping Docker: dockerstart-stop-daemon: warning: failed to kill 11815: No such process No process in pidfile '/var/run/docker-ssd.pid' found running; none killed. invoke-rc.d: initscript docker, action "stop" failed. dpkg : avertissement : le sous-processus ancien script pre-removal a retourné une erreur de sortie d'état 1 dpkg: tentative d'exécution du script du nouveau paquet à la place... Stopping Docker: dockerstart-stop-daemon: warning: failed to kill 11815: No such process No process in pidfile '/var/run/docker-ssd.pid' found running; none killed. invoke-rc.d: initscript docker, action "stop" failed. dpkg: erreur de traitement de /var/cache/apt/archives/docker-engine_1.12.1-0~wheezy_amd64.deb (--unpack) : le sous-processus nouveau script pre-removal a retourné une erreur de sortie d'état 1 dpkg : erreur lors du nettoyage : le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1 Des erreurs ont été rencontrées pendant l'exécution : /var/cache/apt/archives/docker-engine_1.12.1-0~wheezy_amd64.deb Creating index of upgradeable packages ... Creating index of openmediavault plugins ... E: Sub-process /usr/bin/dpkg returned an error code (1) |
C’est pas beau, mais il y a un peu plus d’informations. Apparemment le problème vient du fait qu’il s’est mal coupé.
Le début d’une investigation longue
J’ai tenté de virer les fichiers/dossiers /var/run/docker*, rien y fait, il continue d’échouer sur l’absence de processus (et ce même s’il n’y a aucun fichier pid). En fait le script tente systématiquement de couper le service, sans même vérifier s’il est déjà présent. C’est pénible, et très con.
Mais pourquoi ça pose problème d’ailleurs ?
|
1 2 3 4 |
root@openmediavault:~# service docker start Starting Docker: docker. root@openmediavault:~# ps aux |grep docker root 3156 0.0 0.0 7856 868 pts/1 S+ 13:22 0:00 grep docker |
Ah, en effet, si ça démarre pas, on est pas rendu. Alors, comment le lance-t-il ? Le mode debug de bash est très utile :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
root@openmediavault:~# bash -x /etc/init.d/docker start set -e + export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin + BASE=docker + DOCKERD=/usr/bin/dockerd + DOCKER_PIDFILE=/var/run/docker.pid + DOCKER_SSD_PIDFILE=/var/run/docker-ssd.pid + DOCKER_LOGFILE=/var/log/docker.log (...) Starting Docker: docker+ log_begin_msg_post 'Starting Docker: docker' + : + start-stop-daemon --start --background --no-close --exec /usr/bin/dockerd --pidfile /var/run/docker-ssd.pid --make-pidfile -- -p /var/run/docker.pid + log_end_msg 0 + '[' -z 0 ']' + local retval + retval=0 (...) |
Bien, on récupère donc la ligne de démarrage, et on la lance directement dans le shell :
|
1 2 3 4 5 6 |
root@openmediavault:~# start-stop-daemon --start --background --no-close --exec /usr/bin/dockerd --pidfile /var/run/docker-ssd.pid --make-pidfile -- -p /var/run/docker.pid root@openmediavault:~# INFO[0000] libcontainerd: new containerd process, pid: 3341 WARN[0000] containerd: low RLIMIT_NOFILE changing to max current=1024 max=4096 FATA[0001] Your Linux kernel version 3.2.0-4-amd64 is not supported for running docker. Please upgrade your kernel to 3.10.0 or newer. root@openmediavault:~# |
Ok, cool, mais alors pourquoi tu t’es installé au départ CONNARD ?
Restaurons notre calme. J’aurai pu vous montrer la sortie du fichier /var/log/docker.log, qui contient les mêmes messages, mais ça permet au passage de rappeler l’existence du mode debug de bash, très utile.
Donc, j’ai essayé de contourner en plaçant un fichier pid bidon dans lequel j’ai mis celui d’un vi vide ouvert en parallèle. Nib. J’ai cherché un millions de fois comment utiliser certaines options –force-* de dpkg, sans succès, avec souvent pour seul retour :
|
1 2 3 4 5 6 7 8 |
Utiliser « dpkg --help » pour une obtenir une aide sur l'installation et la désinstallation des paquets [*] ; Utiliser « dselect » ou « aptitude » pour gérer les paquets de manière plus conviviale ; Utiliser « dpkg -Dhelp » pour obtenir une liste des valeurs drapeaux de débogage ; Utiliser « dpkg --force-help » pour consulter la liste des options de forçage ; Utiliser « dpkg-deb --help » pour obtenir une aide sur la manipulation des fichiers *.deb ; Les options marquées d'un [*] affichent beaucoup d'informations - tubez-les à travers « less » ou « more ». |
Un bon gros RTFM dans ta gueule, merci les barbus intégristes, heureusement que je ne suis pas si susceptible.
Arme nucléaire : nettoyage manuel
Au bout de trois heures de manipulations et d’innombrables recherches infructueuses dans plusieurs langues, j’ai opté pour l’option violente, mais néanmoins efficace : la suppression à la main de tous les fichiers du paquet.
On récupère la liste des fichiers avec dpkg -L docker-engine (extrait) :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
/. /usr /usr/lib /usr/lib/docker /usr/bin /usr/bin/docker-containerd-ctr /usr/bin/docker /usr/bin/docker-containerd /usr/bin/dockerd /usr/bin/docker-proxy /usr/bin/docker-runc /usr/bin/docker-containerd-shim /usr/share /usr/share/docker-engine /usr/share/docker-engine/contrib /usr/share/docker-engine/contrib/mkimage-archarm-pacman.conf /usr/share/docker-engine/contrib/mkimage-alpine.sh /usr/share/docker-engine/contrib/nuke-graph-directory.sh /usr/share/docker-engine/contrib/mkimage-arch.sh /usr/share/docker-engine/contrib/mkimage-yum.sh |
Évidemment, je vous recommande d’éviter de supprimer les dossier /usr/bin, /usr/share, /usr/lib, mais j’imagine quand même que vous avez assez du jugeote pour éviter de tout flinguer. Il faut ensuite se pencher sur dpkg.
On supprime tous les fichiers /var/lib/dkpg/info/docker-engine.*. Enfin, on fait une sauvegarde du fichier /var/lib/dpkg/status et on l’édite pour supprimer le paragraphe ayant trait à docker-engine.
Par sécurité, j’ai ensuite faire un apt-get update pour « rafraichir » le tout. Ensuite, j’ai installé vim pour tester le résultat (parce qu’il manquait de toute façon), et paf, ça fait des Chocapic, autrement dit ça fonctionne.
Parfois, une réinstallation suffit
C’est vraiment le cas extrême ici, souvent il suffit de réinstaller le paquet (ou de faire install -f) pour récupérer un gestionnaire de paquets dans un état consistent/stable/fonctionnel, voire de pointer rapidement le problème et le corriger. Raison pour laquelle c’est la première chose qu’ils conseillent, et que j’ai essayé. Mais que voulez-vous, les développeurs sont des grosses buses parfois, et je souhaite bien du courage au prochain qui devra rattraper une telle merde. Au moins vous avez quelques armes en plus.
Le coup du start-stop-daemon c’est tellement pratique avec sysvinit, par contre il est nettement moins loquace avec systemd, c’est regrettable.
En tout cas j’ai beaucoup apprécié le ton « piquant » de cet article. 🙂
Salut,
Nouveau dans le monde de debian même distrib et même problème avec ce satané plugin docker.
c’est vraiment trop technique et tu m’as perdu quand il faut supprimer les fichiers ! je suis vraiment débutant et je ne comprend pas trop ce qu’il faut que je supprime, je préfère demander que tout flinguer !
Merci d’avance
Eh bien comme je l’ai indiqué, tu commences par extraire la liste des fichiers qui est installée par le paquet. Il faut ensuite supprimer les parties pertinentes : /var/lib/docker /usr/lib/docker /usr/share/docker-engine /etc/init.d/docker /var/lib/dpkg/info/docker-engine.* Ensuite c’est le fichier /var/lib/dkpg/status qui est important. Pour être honnête quand je suis intervenu dessus c’était la première fois que je l’ouvrais. C’est pour ça que je recommande une sauvegarde avant de le modifier. Ensuite, sa lecture te permettra de comprendre les « paragraphes » décrivant chaque paquet installé sur le système, et donc quelles ligne tu dois supprimer. C’est vraiment ce fichier qui permet de définir la… Lire la suite »
Merci pour ces réponses.
je débute et tout cela me semble assez risqué.
je vais essayer de migrer sur la nouvelle version de OMV ce sera peut être plus simple et ça résoudra peut être mon problème.
Merci en tout cas