[Linux] Wie "no such file or directory" auflösen [solved]

[Schotter (schottre)]

Hallöchen,

folgendes Problem. Es gibt da ein Programm, das sich mit

No such file or directory

verabschiedet. Normalerweise wird es aus einer GUI heraus ausgeführt, 
d.h. an einem falschen Aufruf liegt es nicht.

Eine ähnliche Situation hatte ich schon einmal, dabei hat mir `strace` 
die Sicht verstellt, denn die ausgeführte "Anwendung" war nur ein 
Skript, dass nach `ksh` gefragt hat, was nicht installiert war. -> 
Gleicher Fehler.

Aber jetzt handelt es sich definitiv um ein kompiliertes Programm und 
ich dachte mit `strace` würde ich herausbekommen auf welche Datei 
zugegriffen werden soll. Klappt aber nicht. (verbose liefert auch nicht 
mehr.)

strace program
execve("/path/to/the/executable/bin/program", ["program"], 0x7ffd5e62b230 /* 67 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

Ich vermute es fehlt irgendein Paket.

Hat jmd weitere Ideen, wie ich der Datei/Bibliothek auf die Schliche 
komme?

Danke,

ts

[Niklas G. (erlkoenig)]

Wahrscheinlich ist die Programmdatei gar nicht auf dem System 
ausführbar, z.B. weil sie für eine andere Architektur kompiliert wurde. 
Ggf. hilft das installieren von 32/64 bit libraries für die benötigte 
Architektur.

Benutz mal "file programmdatei" und "ldd programmdatei" und "objdump -f 
programmdatei".

[Jack V. (jackv)]

Thorsten S. schrieb:
> Hat jmd weitere Ideen, wie ich der Datei/Bibliothek auf die Schliche
> komme?

Mit den Daten, die du rauszensiert hast. Wenn man wüsste, um welches 
Programm es denn geht, könnte man schauen, wovon es abhängt und wo es 
seine Komponenten erwartet.

[Daniel A. (daniel-a)]

Vielleicht fehlt der dynamic loader (man ld.so)?

[Schotter (schottre)]

Niklas G. schrieb:
> Wahrscheinlich ist die Programmdatei gar nicht auf dem System
> ausführbar, z.B. weil sie für eine andere Architektur kompiliert wurde.
> Ggf. hilft das installieren von 32/64 bit libraries für die benötigte
> Architektur.

Darauf wird es wohl hinauslaufen. Ich musste der Datei auch erst noch 
etwas hinterherlaufen, weil es sich um einen SymLink handelte. Aber 
nachdem ich den aufgelöst hatte, konnte ich mir sicher sein, dass die 
Ausgaben passen.

> Benutz mal "file programmdatei" und "ldd programmdatei" und "objdump -f
> programmdatei".`

$ file program
program: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=f6aaff89144be508306dc56d14f4807ab997a953, for GNU/Linux 2.6.32, stripped

$ ldd program
  not a dynamic executable

$ objdump -f program
program:     file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0804ce78

Jack V. schrieb:
> Mit den Daten, die du rauszensiert hast. Wenn man wüsste, um welches
> Programm es denn geht, könnte man schauen, wovon es abhängt und wo es
> seine Komponenten erwartet.

Würde es sich um ein Open Source Programm handeln, hätte ich das schon 
mit angegeben.

Danke für die Hilfe, Problem solved.

[Niklas G. (erlkoenig)]

Schotter schrieb:
> Problem solved.

Wie das jetzt?

[Jack V. (jackv)]

Niklas G. schrieb:
> Wie das jetzt?

Statisch gebautes 32Bit-Binary auf’m 64Bit-System, wohl.

Schotter schrieb:
> Würde es sich um ein Open Source Programm handeln, hätte ich das schon
> mit angegeben.

Auch bei Closed Source darf man in der Regel Namen, Pfade und weitere 
Informationen angeben, um den Leuten die Unterstützung zu erleichtern. 
Noch besser ist aber im Fall proprietärer Software, den Support ihres 
Anbieters zu kontaktieren.

[Niklas G. (erlkoenig)]

Jack V. schrieb:
> Statisch gebautes 32Bit-Binary auf’m 64Bit-System, wohl.

Ja, aber das sollte man prinzipiell schon auch starten können. Braucht 
ja nichtmal den dynamischen Linker. 32bit Support im Kernel deaktiviert?

[Schotter (schottre)]

Niklas G. schrieb:
> Schotter schrieb:
>> Problem solved.
>
> Wie das jetzt?

32-Bit Bibliotheken nachinstalliert. Jetzt lässt es sich immerhin 
ausführen. Die "GUI" wirft noch die gleiche Fehlermeldung, aber da 
vermute ich jetzt eher nicht erfüllte Abhängigkeiten. Ein `yum install 
*.i686` wollte ich nicht lostreten. Jetzt wird's eben fisselig.

Niklas G. schrieb:
> Ja, aber das sollte man prinzipiell schon auch starten können. Braucht
> ja nichtmal den dynamischen Linker. 32bit Support im Kernel deaktiviert?

Nope, es läuft [AlmaLinux8](https://almalinux.org/), RHEL-Klon.


Jack V. schrieb:
> Noch besser ist aber im Fall proprietärer Software, den Support ihres
> Anbieters zu kontaktieren.

Da kommt als erstes die Frage, ob auch RHEL oder SuSE im Einsatz ist. 
Das muss ich verneinen und dann heißt's "Pech gehabt".

[Rolf M. (rmagnus)]

Schotter schrieb:
> $ file program
> program: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> dynamically linked, interpreter /lib/ld-linux.so.2,
> BuildID[sha1]=f6aaff89144be508306dc56d14f4807ab997a953, for GNU/Linux
> 2.6.32, stripped
> $ ldd program
>   not a dynamic executable

Die Ausgabe finde ich merkwürdig. file meint, es sei dynamisch gelinkt, 
ldd sagt genau das Gegenteil.

[Thomas F. (tommf)]

ldd schreibt das immer, wenn er mit dem Programm nichts anfangen kann, 
also auch wenn - wie hier- ein 64Bit-ldd ein 32Bit-Programm bekommt. 
file hat da einen wesentlich breiteren Blickwinkel und kennt mehr 
Varianten.

[Rolf M. (rmagnus)]

Thomas F. schrieb:
> ldd schreibt das immer, wenn er mit dem Programm nichts anfangen kann,
> also auch wenn - wie hier- ein 64Bit-ldd ein 32Bit-Programm bekommt.
> file hat da einen wesentlich breiteren Blickwinkel und kennt mehr
> Varianten.

Bei mir funktioniert es sowohl mit 32- als auch mit 64-Bit-Programmen.

[Thomas F. (tommf)]

Kann sein, dass das funktioniert, wenn auch die 32Bit-Libraries 
installiert sind. Aber die fehlten ja beim TO am Anfang.