Kernel 2.6: ds26-14.3

[staubsauger-nono]

@kriegaex
danke, Link hat funktioniert.
Wo müsste ich denn die aktuelle DL-Adresse im Mod eintragen, damit sie automatisch gefunden wird?

 

[Darkyputz]

bin wohl etwas empfindlich heut morgen...aber auf diesem rotz karren (3200mhz) von intel iss das neubauen immer so laaaaangsam, das ich mal eben schnell mit dem patch ankürzen wollte...und die frage habe ich auch nur gestellt weil ich es für einen kosmetischen fehler hielt...da ich die pakete eh schon lange selbst per hand gedownt hatte...

denke das war ein fall von" vergessen wirs"

P.s. lang dabei heißt leider nicht mehr ahnung...bin leider noch immer ein hoffnungsloser linux noob in meinen augen...und froh das ihr immer so fleissig seit...

 

[ao]

Danke Alex, :groesste:

Läuft denn das make precompiled durch Deine Aufräumaktion noch schneller? (Ich kann's erst kommende Nacht testen...)

bin wohl etwas empfindlich heut morgen...aber auf diesem rotz karren (3200mhz) von intel iss das neubauen immer so laaaaangsam, ...

3200mhz langsam? Ich rödle hier mit 2.4 GHz herum, gähn.
Aber trotzdem: Komplett neu machen ist wohl wirklich besser, weil man dann wenigstens weiß, dass evtl. Fehler nicht durch's Patchen zustande kamen.

OT:
Bin froh, wenn mein MacBook Core 2 Duo da ist. Mit multijob sollte das Ganze dann ja ziemlich schnell gehen.
Und auf Leopard muss man ja jetzt nicht mehr warten. :-Ö

 

[staubsauger-nono]

ich bilde mir ein es läuft schneller.
Multijob auf Laptop 1,66MHz Core duo ca. 25 min (habe es nicht genau gestoppt, aber so ungefähr)

 

[kriegaex]

Ich denke nicht, daß es schneller läuft. Die Konfiguration ist nur etwas übersichtlicher geworden, speziell bei Iptables und JamVM/classpath.

 

[andreasz]

Hallo,

beim versuch ein DS-Mod für die 7170 zu erstellen bleibts beim Make in einer endlosschleife hängen :

tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
tools/ds_download: line 45: % 2 + 1 : syntax error: operand expected (error token is "% 2 + 1 ")
od: Ungültige Option -- D
,,od --help" gibt weitere Informationen.
make: *** [dl/mini_fo-dsmod-0.2.tar.bz2] Unterbrechung

 

[kriegaex]

Ist schon im Posting #1 unter "Probleme" gelistet, nicht gesehen? Das bedeutet, Du hast eine alte Version von GNU Coreutils. Workaround ist dort angegeben.

 

[andreasz]

Asche auf mein Haupt, nach der Update-orgie gehts, danke

Notiz für mich: erst lesen dann posten

 

[dileks]

Hallo kriegaex,

nach unserer privaten Korrespondenz hier nun mein erstes Feedback in IPPF (Premiere).

Nachdem ich schon mit einer früheren ds-mod-Version erfolgreich eine Firmware für die T-Com Speedport W701V gebaut und per Adam2-FTP-Service geflasht habe, musste ich die neue Version 14.3 ausprobieren.
Ich bin mit der neuen Namenskonvention des Patches d'Accord.
Ich hätte jetzt "ds-0.2.9_26-14.3" erwartet, aber der ist wirklich zu lang?
ds26-14.3 gefällt mir ;-).

Auch wenn viele Informationen schon an anderer Stelle zu finden sind, gibt es einige Feinheiten im Zusammenspiel von ds-mod und W701V zu berücksichtigen.
In diesem Posting schildere ich nun meine Vorgehensweise.

HINWEIS W701V:
Es handelt sich dabei um ein AVM-OEM-Produkt, vermutet wird eine FritzBox 7141.

