L'exécutable Linux échoue avec «Fichier introuvable» même si le fichier est là et dans PATH

Je veux lancer l' wineexécutable (version 2.12), mais j'obtiens l'erreur suivante ( $= invite shell):

$ wine
bash: /usr/bin/wine: No such file or directory
$ /usr/bin/wine
bash: /usr/bin/wine: No such file or directory
$ cd /usr/bin
$ ./wine
bash: ./wine: No such file or directory

Cependant, le fichier est là:

$ which wine
/usr/bin/wine

L'exécutable est définitivement là et aucun lien symbolique mort:

$ stat /usr/bin/wine
  File: /usr/bin/wine
  Size: 9712            Blocks: 24         IO Block: 4096   regular file
Device: 802h/2050d      Inode: 415789      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-07-13 13:53:00.000000000 +0200
Modify: 2017-07-08 03:42:45.000000000 +0200
Change: 2017-07-13 13:53:00.817346043 +0200
 Birth: -

Il s'agit d'un ELF 32 bits:

$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

Je peux obtenir la section dynamique de l'exécutable:

$ readelf -d /usr/bin/wine
Dynamic section at offset 0x1efc contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libwine.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000001d (RUNPATH)                    Library runpath: [$ORIGIN/../lib32]
 0x0000000c (INIT)                       0x7c000854
 0x0000000d (FINI)                       0x7c000e54
 [more addresses without file names]

Cependant, je ne peux pas lister les dépendances d'objets partagés en utilisant ldd:

$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory

strace spectacles:

execve("/usr/bin/wine", ["wine"], 0x7fff20dc8730 /* 66 vars */) = -1 ENOENT (No such file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
getpid()                                = 23783
exit_group(1)                           = ?
+++ exited with 1 +++

Modifié pour ajouter une suggestion par @jww : Le problème semble se produire avant la demande de bibliothèques liées dynamiquement, car aucun ldmessage de débogage n'est généré:

$ LD_DEBUG=all wine
bash: /usr/bin/wine: No such file or directory

Même lors de l'impression uniquement des valeurs possibles de LD_DEBUG, l'erreur se produit à la place

$ LD_DEBUG=help wine
bash: /usr/bin/wine: No such file or directory

Modifié pour ajouter la suggestion de @Raman Sailopal: Le problème semble résider dans l'exécutable, car la copie du contenu de /usr/bin/winedans un autre fichier déjà créé produit la même erreur

root:bin # cp cat testcmd    

root:bin # testcmd --help
Usage: testcmd [OPTION]... [FILE]...
Concatenate FILE(s) to standard output.
[rest of cat help page]

root:bin # dd if=wine of=testcmd  
18+1 records in
18+1 records out
9712 bytes (9.7 kB, 9.5 KiB) copied, 0.000404061 s, 24.0 MB/s

root:bin # testcmd
bash: /usr/bin/testcmd: No such file or directory

Quel est le problème ou que puis-je faire pour savoir quel fichier ou répertoire est manquant?

uname -a:

Linux laptop 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux

Cette:

$ file /usr/bin/wine
/usr/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, 
BuildID[sha1]=eaf6de433d8196e746c95d352e0258fe2b65ae24, stripped

Combiné avec ceci:

$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory

Suggère fortement que le système ne dispose pas de l' /lib/ld-linux.so.2interprète ELF. Autrement dit, ce système 64 bits n'a pas de bibliothèques de compatibilité 32 bits installées. Ainsi, la réponse de @ user1334609 est essentiellement correcte.

OK, j'étais occupé pendant les huit dernières heures à remettre mon système en marche après l'arrêt de la surchauffe du processeur. Au redémarrage, il est devenu évident qu'il était tellement foiré que même la console de secours d'initrd ne reconnaissait plus mon clavier. C'est un mystère pour moi comment le système a réussi à rester opérationnel pendant si longtemps, alors que j'essayais de mettre en œuvre les innombrables suggestions de vous (merci beaucoup !!)

Problème au redémarrage:

Warning: /lib/modules/4.11.3-1-ARCH/modules.devname not found - ignoring
ERROR: device 'UUID=...' not found. Skipping fsck.
ERROR: Unable to find root device 'UUID=...'.
You are being dropped to a recovery shell
Type 'exit' to try and continue booting
sh: can't access tty: job control turned off

et aucun clavier ne fonctionne ensuite :-)

Le problème était: Une mise à jour a remplacé le lien symbolique /lib -> /usr/libpar un répertoire. Cela signifiait donc que toutes les bibliothèques et les modules du noyau, qui devraient être /libinclus, manquaient :-)

J'ai donc recréé le lien symbolique et réinstallé le système de base à partir d'un CD live.

Maintenant que j'ai de nouveau Internet, j'ai aussi trouvé ce fil

J'ai également utilisé le gestionnaire de packages de mon installation sur disque en brique (appelé pacman) à partir du CD live pour réinstaller tous les packages du groupe de base (peut-être seulement le noyau, donc le paquet linuxaurait suffi, je ne sais pas)

Pour cela, monter la partition principale de l'installation maçonnée au /mntrépertoire du système CD live et en chrootfaire pacmanpenser /mntest /(insérer la partition principale de votre système pour maçonnéesdXXX )

mount /dev/sdXXX /mnt
# Recreate the /lib -> usr/lib symlink
ln -s usr/lib /lib  
# Mount essential system folders also to the respective subfolders of /mnt
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
# Fake /mnt to be /, so that pacman installs the packages to the correct  places
chroot /mnt
# Reinstall the Arch Linux base system
pacman -Sy base

Pour mémoire: créez un lien symbolique relatif, oui ln -s usr/lib /mnt/libet non ln -s /usr/lib /mnt/lib, car pendant le démarrage du système (étape initrd), la partition principale sera montée en premier sur /new_root. Si le lien symbolique était absolu, vous obtiendriez l'erreur susmentionnée lors du démarrage précoce.

Vous essayez d'exécuter une application 32 bits sur un système d'exploitation 64 bits, vous devez donc installer des bibliothèques de compatibilité 32 bits (glibc en particulier) avant que cela puisse fonctionner.

Pour info, je suis tombé sur ce même problème en cours d'exécution dans une image de docker alpin. L'exécutable était un ELF 64 bits, et l'image alpine était 64 bits, et l'exécutable fonctionnait dans un conteneur différent. Il est donc probable que les bibliothèques alpines découpées n'étaient pas compatibles avec mon exécutable. La page du hub de node.js Docker note:

La principale mise en garde [pour fonctionner dans le conteneur basé sur Alpine] est qu'il utilise musl libc au lieu de glibc et amis , de sorte que certains logiciels peuvent rencontrer des problèmes en fonction de la profondeur de leurs besoins en libc. Cependant, la plupart des logiciels n'ont pas de problème avec cela, donc cette variante est généralement un choix très sûr. Voir ce fil de commentaires Hacker News pour plus de discussion sur les problèmes qui pourraient survenir et quelques comparaisons pour / contre l'utilisation d'images basées sur les Alpes.

Ma solution était d'utiliser une image de conteneur différente (par exemple basée sur Debian Jessie).