Ich möchte die ausführbare Datei wine (Version 2.12) starten, erhalte jedoch den folgenden Fehler ($ = 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 befindet sich jedoch dort: 

$ which wine /usr/bin/wine

Die ausführbare Datei ist definitiv vorhanden 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 handelt sich um 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 Abhängigkeiten von gemeinsam genutzten Objekten jedoch nicht mit : 

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

strace zeigt: 

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 scheint vor der dynamischen Verknüpfung aufzutreten Bibliotheken werden angefordert, da keine ld Debug-Meldungen generiert werden: 

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

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

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

Zum Hinzufügen bearbeitet Vorschlag von @Raman Sailopal: Das Problem scheint in der ausführbaren Datei zu liegen, da das Kopieren des Inhalts von /usr/bin/wine in eine andere bereits erstellte Datei erzeugt wird der gleiche Fehler 

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

Kommentare

  • ./wine in / usr / bin work?
  • Arch ist Multilib-fähig. Das Multilib-Repository ist in /etc/pacman.conf aktiviert. Alle Abhängigkeiten des wine -Pakets werden installiert. Installieren Sie sie jedoch erneut, um sicherzustellen, dass …
  • /lib/ld-linux.so.2 auf Ihrem System vorhanden ist? Alle Symptome deuten darauf hin, dass es fehlt, nur überprüfen.
  • @ n.m. Ja, du hattest recht. Tatsächlich fehlte das gesamte Verzeichnis /lib 🙂
  • Erfahrung;), wenn Sie versuchen, eine ausführbare Datei auszuführen und eine Datei nicht gefunden “ Fehler, während die Datei offensichtlich hier ist, ‚ fehlt der Interpreter. Ihr Befehl file zeigt an, welcher Interpreter für diese ausführbare Datei festgelegt ist.

Antwort

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

In Kombination damit: 

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

Dies wird dringend empfohlen dass das System nicht über den ELF-Interpreter /lib/ld-linux.so.2 verfügt. Das heißt, auf diesem 64-Bit-System sind keine 32-Bit-Kompatibilitätsbibliotheken installiert. Daher ist die Antwort von @ user1334609 im Wesentlichen korrekt.

Kommentare

  • Wird jemand über die irreführende Fehlermeldung sprechen?

Antwort

OK, ich war die letzten acht Stunden damit beschäftigt, mein System nach dem Herunterfahren der CPU-Überhitzung wieder zum Laufen zu bringen 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 betriebsbereit blieb, während 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, die danach funktioniert 🙂

Das Problem war: Ein Update ersetzte den Symlink /lib -> /usr/lib mit einem Verzeichnis. Das bedeutete also, dass alle Bibliotheken und Kernelmodule, von denen erwartet wird, dass sie sich in /lib befinden, fehlten 🙂

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

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

Ich habe auch den Paketmanager von my verwendet Installation auf der Festplatte (pacman) von der Live-CD gemauert, um alle Pakete der Basisgruppe neu zu installieren ( Vielleicht nur der Kernel, also hätte das Paket linux gereicht, ich weiß nicht)

Mounten Sie dazu die Hauptpartition der gemauerten Installation auf das Verzeichnis /mnt des Live-CD-Systems und verwenden Sie chroot, um pacman zum Nachdenken /mnt ist / (fügen Sie die Hauptpartition Ihres gemauerten Systems für sdXXX)

ein 

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, also ln -s usr/lib /mnt/lib und nicht ln -s /usr/lib /mnt/lib, da während des frühen Systemstarts (Initrd-Phase) die Hauptpartition zuerst gemountet wird zu /new_root.Wäre der Symlink absolut, würden Sie den oben genannten Fehler beim frühen Start erhalten.

Kommentare

  • Kleiner Hinweis: Bei Verwendung von systemrescuecd iteriere ich oft nur über proc / sys / dev (für den Pfad in proc sys dev; do mount -obind / $ path / mnt / $ path; done) vor dem Chroot. Wenn Sie jedoch ‚ die Arch-Installations-ISO verwenden, ist es viel einfacher, die bereitgestellte ausführbare Arch-Chroot-Datei auszuführen, da sie alles für Sie erledigt. Es ist im Paket arch-install-scripts enthalten, wenn jemand herumstöbern möchte. 🙂

Antwort

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

Kommentare

  • Bitte klären Sie, wie Ihre Lösung den Fall löst und beantworte die Frage
  • Was Romeo gesagt hat; Sie würden apt-get auf einem Arch-Linux-System anstelle von Pacman ausführen? Und wie würden Komprimierungsbibliotheken und ncurses ihnen helfen?

Antwort

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

Die wichtigste Einschränkung [zum Ausführen im alpinen Container] verwendet musl libc anstelle von glibc und Freunde , sodass bestimmte Software abhängig von der Tiefe ihrer libc-Anforderungen auf Probleme stoßen kann. Die meisten Programme haben jedoch kein Problem damit, daher ist diese Variante normalerweise eine sehr sichere Wahl. Weitere Informationen zu diesem Thema finden Sie unter in diesem Hacker News-Kommentarthread Probleme, die auftreten könnten, und einige Pro / Contra-Vergleiche bei der Verwendung von Bildern auf Alpenbasis.

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

Kommentare

  • Vielen Dank, dass Sie dieses ursprüngliche Systemadministrationsproblem mit dem “ new “ Welt der Container!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.