Die ausführbare Linux-Datei schlägt mit "Datei nicht gefunden" fehl, obwohl sich die Datei dort und in PATH befindet

Ich möchte die wineausführbare Datei (Version 2.12) starten , erhalte jedoch die folgende Fehlermeldung ( $= Shell-Eingabeaufforderung):

$ 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

Die Datei ist jedoch dort:

$ which wine
/usr/bin/wine

Die ausführbare Datei ist definitiv da und kein toter Symlink:

$ 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: -

Es ist eine 32-Bit-ELF:

$ 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

Ich kann den dynamischen Abschnitt der ausführbaren Datei abrufen:

$ 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]

Ich kann die gemeinsamen Objektabhängigkeiten jedoch nicht auflisten, indem ich Folgendes verwende ldd:

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

strace zeigt an:

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 +++

Bearbeitet, um einen Vorschlag von @jww hinzuzufügen : Das Problem tritt anscheinend auf, bevor dynamisch verknüpfte Bibliotheken angefordert werden, da keine ldDebug-Meldungen generiert werden:

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

Auch wenn nur die möglichen Werte von gedruckt werden LD_DEBUG, tritt der Fehler stattdessen auf

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

Bearbeitet, um den Vorschlag von @Raman Sailopal hinzuzufügen: Das Problem scheint in der ausführbaren Datei zu liegen, da das Kopieren des Inhalts /usr/bin/winein eine andere bereits erstellte Datei den gleichen Fehler erzeugt

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

Was ist das Problem oder was kann ich tun, um herauszufinden, welche Datei oder welches Verzeichnis fehlt?

uname -a:

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

Dies:

$ 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

Kombiniert damit:

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

Weist nachdrücklich darauf hin, dass das System nicht über den /lib/ld-linux.so.2ELF-Interpreter verfügt. Das heißt, auf diesem 64-Bit-System sind keine 32-Bit-Kompatibilitätsbibliotheken installiert. Somit ist die Antwort von @ user1334609 im Wesentlichen richtig.

OK, ich war die letzten acht Stunden damit beschäftigt, mein System wieder in Betrieb zu nehmen, nachdem die CPU überhitzt wurde. Beim Neustart stellte sich heraus, dass es so durcheinander war, dass selbst die Fallback-Konsole von initrd meine Tastatur nicht mehr erkannte. Es ist mir ein Rätsel, wie das System so lange funktionsfähig blieb, als ich versuchte, die unzähligen Vorschläge von Ihnen umzusetzen (vielen Dank !!)

Problem beim Neustart:

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

und keine tastatur funktioniert danach :-)

Das Problem war: Ein Update ersetzte den Symlink /lib -> /usr/libdurch ein Verzeichnis. Das bedeutete also, dass alle Bibliotheken und Kernelmodule /libfehlten , die erwartet wurden :-)

Also habe ich den Symlink neu erstellt und das Basissystem von einer Live-CD neu installiert.

Jetzt, wo ich wieder Internet habe, habe ich auch diesen Thread gefunden

Ich habe auch den Paketmanager meiner gemauerten Installation auf der Festplatte (genannt pacman) von der Live-CD verwendet, um alle Pakete der Basisgruppe neu zu installieren (vielleicht nur den Kernel, also linuxhätte das Paket gereicht, ich weiß nicht).

Um dies zu erreichen, mounten Sie die Hauptpartition der gemauerten Installation in das /mntVerzeichnis des Live-CD-Systems und verwenden Sie chroot, um pacmanthink /mntis /(fügen Sie die Hauptpartition Ihres gemauerten Systems für ein 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

Für den Datensatz: Erstellen Sie einen relativen Symlink, ln -s usr/lib /mnt/libund nicht ln -s /usr/lib /mnt/lib, da die Hauptpartition während des frühen Systemstarts (initrd-Phase) zuerst gemountet wird /new_root. Wäre der Symlink absolut, würden Sie beim frühen Booten den oben genannten Fehler erhalten.

Sie versuchen, eine 32-Bit-Anwendung auf einem 64-Bit-Betriebssystem auszuführen. Daher müssen Sie 32-Bit-Kompatibilitätsbibliotheken (insbesondere glibc) installieren, bevor dies funktioniert.

Zu Ihrer Information, ich bin auf dasselbe Problem gestoßen, das in einem alpinen Docker-Image ausgeführt wurde. Die ausführbare Datei war eine 64-Bit-ELF, und das Alpen-Image war 64-Bit, und die ausführbare Datei arbeitete in einem anderen Container. Vermutlich waren die zugeschnittenen Alpenbibliotheken nicht mit meiner ausführbaren Datei kompatibel. Die Docker-Hub-Seite node.js enthält die folgenden Hinweise:

Die größte Einschränkung [beim Ausführen in Containern auf Alpine-Basis] besteht darin, dass musl libc anstelle von glibc und friends verwendet wird. Daher kann es je nach Umfang der libc-Anforderungen zu Problemen kommen. Die meisten Softwareprogramme haben jedoch kein Problem damit. Daher ist diese Variante in der Regel eine sehr sichere Wahl. In diesem Hacker News-Kommentarthread finden Sie weitere Informationen zu den möglicherweise auftretenden Problemen und einige Pro / Contra-Vergleiche zur Verwendung alpiner Bilder.

Meine Lösung bestand darin, ein anderes (z. B. Debian Jessie-basiertes) Container-Image zu verwenden.