[Solved] Ubuntu 10.4: ELF Fehler bei netio

Markus Everson

Grand Admiral Special
Mitglied seit
22.10.2004
Beiträge
6.787
Renomée
270
Standort
Deutschland
root@hauptbenutzer:/tmp# . ./netio_linux-i386 -s
ELF: command not found

(das bin stammt aus dem netio Paket, den prefix netio_ habe ich drangehängt)

Kann jemand mit der Fehlermeldung/dem Sachverhalt was anfangen? Ich will die Netzwerkkarte vermessen.

root@hauptbenutzer:/tmp# ls -l ./netio_linux-i386
-rw-r--r-- 1 root root 14484 2010-04-25 15:58 ./netio_linux-i386

root@hauptbenutzer:/tmp# uname -a
Linux hauptbenutzer 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux
 
Zuletzt bearbeitet:
Der Punkt geht schon, hat ja eine Bedeutung.
Aber wenn ich das richtig sehen fehlt der Datei die Ausführberechtigung: -rw-r--r-- gibt niemandem das Recht sie auszuführen.
 
Der Punkt ist der source Operator. Bei dem braucht es glaub ich keine Ausführrechte. Aber:
Code:
[root@chef ~]# . /sbin/route
-bash: ELF: Kommando nicht gefunden.
Mit dem source Operator führt man Scripte aus.
man bash, siehe source
 
So wird das auch nichts. Der Punkt hat da nichts zu suchen, glaub's mir.

Code:
root@debian:~# . /sbin/route
bash:ELF: command not found

root@debian:~# /sbin/route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
default         router.lan   0.0.0.0         UG    0      0        0 eth0

MfG Dalai
 
Zuletzt bearbeitet:
Der Punkt geht schon, hat ja eine Bedeutung.
Aber wenn ich das richtig sehen fehlt der Datei die Ausführberechtigung: -rw-r--r-- gibt niemandem das Recht sie auszuführen.

Wenn das ein Shell-Script ist und der Punkt damit richtig ist, braucht es keine execute-Rechte. Denn wie SnakePlisken erwähnt hat, ist der Punkt der source Operator, welcher dann auf das Script ausgeführt wird.

Es gibt jetzt zwei Möglichkeiten. Entweder ist das File ein Binary, dann hat der Punkt dort nichts zu suchen. Oder es ist ein Script, dann ist der Punkt richtig und der Fehler kommt von einem Befehl aus dem Script. Wenn dem so ist, müssten wir den Inhalt des Scripts wissen, um weitere Infos geben zu können.
 
Klar, ihr habt natürlich recht. Ich bin einfach davon ausgegangen dass es sich um ein Skript handelt.
 
root@hauptbenutzer:/tmp# . ./netio_linux-i386 -s
ELF: command not found

(das bin stammt aus dem netio Paket, den prefix netio_ habe ich drangehängt)

Kann jemand mit der Fehlermeldung/dem Sachverhalt was anfangen? Ich will die Netzwerkkarte vermessen.

root@hauptbenutzer:/tmp# ls -l ./netio_linux-i386
-rw-r--r-- 1 root root 14484 2010-04-25 15:58 ./netio_linux-i386

root@hauptbenutzer:/tmp# uname -a
Linux hauptbenutzer 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux
Diesen Fehler hatte ich öfter mal, als multilib auf Exherbo noch in den Kinderschuhen steckte und der Migrationspfad auf multilib noch nicht ausgereift war. Da gab es ein Problem, das genau diesen Fehler verursachte.

Grund war ein Problem mit dem Linker oder der glibc (tut mir leid, ich weiß jetzt nicht mehr genau, was), welches dazu führte, dass keine 32bit libs eingebunden wurden (und nein, es geht nicht um $LDPATH).
Wie gesagt, ich kann mich an die Details leider nicht mehr erinnern, aber spontan würde ich deshalb vermuten, dass du ein Problem mit der Einbindung der 32bit-Support Pakete hast, insofern sie denn installiert sind.

Edit:
Du kannst mal ldd auf die Datei loslassen. Gibt das auch eine derartige Meldung aus?
Code:
ldd netio_linux-i386
.
EDIT :
.

Der Punkt geht schon, hat ja eine Bedeutung.
Aber wenn ich das richtig sehen fehlt der Datei die Ausführberechtigung: -rw-r--r-- gibt niemandem das Recht sie auszuführen.
Du brauchst +x nur, wenn du es direkt ausführen willst, also mittels ./shell-script.
Wenn du es über die shell direkt aufrufst, bzw. mittels source, dann reicht Leseberechtigung.
 
Erstmal danke allen die geantwortet haben. Ich schreibe hier in prosa meine Lösung hin in der Hoffnung das der nächste einfacher zum Ziel kommt.

Das .[leerzeichen]./xxxx ist die Methode mit der ich Programme starte die an sich keine Ausführungsrechte haben. Dabei ist es meines Wissen egal ob es Shellscripte oder binaries sind.

Reality-Check:

file /bin/dd ->
/bin/dd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

