7050-Fon-Wlan - ERROR: could not create link for /bin/logger

raik · 29 Mai 2007

Ich hatte folgende Fehlermeldung bei make:

STEP 2: MODIFY
applying patches
...
installing symlinks
./fwmod: line 858: ./ln: cannot execute binary file
ERROR: could not create link for /bin/logger
make: *** [firmware] Fehler 1

Ich habe dann in ./fwmod die Zeile 858 von
( ln -sf "$BUSYBOX_PATH" "$LINK_NAME" ...
auf
( /bin/ln -sf "$BUSYBOX_PATH" "$LINK_NAME"...
geändert und make lief erfolgreich durch.

olistudent · 29 Mai 2007

In deiner Fehlermeldung steht "./ln" und in fwmod steht "( ln -sf...)"? Wie kann denn das sein? Normalerweise sollte doch /bin im Pfad sein?

MfG Oliver

kriegaex · 29 Mai 2007

V.a. sollte normalerweise "." nicht im Pfad sein, v.a. nicht als einziges Verzeichnis.

raik · 29 Mai 2007

Ich lasse gerade nochmal alles neu durchlaufen.
Wenn es fertig ist, melde ich mich nochmal.

kriegaex · 29 Mai 2007

Kannst Du etwas dazu sagen, ob und was Du evtl. mit dem Pfad angestellt hast?

raik · 29 Mai 2007

Ich habe das Paket
ds26-14.4.tar.bz2
am 28.5.07 ca. 16Uhr von
http://www.ip-phone-forum.de/showthread.php?t=135307
Post #1
genommen.

>tar xvf ds26-14.4.tar
>cd ds26-14.4
>make menuconfig

(Ich habe hier nur meine Änderungen angegeben.)
--- General
Hardware type (Fon WLAN 7050) --->
Firmware language (de - deutsch) --->
--- Brandings
- [*] 1&1 (NEW)
- [ ] AVM
--- Patches
- [*] Remove help
- [*] Remove assistant
- [*] Remove libtr069 (EXPERIMENTAL!)
- [*] Remove avalanche_usb.ko (EXPERIMENTAL!)
- [*] Patch enum
- [*] Patch web menu signed message
--- Mod
Language (de - deutsch) --->
Package selection --->
- [*] Callmonitor 1.9.1
- [*] Dnsmasq 2.38
- [*] Wake-on-LAN (WoL) CGI 0.5
Advanced options --->
- [*] Override firmware source
- (fritz.box_fon_wlan_7050.14.04.33.image) Firmware source
- (2) Verbosity level (0-2)
---

>make precompiled
(läuft ca. 30min auf EPIA EN1300)

>make
gibt dann folgenden Fehler aus:

STEP 2: MODIFY
applying patches
applying patches (7050-de)
patching file etc/profile
patching file usr/bin/system_status
patching file etc/init.d/rc.net
patching file etc/init.d/rc.S
Hunk #1 succeeded at 252 with fuzz 1 (offset -97 lines).
patching file etc/init.d/rc.S
patching file etc/fstab
patching file usr/www/all/html/de/fon/foncalls.js
Hunk #1 FAILED at 3.
1 out of 2 hunks FAILED -- saving rejects to file usr/www/all/html/de/fon/foncalls.js.rej
make: *** [firmware] Fehler 2

Mit

>nano patches/7050/130-foncalls.patch

und Ändern der Zeilen
#tClient td {padding: 2px; overflow: hidden}
#tClient th {padding: 2px; overflow: hidden}
in
#tClient td {padding: 2px; overflow: hidden; height: 24px;}
#tClient th {padding: 2px; overflow: hidden;}

habe ich den beseitigt.

>make
bringt dann den Fehler:

...
replacing busybox-4mb_26
installing symlinks
./fwmod: line 859: ./ln: cannot execute binary file
ERROR: could not create link for /bin/logger
make: *** [firmware] Fehler 1

Den beseitige ich mit

>nano fwmod

durch Ändern der Zeile 858 von
( ln -sf "$BUSYBOX_PATH" "$LINK_NAME" ...
auf
( /bin/ln -sf "$BUSYBOX_PATH" "$LINK_NAME"...

>make
läuft dann fehlerfrei durch.

STEP 3: PACK
Checking for left over Subversion directories
squashfs blocksize
hidden squashfs: 65536
root filesystem: 65536
packing var.tar
creating filesystem image
merging kernel image
kernel image size: 3792640 (max: 3866624)
packing 7050_04.33-ds-0.2.9_26-14.de_20070529.image
done.

FINISHED
>

Das Problem mit dem ln -sf in Zeile 858 hatte ich mal nachvollzogen, indem ich die Scipt-Variablen ausgegeben habe:

${FILESYSTEM_MOD_DIR}${LINK_DIR} = build/modified/filesystem/bin
$BUSYBOX_PATH = busybox
$LINK_NAME = logger

Der ln-Befehl wird im Verzeichnis build/modified/filesystem/bin
ausgeführt und funktioniert nicht, da dort das ln->busybox der fritzbox steht.

hermann72pb · 29 Mai 2007

kannst du bitte deine erfogreiche .config hier oder dort posten. Ich sammele sie. Und benutze bitte CODE-Tag

MfG

kriegaex · 29 Mai 2007

Ergänzung: Benutze das Code-Tag, wenn Du etwas inline schreibst. Konfigurationen (.config) u.a. größere Dateien sind aber am besten als Dateianhang aufgehoben (.txt anhängen, damit der Upload akzeptiert wird, bei größerden Sachen als komprimiertes Archiv anhängen).

Weshalb das Busybox-ln bei Dir ausgeführt wird, ist mir schleierhaft. Gib mal bitte $PATH und $PWD aus an der Stelle, wo das gefunden und aufgerufen wird.

raik · 29 Mai 2007

Anbei meine erfolgreiche .config

Anhang anzeigen config.txt

Die Variablen ergeben:
$PATH
:.:/home/raik/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

$PWD
/home/raik/ds26-14.4

und sind in fwmod vor der originalen Zeile 858 eingefügt.

Code:

			esac
echo $PATH
echo $PWD
			( cd "${FILESYSTEM_MOD_DIR}${LINK_DIR}" &&
			  ( ln -sf "$BUSYBOX_PATH" "$LINK_NAME" || ( echo "ERROR: could not create link for $link" 1>&2; exit 1 ) ) ) || exit 1

Übrigens möchte ich an dieser Stelle dem Forum und den Entwicklern mal danken.
Ich verneige mich vor Eurer Software.
Gruß raik

derheimi · 29 Mai 2007

:.:/home...

Das erklärt das ganze natürlich. Irgendwie erinnert mich das an (open)Suse?! Dort konnte man irgendwo dieses "Feature" anklicken, dass zuerst im aktuellen Verzeichnis gesucht werden soll (vermutlich, um es Windows-Umsteigern einfacher zu machen).
@raik:
Welche Distri nimmst Du denn? Das ist doch nicht FriBoLi, oder doch?
@kriegaex,olistudent:
Es würde ja eigentlich nichts schaden, wenn man den Suchpfad daraufhin testet und den Eintrag für das aktuelle Verzeichnis ggf. an letzte Stelle verschiebt - oder gar ganz rauslöscht. Will damit nur sagen, dass ev. auch andere Leute mit so einem Pfad unterwegs sein könnten.

kriegaex · 29 Mai 2007

Tja, das Ganze hätten wir uns sparen können, ich habe ja schon in Beitrag #3 geschrieben, daß das nicht sein darf. Es wäre schön, wenn Hilfestellungen auch gelesen und befolgt würden, wenn sich schon jemand darum bemüht und dann weiter unten nochmals (#5) und nochmals (#8) nachfragt.

Den Pfad prüfen und umbauen werde ich auch nicht, denn das ist nicht üblich. Wenn schon, wird ein Pfad vorne oder hinten erweitert, nicht sonstwie umgebaut. Es könnte ja jemand etwas Sinnvolles mit dem Pfad vorhaben, da mische ich mich nicht ein.

raik · 29 Mai 2007

Ich bin bei Debian4.0. Vielleicht sind die Pfade sogar noch von 3.1 - ich weiß gar nicht mehr, wie ich umgestellt habe.

Ich habe gerade mal meine anderen Debian-Rechner angesehen - die sind alle mit ":.:".
Doch, ich bin immer von 3.1 nach 4.0 gewechselt. Ich glaube aber nicht, daß das bei einer Neuinstallation anders aussieht.

Gruß raik

kriegaex · 29 Mai 2007

Nimm "." aus dem Pfad, dann brauchst Du diesen seltsamen Patch nicht.

raik · 29 Mai 2007

Wie derheimi schon sagte, wird der ":." an Anfang von PATH gar nicht so selten sein. Wo ich mir den Schiß auf 3 Debian-Installationen eingefangen habe, kann ich nicht mehr nachvollziehen.
Auf einer ziemlich frischen Debian4.0 ist der Schiß jedenfalls nicht vorhanden.

@kriegaex
Tut mir leid, wenn ich Deine Hinweise nicht richtig verstanden habe.
#13 ist unmißverständlich.

Gruß raik

derheimi · 29 Mai 2007

kriegaex schrieb:
Den Pfad prüfen und umbauen werde ich auch nicht, denn das ist nicht üblich. Wenn schon, wird ein Pfad vorne oder hinten erweitert, nicht sonstwie umgebaut. Es könnte ja jemand etwas Sinnvolles mit dem Pfad vorhaben, da mische ich mich nicht ein.

Also Fakt ist doch folgendes: der Pfad kann von jedem so gesetzt werden, wie sein System es erfordert oder seine "Vorlieben" sind. Es gibt da keinen Standard, obwohl eine bestimmte Reihenfolge sinnvoll ist. Die meisten Distributionen kommen mit so einem sinnvollen Default als Voreinstellung.

Bei meinen Debian 3.1 bzw. 4.0 Installationen ist der aktuelle Pfad nirgens mit drin. Und für sinnvoll halte ich das auch nicht, aber es ist eine durchaus "legale" Konfiguration, egal wie sie entstanden ist.

Ich sehe diese Möglichkeiten:
1) in der Dokumentation des dsmod wird darauf hingewiesen, dass diese Pfadvariante Probleme macht,
2) der Dsmod fängt das Problem ab, entweder durch
2a) wie oben vorgeschlagen (Manipulation Pfad),
2b) absolute Pfade bei Aufrufen (nicht wirklich!),
2c) explizites Setzen eines Pfades,
3) FriBoLi wird als einzig wahre Referenz-Distri für den dsmod festgelegt, dann kann jede Support-Anfrage sofort mit entsprechenden Hinweis abgehandelt werden.