TO-BE-PATCHED:
Leider lädt der Build-Prozess noch die alte TCom-W701V-Firmware v33.04.25 herunter.
Mit der 26er-Firmware funktionierte schon der 14.2er-ds-mod.
Meine verwendete dot-config-Datei ist diesem Posting (unten) angehängt.

Diese Zeile ist in .config (nach make menuconfig)...
DS_DL-SOURCE="fw_Speedport_W_701_V.33.04.25.image"
...zu ändern in...
DS_DL-SOURCE="fw_Speedport_W701V_V33.04.26.image"

HINWEIS BUSYBOX:
In Sektion Coreutils habe ich noch diff ausgewählt (vor make precompiled).

[bofh@friboli]$ make busybox-menuconfig

HINWEIS DS-MOD-PACKAGES:
Als Packages habe ich dropbear (SSH-Server) und syslogd (Protokollierung von Systeminformationen) ausgewählt.
Die Auswahl der Packages hat Einfluss auf die Grösse der Firmware-Datei.
Die Firmware (flashsize) der W701V darf bis zu 8 MByte gross sein.
Der verfügbare maximale Speicher (memsize) ist 32 MByte gross, der Rest (memsize abzüglich flashsize) kann z.B. für selbst-compilierte Programme genutzt werden.

HINWEIS BUILD-PROZESS:
Die zuvor für den 14.2er-ds-mod-Build-Prozess benötigten Dateien (Packages, Toolchain, TCom-Firmware etc.) lagen bereits in $HOME/ds-mod_dl vor.
Nur neuere Dateien wurden heruntergeladen.
Der Build-Prozess auf Basis der 25er- und 26er-TCom-W701V-Firmware laufen sauber durch.
Folgende Firmware-Image- und Kernel-Image-Datei wurden erzeugt:
"W701V_04.26-ds-0.2.9_26-14.de_20070418.image" mit 4,43 MByte (4.648.960 Byte) im ds-mod-Root-Verzeichnis
"kernel.image" mit 4,18 MByte (4.392.200 Byte) im Verzeichnis build/modified/firmware/var/tmp unterhalb vom ds-mod-Root-Verzeichnis

HINWEIS FIRMWARE-UPDATE ÜBER TCOM-WEBUI:
Leider konnte schon die mit 14.2er-ds-mod erzeugte 26er-Firmware nicht über die TCom-WebUI geflasht werden.
Ich vermute dass sowohl die T-Com als auch AVM inzwischen dem Modding bewusst einen Riegel vorschieben wollen.
Ähnliche Probleme melden Modding-Willige z.B. über die FritzBox 7050 mit Firmware-Version 14.04.30 und 14.04.31.
Meine Lösung nutzt das Flashen über den Adam2-FTP-Service (empfohlen nur für erfahrene User).

DISCLAIMER:
!!! KEINE HAFTUNG FÜR SCHÄDEN DIE BEIM/NACH FLASHEN GEMÄSS DIESER ANLEITUNG ENTSTEHEN (KÖNNEN) !!!

WARNUNG #1 ZUM FLASHEN ALLGEMEIN:
Wer wenig Erfahrung mit Flashen an sich und Linux hat, sollte das Flashen nicht wie hier aufgezeigt machen (evtl. Garantieverlust!!!).

WICHTIGE HINWEISE ZU ADAM2-FTP-SERVICE (KURZ A2FS):
Auf den Adam2-Bootloader kann per Passive-FTP-Protokoll über den sog. Adam2-FTP-Service (kurz A2FS) zugegriffen werden.
Nach dem Einloggen gibt es die Möglichkeit Konfigurationsdaten dauerhaft zu verändern, z.B. das sog. Branding oder den ADSL-Standard.
Im Zusammenspiel von Adam2-FTP-Service und Windows- bzw. Linux-Systemen gibt es Einiges zu berücksichtigen.

