Erhalten Sie die Meldung „nicht gefunden“, wenn Sie eine 32-Bit-Binärdatei auf einem 64-Bit-System ausführen?

Ich habe derzeit ein seltsames Problem auf Debian (wheezy/amd64).

Ich habe eine Chroot erstellt, um einen Server zu installieren (mehr Details kann ich dazu leider nicht sagen). Nennen wir seinen Pfad /chr_path/ .
Zur Vereinfachung 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 (Der Installer enthält aus bestimmten Gründen eine Perl-Binärdatei)

Natürlich habe ich den /some_path/ überprüft location und ich habe die „perl“-Binärdatei gefunden. Datei in der Chroot-Umgebung gibt :

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 verwenden , ls , vim drauf, aber sobald ich versuche es auszuführen – ./perl zum Beispiel – ich bekomme:zsh:Not found ./perl .

Diese Situation ist für mich durchaus nachvollziehbar. Außerdem :

• Ich kann andere einfache Binärdateien (/bin/ls,…) in der Chroot ausführen, ohne Fehler zu bekommen
• Ich habe die gleichen Probleme mit anderen Binärdateien, die mit dem Projekt geliefert wurden
• Wenn ich versuche, die Binärdatei vom Hauptstammverzeichnis auszuführen (/chr_path/some_path/perl ), es funktioniert.
• Ich habe versucht, eine der Binärdateien mit einer Kopie meines ls zusammenzufügen . Ich habe überprüft, ob die Zugriffsrechte gleich sind, aber das hat nichts geändert (eines funktionierte und das andere nicht)

Akzeptierte Antwort:

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

• Der Lader 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 Programm, das in der Shebang-Zeile erwähnt wird, z. /bin/sh für ein Skript, das mit #!/bin/sh beginnt . (Bash und zsh geben in diesem Fall eine Meldung „bad interpreter“ anstelle von „command not found“ aus.)

Die Fehlermeldung ist ziemlich irreführend, da sie nicht anzeigt, 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 hat, nicht aber auch zum Anzeigen, dass der Fehler tatsächlich eine andere Datei betrifft. Einige Shells erledigen die Arbeit für Skripte selbst (Lesen der #! Zeile im Skript und Überarbeitung der Fehlerbedingung), aber keiner, den ich gesehen habe, hat versucht, dasselbe für native Binärdateien zu tun.

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

Verwandte:Möglichkeit, den optimalen Wert für den bs-Parameter für dd zu bestimmen?

Diese Situation tritt häufig auf, wenn Sie versuchen, eine Binärdatei für das richtige System (oder die richtige Systemfamilie) und Superarchitektur, aber die falsche Subarchitektur 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, daher sind die Anweisungen sinnvoll und bringen das Programm an den Punkt, an dem es nach seinem Ladeprogramm suchen kann. Aber das Programm ist ein 32-Bit-Programm (wie die file Ausgabe anzeigt), suchen Sie nach dem 32-Bit-Loader /lib/ld-linux.so.2 , und Sie haben vermutlich nur den 64-Bit-Loader /lib64/ld-linux-x86-64.so.2 installiert in der Chroot.

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 die Multiarch-Unterstützung: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 des Perl-Pakets von Debian erstellen möchten, um zu sehen, welche Bibliotheken wahrscheinlich benötigt werden, können Sie aptitude search -F %p '~Rdepends:^perl$ ~ri386' ). Sie können eine Sammlung gemeinsamer Bibliotheken einbinden, indem Sie die ia32-libs installieren Paket (Sie müssen zuerst die Multiarch-Unterstützung aktivieren). Auf Debian amd64 bis hin zu Wheezy befindet sich der 32-Bit-Loader in der libc6-i386 Paket. Sie können einen größeren Satz von 32-Bit-Bibliotheken installieren, indem Sie ia32-libs installieren .