Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Je crois qu'on chauffe.
L'hôte est une VM Parallels et il me revient qu'elle pourrait être une machine multiarchitecture...
Je crois avoir vu ça dans le résultat d'une commande.
Je n'y suis pas habitué. Et j'ai toujours installé des OS debian 64 bits.
Quelle serait la commande qui permet de savoir exactement s'il y a une multiarchitecture (qui aurait trompé apt) ?
(je ne crois pas que ce soit lscpu ni hostnamectl)
apt policy libc6 ?
Rappel : je ne peux pas tâtonner auprès de l'utilisateur en lui demandant de saisir de nombreuses commandes. Il doit entrer une commande pour diagnostiquer et une commande pour traiter le pb.
Merci.
----- Mail original -----
De: "didier gaumet" <didier.gaumet@gmail.com>
À: "Liste Debian" <debian-user-french@lists.debian.org>
Envoyé: Mardi 2 Mai 2023 08:21:25
Objet: Re: Problème pour servir à un exécutable sa dépendance à libc.so.6 (debian 11)
Le mardi 02 mai 2023 à 02:18 +0200, roger.tarani@free.fr a écrit :
> Merci !
>
> Je n'ai JAMAIS eu besoin d'installer spécifiquement ou de réparer la
> bibliothèque C (libc6) sur un hôte debian.
>
> L'utilisateur a installé sa debian11 seul à partir d'une image ISO
> récente.
> Je n'ai pas accès à sa machine. Je dois lui proposer une manip
> directe, simple et efficace.
>
> Je crois comprendre qu'il s'agit d'un problème de dynamic linker.
> Comment répare-t-on l'accès à cette bibliothèque libc qui est
> installée ?
>
> Question bonus : que peut faire un utilisateur (juste capable de
> recopier des lignes de commande fournies) pour diagnostiquer ce qui a
> pu abîmer ce système ?
>
>
> Extrait de mon message initial :
>
> //
> Sur l'hôte qui pose problème :
> - libc.so.6 est bien présent. Et est donc inaccessible à
> l'exécutable.
> - la commande ldconfig est introuvable. J'attends de savoir si
> /usr/sbin/ldconfig existe... Après vérification, ce fichier existe;
> Peut-être un problème de PATH ?...
>
> Sur un hôte qui sert correctement libc.so.6 au même exécutable, il y
> a les liens symboliques suivants vers ld-2.31.so :
>
> lrwxrwxrwx 1 root root 32 Apr 19 23:17 /lib64/ld-linux-x86-64.so.2 ->
> /lib/x86_64-linux-gnu/ld-2.31.so
>
> -rwxr-xr-x 1 root root 177928 Apr 19 23:17 /lib/x86_64-linux-gnu/ld-
> 2.31.so
> lrwxrwxrwx 1 root root 10 Apr 19 23:17 /lib/x86_64-linux-gnu/ld-
> linux-x86-64.so.2 -> ld-2.31.so
>
> Cela manque sur l'hôte qui pose problème.
> //
comme les liens en question semblent (si j'ai compris correctement, ce
qui reste encore à prouver) créés par l'installation du paquet libc6,
https://packages.debian.org/bullseye/amd64/libc6/filelist
c'est pour cela que je proposais:
- de vérifier (commande: apt policy libc6) les versions disponibles
pour installation et installées de libc6.
Un exemple de problème qui pourrait survenir: que ton utilisateur se
serve de multiarch; bien que l'hôte problématique soit en architecture
amd64, il suffisait par le passé que la double architecture (multiarch)
amd64+x86 soit paramétrée pour que parfois apt soit complètement perdu
et cherche à remplacer/installer des exécutables uniquement en 32 bits
(même si les deux architectures de ces exécutables existent) sur un
système 32+64 bits. Et parfois du coup ça ne marchait plus.
- de réinstallet (sudo apt reinstall libc6) ou reparamétrer (sudo dpkg-
reconfigure libc6). En cas de multiarch il faut spécifier le paramètre
-a=architecture pour apt et un dpkg-reconfigure ne suffit pas si seule
la version 32 bits de libc6 est insyallé: il faut réinstaller la
version 64 bits.
Mais je t'emmène peut-être sur une fausse piste, et même si cette piste
était en partie judicieuse, peut-être mon exposé serait-il faux quant
aux conséquences que j'évoque, hein, donc je t'encourage quoiqu'il en
soit à pendre en compte les suggestions de Jean-Michel dans son message
:-)
Reply to: