Obtention du message "Not found" lors de l'exécution d'un fichier binaire 32 bits sur un système 64 bits

J'ai actuellement un problème étrange sur debian (Wheezy / amd64).

J'ai créé un chroot pour installer un serveur (je ne peux pas donner plus de détails à ce sujet, désolé). Appelons son chemin /chr_path/. Pour rendre les choses faciles, j'ai initialisé ce chroot avec un debootstrap (également Wheezy / amd64).

Tout semblait bien fonctionner à l'intérieur du chroot, mais lorsque j'ai lancé le script d'installation de mon serveur, j'ai reçu: zsh: Not found /some_path/perl(l'installateur contient un binaire Perl pour certaines raisons)

Naturellement, j'ai vérifié l' /some_path/emplacement et j'ai trouvé le binaire "perl". fileen environnement chroot, retourne:

/some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

Le fichier existe, semble ok, a les droits corrects. Je peux utiliser file, ls, vimsur elle , mais dès que je tente de l' exécuter - ./perlpar exemple - je reçois: zsh: Not found ./perl.

Cette situation est tout à fait compréhensible pour moi. De plus :

• Je peux exécuter d'autres binaires de base (/ bin / ls, ...) dans le chroot sans commettre d'erreur
• J'ai les mêmes problèmes pour les autres fichiers binaires fournis avec le projet
• Lorsque j'essaie d'exécuter le binaire à partir de la racine principale ( /chr_path/some_path/perl), cela fonctionne.
• J'ai essayé de mettre un des binaires avec une copie de mon fichier ls. J'ai vérifié que les droits d'accès étaient les mêmes mais cela ne changeait rien (l'un fonctionnait, l'autre ne l'était pas)

Lorsque vous ne parvenez pas à exécuter un fichier dépendant d'un «chargeur», l'erreur que vous obtenez peut faire référence au chargeur plutôt qu'au fichier que vous exécutez.

• Le chargeur d'un exécutable natif lié dynamiquement est la partie du système responsable du chargement des bibliothèques dynamiques. C'est quelque chose comme /lib/ld.soou /lib/ld-linux.so.2, et devrait être un fichier exécutable.
• Le chargeur d'un script est le programme mentionné sur la ligne shebang, par exemple /bin/shpour un script qui commence par #!/bin/sh. (Bash et zsh affichent un message «mauvais interprète» au lieu de «commande introuvable» dans ce cas.)

Le message d'erreur est plutôt trompeur car il n'indique pas que le chargeur est le problème. Malheureusement, il serait difficile de résoudre ce problème car l'interface du noyau ne permettait de signaler qu'un code d'erreur numérique, mais pas d'indiquer également que l'erreur concernait en fait un fichier différent. Certains shells font le travail eux-mêmes pour les scripts (en lisant la #!ligne et en retravaillant la condition d'erreur), mais aucun de ceux que j'ai vus ne tente de faire la même chose pour les fichiers binaires natifs.

lddCela ne fonctionnera pas non plus sur les fichiers binaires, car il définit des variables d’environnement spéciales, puis exécute le programme et permet au chargeur d’effectuer le travail. stracene fournirait aucune information significative non plus, car il ne rapporterait pas plus que ce que le noyau rapportait, et comme nous l'avons vu, le noyau ne peut pas tout rapporter.

Cette situation se produit souvent lorsque vous essayez d'exécuter un fichier binaire pour le bon système (ou la bonne famille de systèmes) et la superarchitecture, mais pour la mauvaise sous-architecture. Ici, vous avez des binaires ELF sur un système qui en attend, le noyau les charge donc parfaitement. Ce sont des binaires i386 s'exécutant sur un processeur x86_64. Les instructions ont donc un sens et permettent au programme de rechercher le chargeur. Mais le programme est un programme 32 bits (comme le filemontre la sortie) cherche le chargeur 32 bits /lib/ld-linux.so.2et vous n’avez probablement installé que le chargeur 64 bits /lib64/ld-linux-x86-64.so.2dans le chroot.

Vous devez installer le système d'exécution 32 bits dans le chroot: le chargeur et toutes les bibliothèques dont les programmes ont besoin. À partir de Debian Wheezy, si vous souhaitez une prise en charge de i386 et x86_64, commencez par une installation amd64 et activez le support multiarch : run dpkg --add-architecture i386then apt-get updateet apt-get install libc6:i386 zlib1g:i386 …(si vous souhaitez générer une liste des dépendances du paquet perl de Debian, voyez ce que les bibliothèques sont susceptibles de contenir. être nécessaire, vous pouvez utiliser aptitude search -F %p '~Rdepends:^perl$ ~ri386'). Vous pouvez extraire une collection de bibliothèques communes en installant le ia32-libspaquet (vous devez d'abord activer le support multiarch). Sur Debian amd64 jusqu’à Wheezy, le chargeur 32 bits est dans le libc6-i386paquet. Vous pouvez installer un plus grand ensemble de bibliothèques 32 bits en installant ia32-libs.

Courez ldd(1)sur votre perlbinaire. Souvent, l' Not founderreur apparemment déroutante sur un fichier qui est clairement là existe parce qu'une des bibliothèques partagées utilisées par le programme est introuvable.

Il est donc possible que votre chroot soit incomplet en ce qui concerne les bibliothèques partagées nécessaires à vos fichiers binaires.