L'exécutable Linux échoue avec "Fichier non trouvé" même si le fichier est là et dans PATH
Je souhaite lancer l'exécutable wine (version 2.12), mais j'obtiens l'erreur suivante ($ = Invite du 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 des objets partagés à l'aide de ldd:
$ ldd /usr/bin/wine
/usr/bin/ldd: line 117: /usr/bin/wine: No such file or directory
strace montre:
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 que les bibliothèques liées dynamiquement ne soient demandées, car aucun message de débogage ld n'est généré:
$ LD_DEBUG=all wine
bash: /usr/bin/wine: No such file or directory
Même en n'imprimant que les 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, comme la copie du contenu de /usr/bin/wine vers 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 n'a pas le /lib/ld-linux.so.2 Interprè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/lib avec un répertoire. Cela signifiait donc toutes les bibliothèques et les modules du noyau, qui devraient être dans /lib manquait :-)
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ée pacman) à partir du CD live pour réinstaller tous les packages du groupe de base (peut-être uniquement le noyau, donc package linux aurait suffi, je ne sais pas)
Pour ce faire, montez la partition principale de l'installation en brique sur le /mnt répertoire du système de CD live et utilisez chroot pour faire pacman penser /mnt est / (insérez la partition principale de votre système bricked pour sdXXX)
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, donc ln -s usr/lib /mnt/lib et pas ln -s /usr/lib /mnt/lib, car lors du démarrage initial du système (étape initrd), la partition principale sera d'abord montée 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 docker basé sur Alpine. 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 Alpine découpées n'étaient pas compatibles avec mon exécutable. page du hub de node.js Docker notes:
La principale mise en garde [pour s'exécuter dans le conteneur basé sur Alpine] est qu'il utilise musl libc au lieu de glibc et amis , donc 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 Alpine.
Ma solution a été d'utiliser une image de conteneur différente (par exemple basée sur Debian Jessie).