cp /bin/dd /tmp ; chmod 400 /tmp/dd ; cd /tmp
. ./dd -v
ELF: command not found

Wieder was dazu gelernt...


Ich hab jetzt mal x gesetzt, das Ergebnis hat sich aber nicht in der gewünschten Weise geändert.

root@hauptbenutzer:/tmp# ls -l | grep netio
-rwxr-xr-x 1 root root 14484 2010-04-26 21:36 netio_linux-i386

root@hauptbenutzer:/tmp# /tmp/netio_linux-i386
-bash: /tmp/netio_linux-i386: No such file or directory

root@hauptbenutzer:/tmp# file /tmp/netio_linux-i386
/tmp/netio_linux-i386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped

root@hauptbenutzer:/tmp# ldd /tmp/netio_linux-i386
not a dynamic executable


Update:

http://ppa.funzt-halt.net/pool/main/n/netio/netio_1.2.6-1_amd64.deb
dpkg -i netio_1.2.6-1_amd64.deb

root@hauptbenutzer:/tmp# netio

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

Usage: netio [options] [<server>]

-s run server side of benchmark (otherwise run client)
-b <size>[k] use this block size (otherwise run with 1,2,4,8,16 and 32k)

-t use TCP protocol for benchmark
-u use UDP protocol for benchmark
-h <addr> bind TCP and UDP servers to this local host address/name only
(default is to bind to all local addresses)
-p <port> bind TCP and UDP servers to this port (default is 18767)

<server> If the client side of the benchmark is running,
a server name or address is required.

The server side can run either TCP (-t) or UDP (-u) protocol or both
(default, if neither -t or -u is specified). The client runs one of
these protocols only (must specify -t or -u).


Funktioniert also. Es scheint das ich auf ein 64bittiges Riff aufgelaufen bin.

Wenn mir jemand verrät wie ich den Inhalt des deb Paketes genauer inspiziere kann ich es morgen aus der VM entlassen.
 
Wenn mir jemand verrät wie ich den Inhalt des deb Paketes genauer inspiziere kann ich es morgen aus der VM entlassen.
Code:
ar -x foo.deb


Schau dir doch mal das Shellscript zu ldd an.

Da müsste am Anfang etwas in der Art stehen:
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2"

Trag doch da mal provisorisch noch /lib32/ld-linux.so.2 ein und schau, ob dir ldd dann eine andere Ausgabe bringt.

BTW, der netio Befehl, den du da am Ende ausführst, ist das nun ein 64bit Programm?
Geht nach der Installation jetzt auch das lokale i386 netio, das vorher nicht ging?
 
Code:
ar -x foo.deb

cool... :-)


[/QUOTE][...] Trag doch da mal provisorisch noch /lib32/ld-linux.so.2 ein und schau, ob dir ldd dann eine andere Ausgabe bringt.[/QUOTE]

Gleiche Ausgabe.

BTW, der netio Befehl, den du da am Ende ausführst, ist das nun ein 64bit Programm?

root@hauptbenutzer:/tmp# which netio
/usr/sbin/netio
root@hauptbenutzer:/tmp# ldd /usr/sbin/netio
linux-vdso.so.1 => (0x00007fffe7391000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f223ceb5000)
libc.so.6 => /lib/libc.so.6 (0x00007f223cb46000)
/lib64/ld-linux-x86-64.so.2 (0x00007f223d0d1000)

Das war aus dem Namen ja auch erkennbar.

Geht nach der Installation jetzt auch das lokale i386 netio, das vorher nicht ging?

Nein, unverändert.
 
Ok, es gibt das wohl auch als 64bit Version. Dann nutze doch das. ;)

Wie gesagt, dir scheinen irgendwelche Datein für den multilib-Support zu fehlen. Genaueres kann ich dir aber auch nicht sagen, ist von Distribution zu Distribution ja verschieden.

Edit: Gibt es /lib32/ld-linux.so.2 eigentlich überhaupt auf deinem System?
 
Zuletzt bearbeitet:
evtl mal das paket linux32 installieren, da beinhaltet auch die 32bit libs wenn ich mich recht erinnere
 
linux32 ist schon installiert.


root@hauptbenutzer:~# linux32 /tmp/linux-i386
linux32: /tmp/linux-i386: No such file or directory

root@hauptbenutzer:~# ls -l /tmp/linux-i386
-rwxr-xr-x 1 root root 14484 2010-04-27 18:43 /tmp/linux-i386


Die 32Bit Libraries habe ich aber auch nicht gefunden.

root@hauptbenutzer:~# ls -l /lib32/*
ls: Zugriff auf /lib32/* nicht möglich: No such file or directory

Update:
apt-get install lib32stdc++6

war die Lösung des Problems.

Danke an alle die geholfen haben, Puck kriegt den ersten Platz in meinem Nachtgebet für den entscheidenden Tipp des heuten Tages, :-)

Das Ubuntu 9.10 in der Grundinstallation keine 32Bit Kompatiblität mitbringt war ein wenig unerwartet.
 
Zurück
Oben Unten