it-swarm.com.de

Beim Ausführen einer 32-Bit-Binärdatei auf einem 64-Bit-System wird die Meldung "Nicht gefunden" angezeigt

Ich habe derzeit ein seltsames Problem mit Debian (Wheezy/AMD64).

Ich habe eine Chroot erstellt, um einen Server zu installieren (ich kann leider keine näheren Angaben dazu machen). Nennen wir seinen Pfad /chr_path/. Um die Sache zu vereinfachen, habe ich diese Chroot mit einem Debootstrap (auch Wheezy/AMD64) initialisiert.

Alles schien innerhalb der Chroot gut zu funktionieren, aber als ich das Installationsskript meines Servers startete, bekam ich: zsh: Not found /some_path/Perl (das Installationsprogramm enthält aus bestimmten Gründen eine Perl-Binärdatei)

Natürlich habe ich das /some_path/ location und ich fanden die "Perl" -Binärdatei. file in der Chroot-Umgebung gibt Folgendes zurück:

/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

Die Datei existiert, scheint in Ordnung zu sein, hat die richtigen Rechte. Ich kann file, ls, vim darauf verwenden, aber sobald ich versuche, es auszuführen - ./Perl zum Beispiel - ich bekomme: zsh: Not found ./Perl.

Diese Situation ist für mich durchaus verständlich. Außerdem :

  • Ich kann andere grundlegende Binärdateien (/ bin/ls, ...) in der Chroot ausführen, ohne Fehler zu erhalten
  • Ich habe die gleichen Probleme für andere Binärdateien, die mit dem Projekt geliefert wurden
  • Wenn ich versuche, die Binärdatei von der Hauptwurzel aus auszuführen (/chr_path/some_path/Perl), Es klappt.
  • Ich habe versucht, eine der Binärdateien mit einer Kopie meines ls abzulegen. Ich habe überprüft, ob die Zugriffsrechte gleich sind, aber dies hat nichts geändert (einer hat funktioniert und der andere nicht).
72
Elenaher

Wenn Sie eine Datei, die von einem „Loader“ abhängt, nicht ausführen können, bezieht sich der Fehler möglicherweise eher auf den Loader als auf die Datei, die Sie ausführen.

  • Der Loader einer dynamisch verknüpften nativen ausführbaren Datei ist der Teil des Systems, der für das Laden dynamischer Bibliotheken verantwortlich ist. Es ist so etwas wie /lib/ld.so oder /lib/ld-linux.so.2 und sollte eine ausführbare Datei sein.
  • Der Lader eines Skripts ist das in der Shebang-Zeile erwähnte Programm, z. /bin/sh für ein Skript, das mit #!/bin/sh beginnt. (Bash und zsh geben in diesem Fall die Meldung "Bad Interpreter" anstelle von "Command not found" aus.)

Die Fehlermeldung ist eher irreführend, da sie nicht darauf hinweist, dass der Loader das Problem ist. Leider wäre es schwierig, dies zu beheben, da die Kernel-Schnittstelle nur Platz zum Melden eines numerischen Fehlercodes bietet und nicht auch zum Anzeigen, dass der Fehler tatsächlich eine andere Datei betrifft. Einige Shells erledigen die Arbeit selbst für Skripte (Lesen der Zeile #! im Skript und Überarbeiten der Fehlerbedingung), aber keine, die ich gesehen habe, versucht, dasselbe für native Binärdateien zu tun.

ldd funktioniert auch nicht mit den Binärdateien, da einige spezielle Umgebungsvariablen festgelegt und dann das Programm ausgeführt werden, sodass der Loader die Arbeit erledigen kann. strace würde auch keine aussagekräftigen Informationen liefern, da nicht mehr als das gemeldet wird, was der Kernel meldet, und wie wir gesehen haben, kann der Kernel nicht alles melden, was er weiß.

Diese Situation tritt häufig auf, wenn Sie versuchen, eine Binärdatei für das richtige System (oder die Systemfamilie) und die Superarchitektur, jedoch für die falsche Unterarchitektur auszuführen. Hier haben Sie ELF-Binärdateien auf einem System, das ELF-Binärdateien erwartet, sodass der Kernel sie problemlos lädt. Es handelt sich um i386-Binärdateien, die auf einem x86_64-Prozessor ausgeführt werden. Die Anweisungen sind daher sinnvoll und bringen das Programm an den Punkt, an dem es nach seinem Loader suchen kann. Das Programm ist jedoch ein 32-Bit-Programm (wie die Ausgabe file angibt), das nach dem 32-Bit-Loader /lib/ld-linux.so.2 sucht, und Sie haben vermutlich nur den 64-Bit-Loader /lib64/ld-linux-x86-64.so.2 in der Chroot installiert.

Sie müssen das 32-Bit-Laufzeitsystem in der Chroot installieren: den Loader und alle Bibliotheken, die die Programme benötigen. Wenn Sie ab Debian wheezy sowohl i386- als auch x86_64-Unterstützung wünschen, beginnen Sie mit einer AMD64-Installation und aktivieren Sie multiarch support: Führen Sie dpkg --add-architecture i386 aus, dann apt-get update und apt-get install libc6:i386 zlib1g:i386 … (wenn Sie eine Liste der Abhängigkeiten von Debian generieren möchten Perl-Paket, um zu sehen, welche Bibliotheken wahrscheinlich benötigt werden, können Sie aptitude search -F %p '~Rdepends:^Perl$ ~ri386') verwenden. Sie können eine Sammlung allgemeiner Bibliotheken abrufen, indem Sie das Paket ia32-libs installieren (Sie müssen zuerst die Multiarch-Unterstützung aktivieren). Auf Debian AMD64 bis zum Keuchen befindet sich der 32-Bit-Loader im Paket libc6-i386 . Sie können einen größeren Satz von 32-Bit-Bibliotheken installieren, indem Sie ia32-libs installieren.

Führen Sie ldd(1) auf Ihrer Perl-Binärdatei aus. Oft ist das scheinbar verwirrende Not found Fehler in einer Datei, die eindeutig vorhanden ist, weil eine der vom Programm verwendeten gemeinsam genutzten Bibliotheken nicht gefunden wird.

Es ist also möglich, dass Ihre Chroot in Bezug auf die von Ihren Binärdateien benötigten gemeinsam genutzten Bibliotheken unvollständig ist.

5
camh