Nach Reboot der W701V steht der A2FS nur für einige Sekunden (2 bis 6 ping-Antworten) zum Einloggen zur Verfügung.
Der A2FS ist stets unter der IP-Adresse <192.168.178.1> erreichbar.
Ich erwähne das nur, da die W701V per Werkseinstellung (TCom-Firmware) auf die IP-Adresse <192.168.2.1> horcht.
Bei den AVM-FritzBox-Produkten horcht sowohl die FritzBox als auch der A2FS auf IP-Adresse <192.168.178.1>.
TIPP: Am besten in einem separaten Konsole-Fenster einen Dauerping starten....

CMD> ping -t 192.168.178.1
[bofh@friboli]$ ping -b 192.168.178.1

WICHTIGE HINWEISE ZU ADAM2-FTP-SERVICE UND WINDOWS-SYSTEM:
Einige Win32-FTP-Clients unterstützen kein sog. Passive-FTP, z.B. der in WinXP enthaltene FTP-Client.
Mit NcFTP-Client (win32-Version) klappte es bei mir nicht.
Allerdings ist ein telnet auf Port #21 geschwätziger.

CMD> telnet 192.168.78.1 21

Auch mit der Benutzung von TFtpd32-Server hatte ich keinen Erfolg.
Die Kernel-Image-Datei konnte nicht erfolgreich übertragen und somit geflashed werden (evtl. TFtpd32 von mir falsch konfiguriert).

WICHTIGE HINWEISE ZU ADAM2-FTP-SERVICE UND LINUX-SYSTEM:
Einfacher und sicherer ging es mir unter Linux.
Ein Linux-System kann auch unter Windows als sog. Virtuelle Maschine eingesetzt werden: Einfach FriBoLi mit VMware-Player benutzen (übrigens auch die Entwicklungs-Umgebung des Autors) !
Aber auch unter FriBoLi gab es mit einigen Linux-FTP-Clients Schwierigkeiten, z.B. NcFTP-Client (Linux-Version).
Mit dem Default-FTP-Client (/usr/bin/netkit-ftp) klappte es schliesslich.
HINWEIS FRIBOLI:
Mein FriBoLi-System läuft bereits auf Debian Etch (v4.0) mit aktualisierten Debian-Paketen.

[bofh@friboli]$ apt-get update && apt-get upgrade && apt-get dist-upgrade

Ich habe den FriBoLi-Linux-Kernel gegen den offiziellen 2.6.18er-Debian-Kernel mit SquashFS-Kernel-Modul ausgetauscht.

[root@friboli]# apt-get install linux-image-2.6.18-4-686
[root@friboli]# apt-get install squashfs-modules-2.6.18-4-686 squashfs-tools

Jetzt starten wir die Adam2-FTP-Session...

[bofh@friboli]$ ftp 192.168.178.1

Nach FTP-Login (USER: adam2 und PASS: adam2) muss BINARY, PASSIVE UND MEDIA_FLASH MODE gesetzt werden.

ftp> bin
ftp> passive
ftp> quote MEDIA FLSH

WARNUNG #2 ZU FIRMWARE-UPDATE-ÜBERTRAGUNG (KRITISCHER TEIL):
Vor dem Flashen wird stets empfohlen die Geräte auf Werkseinstellungen (Factory-Default) zu setzen.
Bei mir war es auch ohne Factory-Default erfolgreich.
Per put-Kommando wird die Kernel-Image-Datei "kernel.image" - nicht zu verwechseln mit Firmware-Image-Datei (s.w.o.) - auf die Partition mtd1 geflashed!!!
kernel.image ist übrigens ein TAR-Archiv, einfach mal umbenennen und entpacken.
Bis der eigentliche Datei-Transfer losgeht, dauert es ein paar Minuten.
Also Geduld und keine Panik (und hoffentlich kein Stromausfall)...

ftp> put ./ds-latest/build/modified/firmware/var/tmp/kernel.image mtd1
local: ./ds-latest/build/modified/firmware/var/tmp/kernel.image remote: mtd1
227 Entering Passive Mode (192,168,178,1,5,45)
150 Opening BINARY data connection
226 Transfer complete
4392200 bytes sent in 18.98 secs (226.0 kB/s)