kriegaex · 30 Mai 2007

Gehen wir doch nochmals zurück zum Anfang (sprich: Beitrag #1):

Code:

./fwmod: line 858: ./ln: cannot execute binary file
ERROR: could not create link for /bin/logger
make: *** [firmware] Fehler 1

Geht es noch klarer? Die Fehlermeldung gibt an:

Skriptname
Zeile
Problemursache (./ln)
Konsequenz 1 (Binärdatei kann nicht ausgeführt werden)
Konsequenz 2 (Link kann nicht erzeugt werden)
Konsequenz 3 (Firmware kann nicht gebaut werden)

Das Problem ist gelöst, die Ursache hier im Thread ge- und erklärt. Man kann also im Forum danach suchen. Um das Ganze noch ein wenig sicherer zu machen, werde ich es im Beitrag #1 des jeweils aktuellen Release-Threads zu ds26 als FAQ erwähnen (bereits erledigt), auch wenn es im Grunde überflüssig ist. Ich hoffe, das ist zufriedenstellend.

danisahne · 30 Mai 2007

Ich finde das explizite setzen des Pfades in fwmod die schönste Lösung. Einfach ein

Code:

export PATH=/bin:...usw

an den Anfang des Skripts oder besser noch im Top-Level Makefile.

Mfg
danisahne

raik · 30 Mai 2007

@kriegaex
Könntest Du bitte im FAQ das Pfad in PATH ändern?
Das dürfte von Normalbenutzern eher richtig verstanden werden.
Gruß raik

kriegaex · 31 Mai 2007

Es gibt doch einen Link auf diesen Thread.

7050-Fon-Wlan - ERROR: could not create link for /bin/logger

Neuer User

IPPF-Urgestein

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

IPPF-Promi

Aktives Mitglied

Neuer User

Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Mitglied

Aktives Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Statistik des Forums