Bonjour.
Ca faisait longtemps, j’espère que ceux que je connais ici vont bien ?
J’ai voulu faire une mise à jour d’un serveur de buster en bookworm, et le dist-upgrade a planté pendant qu’il installait libgcc-s1:i386 (mon système est amd64, mais bon) sous prétexte que la libc6 n’est pas configurée.
Le dernier message lors de la mise à jour était:
(...)
Dépaquetage de libgcc-s1:i386 (12.2.0-14) ...
Remplacement de fichiers dans l'ancien paquet libgcc1:i386 (1:8.3.0-6) ...
dpkg: des problèmes de dépendances empêchent la configuration de libgcc-s1:amd64 :
libgcc-s1:amd64 dépend de libc6 (>= 2.35) ; cependant :
Le paquet libc6:amd64 n'est pas encore configuré.
dpkg: erreur de traitement du paquet libgcc-s1:amd64 (--configure) :
problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
libgcc-s1:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Depuis, plus possible de faire le moindre sudo ou de passer root en su, ni d’ouvrir une nouvelle connection ssh sur le serveur.
Coup de bol, j’avais une session ouverte en root dans un onglet pour essayer d’agir, mais quoi que je tente avec apt/dpkg, python refuse ce que je demande sous prétexte qu’il ne trouve pas libcrypt.so.1
Par exemple:
# dpkg-reconfigure libc6:amd64
/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
Je n’ose pas encore redémarrer dans cet état instable, auriez vous une idée d’un truc à tester avant cette solution de dernière espoir pour essayer de récupérer la situation ?
Bon, alors là, je me suis dit qu’en déployant la libcrypt.so.1 depuis le .deb que j’avais dans /var/cache/apt/archives, python remarcherait et que ça débloquerait peut être les choses, donc j’ai extrait le data.tar.xz du .deb, et je l’ai déployé à l’arrache dans mon arborescence, et maintenant, bah…
root@tarantino:~# apt --fix-broken install
bash: /usr/bin/apt: Aucun fichier ou dossier de ce type
root@tarantino:~# /bin/apt --fix-broken install
bash: /bin/apt: Aucun fichier ou dossier de ce type
C’est encore plus cassé…
[edit:je teste le reboot finalement et en coupant le courant vu que plus rien ne marche, donc bon]
Alors le reboot s’est mal passé (comme je m’y attendais) et j’en ai bavé pour obtenir un accés en KVM…
Là je viens juste de voir que la machine avait rebooté sur un kernel panic, donc je vais basculer sur un livecd ubuntu pour travailler le probléme en chroot.
En attendant, pour ce qui est de mes sources, j’ai remplacé buster par bookworm partout, ajouté les non-free-firmware, et j’ai désactivé les dépots backports que j’utilisais en buster.
Bon, j’ai aussi des sources sury, une archive pour des php anciens, le depot officiel mysql d’oracle, des dépots pour dépot jitsy et prosody, mais rien dans ces dépots annexes qui customise les paquets de coeur de distrib, et lors du dist-upgrade, tout ce que j’ai vu passer comme paquet venait du dépot debian bookworm, rien ne venait de ces dépots accessoires.
Je ne peux pas te lister le détail pour l’instant, vu que je n’ai pas encore accès à la machine, mais coté download des paquets et configuration de mes sources, rien n’a cloché.
Tu soupçonnes quoi dans les sources ?
Ca ne nous dit pas si tu as d’autres repo que les repo Debian only.
Déjà avec ça, cela veut dire que tu mixtes du i386 avec de l’amd64.
Toutg dépend donc comment tgyu as configuré ton sources.list, d’où ma demande que tu nous montres tes fichiers de conf.
Oui, mais ça n’est pas une erreur, j’ai eu besoin de multiarch avant (je crois que c’était nécessaire pour certaines fonctionnalités de jitsi), mais c’était déjà comme ça avant que je tente mon dist-upgrade, et ce n’est pas dans les sources.list que ça se configure.
Bon, @Zargos , c’est impossible pour moi de copier/coller le contenu de mes fichiers sources.list dans la console que j’ai reussi à ouvrir depuis un livecd, mais je t’avouerais que je ne vois pas bien ce que tu pourrais en faire pour règler le probléme de libc6 en capilotade, sachant que de toutes les manières je ne peux plus faire tourner apt…
Sinon juste pour info, j’ai monté mes disques et essayé de chrooter dessus, mais il ne veut même plus lancer un bash (ni rien d’autre d’ailleurs) dans le chroot:
Je crois que c’est mort, je vais tout remonter sur un autre serveur pour être sur d’avoir un truc qui marche, mais aprés j’essayerais de corriger en déployant un debootstrap sur ce serveur cassé, parce que j’aime pas abandonner.
En attendant, je suis preneur d’une idée plus prometteuse que d’aller regarder dans mes sources.list.
J’en suis même certain.
Faire un bon de buster à bookworm (N → N+2) à partir d’un état non strictement et purement buster non multi-arch n’a strictement aucune chance de succès pour espérer un système exploitable et durable.
Je ne serais pas aussi catégorique.
Oui, ça provoque presque toujours des zouilles de passer plusieurs étapes, mais une étape aussi, et sur mon vieux serveur à la maison qui fut installé en woody et est maintenant en bullseyes, j’ai même fait le saut de etch en jessie.
Bon, ça m’a pris un jour ou deux pour régler tous les soucis de dépendance, forcer des installs à coup de dpkg en contournant apt, mais tous les upgrades que j’ai fait jusqu’ici (toujours à l’arrache) ont presque toujours fini par passer.
J’ai eu une fois un plantage vraiment irréparable du même type que maintenant, et comme par hasard, c’était aussi un problème sur la libc6.
Bref, oui, c’est pas bien de sauter plusieurs versions, mais faut pas exagèrer, c’est robuste, apt.
Je sais, je sais, c’est trés imprudent, mais je m’y suis mis avant la fin de ma première cuve de café du matin…
Bah vu que rien ne passe dans le chroot, je l’ai fait depuis le livecd:
matt@redacted:~/chr/var$ ls -al ~/chr
total 77
drwxr-xr-x 19 root root 4096 juin 12 22:15 .
drwxr-xr-x 5 matt users 200 juin 12 21:33 ..
lrwxrwxrwx 1 root root 7 août 6 2020 bin -> usr/bin
drwxr-xr-x 4 root root 1024 juin 12 13:52 boot
drwxr-xr-x 19 root root 4160 juin 12 18:32 dev
drwxr-xr-x 133 root root 12288 juin 12 14:33 etc
drwxr-xr-x 4 root root 4096 sept. 24 2020 home
lrwxrwxrwx 1 root root 29 juin 12 13:47 initrd.img -> boot/initrd.img-6.1.0-9-amd64
lrwxrwxrwx 1 root root 39 juin 12 13:47 initrd.img.old -> boot/initrd.img-5.10.0-0.deb10.22-amd64
drwxr-xr-x 3 root root 4096 janv. 6 23:57 lib
lrwxrwxrwx 1 root root 9 août 6 2020 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 août 6 2020 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 août 6 2020 libx32 -> usr/libx32
drwx------ 2 root root 16384 août 6 2020 lost+found
drwxr-xr-x 2 root root 4096 août 6 2020 media
drwxr-xr-x 2 root root 4096 août 6 2020 mnt
drwxr-xr-x 5 root root 4096 nov. 7 2022 opt
dr-xr-xr-x 225 root root 0 juin 12 18:59 proc
drwx------ 12 root root 4096 juin 12 15:32 root
drwxr-xr-x 2 root root 4096 août 6 2020 run
lrwxrwxrwx 1 root root 8 août 6 2020 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 août 6 2020 srv
dr-xr-xr-x 13 root root 0 juin 12 18:31 sys
drwxrwxrwt 26 root root 4096 juin 12 16:07 tmp
drwxr-xr-x 14 root root 4096 janv. 6 23:57 usr
drwxr-xr-x 18 root root 4096 sept. 24 2020 var
lrwxrwxrwx 1 root root 26 juin 12 13:47 vmlinuz -> boot/vmlinuz-6.1.0-9-amd64
lrwxrwxrwx 1 root root 36 juin 12 13:47 vmlinuz.old -> boot/vmlinuz-5.10.0-0.deb10.22-amd64
Alors ça, je ne peux pas l’exécuter, vu que le chroot ne marche pas (que ce soit avec /bin/bash ou /usr/bin/bash, c’est pareil, alors que les fichiers y sont bien), mais le dernier paquet libcrypt1, celui que je suis allé chercher dans /var/cache/apt/ et dont j’ai déployé « à la main » les fichiers avec ar et tar (méthode trés sale de désespéré), c’est: libcrypt1_1%3a4.4.33-2_amd64.deb
Tu crois que ça vaudrait le coup de tester en redéployant violemment les fichiers du paquet buster à la place ?
Ca mérite un test.
Je fais ça dés que j’ai fini de sauvegarder tout.
Sinon, j’ai pensé aussi que je pouvais réinstaller tous les executables d’une bookworm neuve par dessus mon install actuelle avec debootstrap, puisque tout est en place pour ça, mais j’ai un peu peur que ça écrase au passage toute la config en place (notamment les bdd sql).
Le problème n’est pas la robustesse d’apt.
apt n’est pas fait pour gérer des upgrades de N à N+2 et des configurations totalement modifiées pour certaines fonctions vitales.
Il y a réellement des choses qui doivent être totalement reconfigurées de N à N+2.
Rattrapper des sytèmes à priori foutus ne m’a jamais fait peur.
Mais dans ton cas précis, après bricolage/chrootage en multi-arch ma conclusion est claire, si tu vises un système exploitable et durable.
??? Non mais sérieux. Pitié.
Ce genre de situation n’est pas de l’à peu près, mais demande une extrême précision, déjà en se souciant si un chroot est fait d’un système x64 vers i386 ou pas…
Le chroot de on ne sait pas quoi vers on ne sait pas quoi ne s’invente pas.
mattotop va poursuivre s’il le souhaite, mais sans complications supplémentaires.
surement, mais je ne suis pas devant son ordi, et comme il a déjà essayé, pourquoi pas? J’essaie de lui proposer des solutions avant la réinstallation avec perte que tu suggères avec certitude en ne faisant que critiquer sa méthode.
Perso je trouve que c’est aussi comme ça qu’on peut apprendre de ses erreurs., en essayant de les réparer.
avec ça il serait sauvé, non? Perso avant de faire un bullseye vers bookworm, je fais un rsync compet du système
Mon idée est qu’en réinstallant un système buster avec tous les programmes puis en copiant par dessus la sauvegarde ça pourrait marcher, mais c’est vrai que je n’ai jamais essayé; ensuite bullseye et bookworm
je vais essayer pour voir.
Mais ça n’aide pas ici.
Bah non, car ça ne ferait rien d’autre que réinstaller le bazar sauvegardé, je me retrouverais avec les mêmes problèmes d’incohérence sur les libs.
J’ai essayé le bootstrap d’une bullseye par dessus l’existant, mais ça s’est arrêté au déploiement des paquets parce que debootstrap refuse d’écraser les fichiers en place. C’est un bug de debootstrap, mais les devs ont décidé que c’était pas assez important pour qu’ils le corrigent (au dernières nouvelles du bug report que j’ai lu).
Sinon, j’ai fini de réinstaller et de configurer la base d’un nouveau serveur, je m’apprêtais à réimporter la config dessus comme sur le vieux, mais j’ai réalisé soudain que comme j’avais une vingtaine de noms de domaines gérés dessus, avec toute la config dns, les sites web et le systéme de mail qui va avec, il valait mieux que je réinstalle le tout sur la même adresse ip, sinon faut que j’aille changer les configs chez le registrar, que j’attende la propagation des nouvelles zones, etc, l’horreur.
Bref, je vais formater l’ancien serveur et remettre petit à petit la config d’avant, donc on peut laisser tomber l’idée de le corriger ou d’en faire un clone, je vous remercie de vos suggestions.
Ah tiens, en remontant ma config (ça avance bien merci), je me suis aperçu que mon serveur dns slave était en stretch…
Je l’avais oublié celui là.
Promis, je ne le passe pas direct en bookworm.
He oui… ‹ apt est robuste ›, mais il ne sait pas tout faire, et surtout pas remettre à niveau un système qui date de stretch avec des upgrades successifs de N à N+2…
apt gère les dépendances, exécutent des scripts de post-inst, et c’est tout. Rien de plus.
Ca n’a aucune importance. C’est un slave; donc à partir du moment ou tu sauvegarde les fichiers de conf (named.conf*, le reste sera mis à jour lors du transfert de zone.
Coté Debian, installation minimale directe (j’ai même une iso toute prête pour ça, suffit de la mettre et le serveur est directement utilisable tel quel.)