WICHTIGER HINWEIS ZU BRANDING UND WEBUI:
Nach erfolgreichem Flashen wird die TCom-WebUI durch die von AVM mit erweitertem Funktionsumfang und neuen Konfigurationsmöglichkeiten ersetzt!
Im Build-Prozess ist per Default das Branding auf "tcom" gesetzt.
Ich hatte das Branding jedoch manuell auf "avm" gesetzt, so bekam ich nach dem Flashen gar keine WebUI zu Gesicht.
Mein Internet-Zugang über LAN funktionierte dennoch auf Anhieb (kein Factory-Default vor dem Flashen und Branding "avm").
Falls das Branding auf "tcom" geändert werden muss (in meinem Fall auch nachträglich)...

ftp> quote GETENV firmware_version
ftp> quote SETENV firmware_version tcom

If you have to change the ADSL-Standard (e.g. Italy requires Annex A)...

ftp> quote GETENV annex
ftp> quote SETENV annex A

Eventuell soll die W701V auf eine andere IP-Adresse horchen...

ftp> quote GETENV my_ipaddress
ftp> quote SETENV my_ipaddress 192.168.178.1

Reboot der W701V und Ende der Adam2-FTP-Session...

ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
ftp> quit
221 Goodbye

Nach dem Reboot sollte die W701V die neuen Konfigurationsdaten dauerhaft übernommen haben.
Die ds-mod-WebUI sollte jetzt unter http://192.168.178.1:81 (Default-HTTP-Port #81) erreichbar sein.
telnetd (Telnet-Daemon) starten.
Als unmittelbar nächster Schritt sollten für die AVM-WebUI und ds-mod-WebUI neue (sichere) Passwörter vergeben werden.
Dazu loggt man sich auf die W701V per SSH (Port #22) oder Telnet (Port #23) ein, z.B. mit PuTTY unter Windows.
Den Reboot nicht vergessen!

[root@w701v]# modpasswd
[root@w701v]# modpasswd dsmod
[root@w701v]# reboot

That's it, folks.

Dickes Lob an die Macher der neuen ds-mod-Version,
insbesondere an kriegaex, der stets kompetent, schnell und zu (sehr!) später Stunde meine Fragen beantworten konnte,
dileks

 

[dileks]

Auch wenn es schon von kriegaex empfohlen wurde, hier noch mal explizit als eigenständiges Posting.

TIPP:
Die für den ds-mod-Build-Prozess notwendigen Dateien (Packages, Toolchain, etc.) kann man separat in ein Verzeichnis herunterladen/kopieren und dort belassen.
Einen symbolischen Link setzen und fertig.
Dadurch wird nicht nur der Internet-Traffic gemindert, sondern der Build-Prozess beschleunigt, da nicht immer wieder die gleichen Dateien herunterzuladen sind.
HINWEIS:
Im Verzeichnis $HOME/ds-mod_dl liegen meine "wget-Dateien".

[bofh@friboli]$ cd $HOME
[bofh@friboli]$ tar -xjvf ds-version.tar.bz2
[bofh@friboli]$ ln -s ds-version ds-latest
[bofh@friboli]$ cd ds-latest
[bofh@friboli]$ ln -s ../ds-mod_dl dl

DOWNLOAD-LINK:
http://dsmod.3dfxatwork.de/

 

[joelxy]

fakeroot Fehler

Hallo

Ich bekomme beim make einen fakeroot Fehler. (Für das Ziel all ist nichts zu tun)
Ich habe im Forum gesucht und folgendes gefunden:

http://www.ip-phone-forum.de/showthr...light=fakeroot

Ich denke das entspricht dem Fehler. Das friboli ist auf dem neuesten Stand und ein 'apt-get install coreutils' gibt an, das ich die neueste Version habe.
Versuche den mod für die 7050 zu bauen.
Ist vielleicht nur eine Kleinigkeit die ich übersehe.
Habe mal die Ausgabe mitangehängt. Danke und Grüße

Joel!

 

[kriegaex]

@joelxy: Kurze Vorab-Info: Das ist ein völlig anderer Fehler. Die Meldungen sehen sich nicht mal ähnlich, außerdem ist das andere Problem ja gelöst. Mehr Info folgt später von olistudent oder mir.

 

[dileks]

Problem ist von kriegaex bereits gefixt (s.w.o).
-dileks

Was heisst konkret?

Das friboli ist auf dem neuesten Stand...

Möglicherweise behebt das dein Problem...

[root@friboli]$ apt-get update && apt-get upgrade

Schick mal folgende packages.txt (Liste deiner installierten Debian Pakete)...

[root@friboli]$ env COLUMNS=200 dpkg -l >/root/packages.txt

Stell mittels "make menuconfig" in Advanced-Options den Verbosity Level auf 2 (sehr geschwätzig)?
Schick die dot-config.

Beschreib mal, wie du den Build-Prozess einleitest.

Am besten du schickst mir noch "make_precompiled.out.gz" und "make.out.gz", damit man einfacher nachvollziehen kann, was gelaufen ist.

[bofh@friboli]$ make menuconfig
[bofh@friboli]$ make precompiled >make_precompiled.out 2>&1
[bofh@friboli]$ make >make.out 2>&1
[bofh@friboli]$ gzip -9c make_precompiled.out >make_precompiled.out.gz
[bofh@friboli]$ gzip -9c make.out >make.out.gz

 

[joelxy]

Hallo dileks,

danke das
apt-get update && apt-get upgrade

brachte den erwünschten Erfolg.

Gruß Joel!

 

[kriegaex]

Nochmal zur Bftpd-Download-Adresse:

danke, Link hat funktioniert. Wo müsste ich denn die aktuelle DL-Adresse im Mod eintragen, damit sie automatisch gefunden wird?

Ist längst als Workaround beschrieben in Posting #1, hatte nur Deine Nachfrage nicht gleich gesehen.

 

[kriegaex]

Exkurs ins Makefile-Land (kleines Lehrstück)

Nachdem ja, abgesehen vom der einen zunächst im Mod-Paket fehlenden Datei, die von den Frühaufstehern schmatke und dsteinkopf entdeckt wurde und die ich nachgeliefert habe für alle, die jetzt den Download ziehen, bisher kein Fehler mehr gemeldet wurde und sich alles andere in Wohlgefallen aufgelöst hat (alte FriBoLi- oder GNU-Coreutils-Versionen, fehlende Ausführungsrechte auf eingepatchte Dateien etc.), möchte ich Euch einen subtilen kleinen Fehler zur Unterhaltung präsentieren, der von uns keinem auffallen würde und nur auftritt, wenn man ds26 benutzt, um gar keinen ds26 zu bauen, sondern stattdessen nur die Tools wie unsquashfs verwenden möchte, so wie dort auf meine eigene Anregung hin geschehen.

Situation
Anwender X zieht sich ds26, entpackt ihn und ruft make tools auf, damit der die SquashFS-Werkzeuge gebaut kriegt. Nun gehören laut Makefile ja die Tools zu der Gruppe von Make-Targets, welche keinen vorherigen menuconfig benötigen:

[B]noconfig_targets:=[/B]menuconfig config oldconfig defconfig [B]tools[/B]

Kein menuconfig bedeutet aber auch: keine Datei .config. Darauf komme ich gleich nochmal zurück.

Seit einigen Wochen gehört zur Gruppe der Build-Tools aber auch eine Busybox, und zwar dieselbe Version, die auch für die Fritz!Box gebaut wird. Nur wird sie eben in ihrer zweiten Inkarnation als Werkzeug für den Build benutzt, um bspw. die LZMA-komprimierten Download-Toolchains zu entpacken. (Nebenbei: Weil die TCs so riesig sind, wurden sie LZMA-komprimiert, weil sie dadurch nochmal deutlich kleiner werden als bzip2-komprimierte Archive.) Wie auch immer, wir haben Busyboxen für zwei unterschiedliche Systeme, die aber aus den gleichen Quellen gebaut werden.

Symptom
Hier fängt das (zunächst rein kosmetische) Problem an: Wenn nun sowohl in make/busybox/busybox.mk als auch in tools/make/busybox-tools.mk jeweils das hier

$(DL_DIR)/$(BUSYBOX_SOURCE):
    wget -P $(DL_DIR) $(BUSYBOX_SITE)/$(BUSYBOX_SOURCE)

steht, um zu gewährleisten, daß sowohl das Target busybox-precompiled als auch das Target busybox-tools jeweils bei Bedarf das Quellcode-Archiv dl/busybox-1.4.1.tar.bz2 herunterladen können, spuckt fortan z.B. make precompiled immer Folgendes aus:

make/busybox/busybox.mk:15: Warnung:
  Die Befehle für das Ziel dl/busybox-1.4.1.tar.bz2 werden berschrieben
tools/make/busybox-tools.mk:14: Warnung:
  Alte Befehle für das Ziel dl/busybox-1.4.1.tar.bz2 werden ignoriert

Symptom bekämpfen
Was tun wir also als Entwickler? Wir kommentieren das Target an einer Stelle - sagen wir, bei der Tools-Busybox - aus und sind glücklich, denn fortan erscheint beim Bauen von Paketen und FW-Images die Warnung nicht mehr und alles funktioniert wie geplant. ABER.

Seiteneffekt
Exkurs: Im DS-Mod arbeiten wir, gemäß den Empfehlungen aus Peter Millers "Recursive Make Considered Harmful", nicht mit rekursiv aufgerufenen Makefiles, sondern stattdessen mit einem großen (virtuellen) Master-Makefile, welches sich dynamisch aus dem Wurzel-Makefile und den von ihm nachgeladenen Includes (*/Makefile.in + *.mk) zusammensetzt. Erst, wenn die Grenzen des Mods verlassen werden müssen, um externe Pakete zu kompilieren, werden weitere unabhängige Build-Prozesse angestoßen.

Das soeben Geschriebene bedeutet aber, daß der Mod-Build im Normalfall alle Targets sieht, und das ist gut so. Dadurch fiel uns ja oben überhaupt auf, daß es zwei Targets gab, welche die Busybox-Quellen herunterladen wollten. Diese Redundanz haben wir dann durch Auskommentieren eines Downloads beseitigt. Leider haben wir uns damit folgendes Problem eingekauft, welches bei einem frisch entpackten Mod auftritt (oder auch, wenn wir einfach mal dl/busybox-1.4.1.tar.bz2 löschen):

make: *** Keine Regel vorhanden, um das Target dl/busybox-1.4.1.tar.bz2, 
  benötigt von source/busybox-host/.unpacked, zu erstellen.  Schluss.

Ursachenforschung und Problemlösung
Das Download-Target aus make/busybox/busybox.mk wird nicht gefunden. Wieso eigentlich? Als wir vorhin die andere Busybox bauen wollten, waren doch sogar zwei da, bis wir die Tools-Busybox-Regel auskommentiert hatten. Ein Blick ins Wurzel-Makefile zeigt:

[B]ifeq ($(strip $(DS_HAVE_DOT_CONFIG)),y)[/B]
(...)
include $(MAKE_DIR)/Makefile.in
[B]include $(MAKE_DIR)/*/Makefile.in[/B]
(...)

Die Makefile-Includes für die Mod-Pakete werden also nur dann geladen, wenn die Variable DS_HAVE_DOT_CONFIG den Wert y hat. Dies scheint im Falle von make tools nicht der Fall zu sein, wie sich an anderer Stelle bestätigt: Die Variable ist Bestandteil von .config und wird während der Menükonfiguration (make menuconfig) erstellt. Nun gehören die Tools aber doch gerade zu den noconfig_targets, wie wir zu Beginn festgestellt hatten. Und für diese Targets wird .config überhaupt nicht geladen:

ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
-include $(TOPDIR)/.config
endif

Kein Wunder also, daß make tools nicht das Download-Target der Busybox für die Fritz!Box kennt.

Nehmen wir also das ifeq ... endif außen herum weg, so daß .config immer geladen wird:

#ifeq ($(filter $(noconfig_targets),$(MAKECMDGOALS)),)
-include $(TOPDIR)/.config
#endif

Leider bleibt die Fehlermeldung die gleiche, denn offenbar gibt es kein Target .config, welches menuconfig automatisch startet, falls die Datei nicht vorhanden ist. Dieses Target müßten wir im Grunde nachrüsten und auch die Tools-Targets davon abhängig machen. Aber vernachlässigen wir das für einen Moment und rufen make menuconfig selbst auf. Nichts ändern, einfach wieder verlassen und abspeichern, fertig. Danach existiert .config, und die Datei enthält auch immer die mit dem Wert y versehene Variable DS_HAVE_DOT_CONFIG.

Jetzt sollten wir alles Notwendige haben. Wagen wir es erneut:

make tools

Nun startet der Busybox-Download und alles geht seinen Gang: Die Tools werden gebaut, die anderen, weniger problematischen Downloads funktionieren auch, da sie nicht von Bedingungen abhängen bzw. nicht einfach auskommentiert wurden.

Fazit (lessons learned)

• Bekämpfe Ursachen, nicht Symptome!
• Baue nicht nur keine rekursive Makefile-Struktur auf, sondern verzichte nach Möglichkeit auch auf If-Bedingungen um Include-Befehle herum. Eine saubere Build-Struktur sollte unter allen Bedingungen funktionieren, wenn alle Includes geladen sind. Ansonsten werden mögliche Probleme nur unter bestimmten Umständen eintreten, welche dann schwer nachvollziehbar sind. Wenn es kracht, dann besser sofort, damit es weh genug tut, um die Problemursachen gleich zu beseitigen.
• Debugging ist spannend! (Es kostet aber trotzdem Zeit.)

Postskriptum: Da ich nicht die gesamte Build-Struktur wegen dieser Kleinigkeit umbauen werde, behebe ich das Problem mit einer Fallunterscheidung, welche das Download-Target in tools/make/busybox-tools.mk bei Bedarf aktiviert. Das ist nicht ideal, sorgt aber dafür, daß das Target in beiden Fällen verfügbar ist, und zwar jeweils genau einmal, also ohne Warnungen (2x vorhanden) und ohne Folgefehler (0x vorhanden).

 

[ao]

Wow, der Scrum-Master hat gesprochen! :groesste:

Aber jetzt mal eine evtl. blöde Frage von mir Linux-Noob:
Habe ich Dich richtig verstanden, dass man den ds-mod auch zum Entwickeln anderer Linux-Geschichten nutzen kann?
Wobei, Du meinst wohl nicht den ds-mod an sich, sondern die Toolbox, oder habe ich jetzt gar nichts verstanden?

Spontan fällt mir die M740-Box (DVB-T Receiver auf Linux-Basis) ein, auf die der VDR portiert wurde und wofür noch eine ganze Menge Plugins zu kompilieren sind. Ginge das damit?

 

[kriegaex]

Mit dem DS-Mod (z.B. ds26) als Framework, egal ob mit selbst gebauten oder vorkompilierten Download-Toolchains, kannst Du auch andere Software für die Box bauen, ja. Siehe Wiki-Kurzanleitung (manchmal wird's schon komplizierter als neu übersetzen, aber im Grunde stimmt das so).

 

[ao]

Cool, das muss ich mal wirklich für die M740 versuchen. Ob die Plattform und CPU passen, weiß ich noch nicht...

Die Toolchain habe ich inzwischen hier gefunden: http://dsmod.3dfxatwork.de
Der Link im ersten Beitrag scheint sich inzwischen geändert zu haben.

 

[kriegaex]

ds26-14.3 kennt bereits zwei Mirrors (ein dritter ist gerade in Vorbereitung, ein vierter kommt auch bald), Du mußt einfach Advanced Options -> Compiler Options ->Download and use precompiled toolchain auswählen und danach den Mod bauen. Oder Du machst explizit ein make download-toolchain.