Die aktuellen WIKI-Seiten zu FREETZ befinden sich auf www.freetz.org. Alle Aktualisierungen und Änderungen werden nur dort eingepflegt! Bitte dieses WIKI nicht mehr ergänzen!
Aktuelle Howtos befinden sich auf www.freetz.org!
Sammlung von Howtos und Kurztipps rund um Freetz (ehemals ds-mod).
Dies kann ohne großen Aufwand über das Verzeichnis ./root/ realisiert werden. Einfach die gewünschten Dateien in das Verzeichnis ./root/ an die Stelle kopieren, an der sie im root Dateisystem der Box landen sollen (außer ./root/lib/ und ./root/usr/lib/, welche seperat behandelt werden). Beispiel: eine Datei ./root/usr/bin/foo wird auf der Box in /usr/bin/foo landen.
Wenn die Box nicht mehr ansprechbar ist, die Power LED leuchtet und die übrigen LEDs in regelmäßigen Abständen aufblinken, dann kann folgende Vorgehensweise die Box wieder zum Leben erwecken. In diesen Fällen ist meist mtd0 (Filesystem) und mtd1 (Kernel) betroffen, nicht mtd3 / mtd4 (mtd2 auf KEINEN Fall anrühren).
make recover
Am bequemsten funktioniert es, wenn nach einem `make' der ds-mod noch nicht mit `make clean', `make dirclean' oder `make distclean' bereinigt wurde und noch eine für die Box passende Konfiguartion des Mods vorhanden ist. In diesem Fall lädt `make recover' die unmodifizierte original Firmware auf die Box.
Das Erstellen eines Cross-Compilers ist mit dem ds-mod denkbar einfach:
make menuconfig
Hier unter „Advanced options“ > „Compiler options“ die Optionen für den Cross-Compiler wählen. Soll der Compiler Programme für eine mit dem ds-mod erzeugte Firmware kompilieren, so ist in der Regel nichts zu ändern. Soll der Compiler hingegen für eine originale Firmware kompilieren können, so solltest du bei „uClibc config“ die entsprechende Konfiguration auswählen. ACHTUNG: Im zweiten Fall sollte diese entpackte Instanz des ds-mod nicht mehr zum Erstellen von Images verwendet werden, sondern nur noch der Cross-Compiler selbst.
make toolchain
Eine ganze Weile und ca 2 GB später wurden zwei Cross-Compiler erstellt:
make libs
Erstellt alle im menuconfig ausgewählten Libraries und installiert deren Header.
make menuconfig
Wähle deinen Boxtyp (Type) und die gewünschten Pakete aus, denn es werden nur die vorkompilierten Programme der aktuellen ds-mod Konfiguration kompiliert.
make precompiled
Dies erstellt sowohl die Toolchain (falls noch nicht geschehen) und alle für deine Konfiguration benötigten vorkompilierten Programme und den Kernel.
Vorraussetzung ist eine Toolchain (siehe Cross-Compiler / Toolchain erstellen). Sollten jemals Probleme mit nicht vorhandenen Verzeichnissen auftauchen, so kann ein
make world
Abhilfe schaffen. In der Regel sollte das aber nicht nötig sein.
make kernel-dirclean
Löscht den aktuell entpackten Source Tree des Kernels (wir werden von komplett sauberen Kernel Sourcen kompilieren; wer das nicht will, kann es mit `make kernel-clean' versuchen)
make kernel-menuconfig
Die Konfiguration des Kernels wird danach wieder nach ./make/linux/Config.<kernel-ref> zurückgespeichert
make kernel-precompiled
Nun werden der Kernel und die Kernel Module kompiliert:
Vorraussetzung ist eine Toolchain (siehe Cross-Compiler / Toolchain erstellen). Sollten jemals Probleme mit nicht vorhandenen Verzeichnissen auftauchen, so kann ein
make world
Abhilfe schaffen. In der Regel sollte das aber nicht nötig sein.
make busybox-dirclean
Löscht die aktuell entpackten Sourcen der Busybox (wir werden von komplett sauberen Busybox Sourcen kompilieren; wer das nicht will, kann es mit `make busybox-clean' versuchen)
make busybox-menuconfig
Die Konfiguration der Busybox wird danach wieder nach ./make/busybox/Config.<target-ref> zurückgespeichert
make busybox-precompiled
Dies kompiliert die Busybox und aktualisiert:
Bei dringenden oder kleinen Änderungen / Neuerungen werden passend zum letzten Release so genannte Patches angeboten. Diese Patches haben einen Dateinamen ähnlich diesem: ds26-x.y-patch-name.patch.bz2. Der Patch muss nach dem Entpacken des zugehörigen ds-mod ds26-x.y.tar.bz2 und vor dem Erstellen des Image eingespielt werden. Folgende Anleitung geht davon aus, dass beide Dateien im aktuellen Verzeichnis liegen:
tar -xvjf ds26-x.y.tar.bz2
bunzip2 ds26-x.y-patch-name.patch.bz2
patch -p0 < ds26-x.y-patch-name.patch
Nun ist der Patch in den entpackten ds-mod eingespielt und man kann mit dem Erstellen des Image fortfahren.
Pakete, die noch nicht in den Mod integriert sind, können als sogenanntes „Addon Paket“ installiert werden. Dazu das gewünschte Paket vor dem Erstellen des Image herunterladen und nach ./addon entpacken. Folgendes Beispiel geht davon aus, dass man sich im Verzeichnis des entpacken ds-mod befindet:
tar -C addon -xjvf /pfad/zu/addon-paket-0.1-dsmod.tar.bz2
Danach muss das Paket in der Liste ./addon/static.pkg in eine neue Zeile eingetragen werden (im obigen Beispiel: addon-paket-0.1). Addon Pakete werden nach den integrierten Paketen in der Reihenfolge des Auftretens in ./addon/static.pkg gestartet.
Nachdem die Toolchain heruntergeladen oder gebaut wurde, kann sie verwendet werden, um eigene Programme, oder solche, die noch nicht als Paket zur Verfügung stehen, zu übersetzen.
Den MIPS-Compiler zum Pfad hinzufügen:
export PATH=/pfad/zu/dsmod/toolchain/target/bin:$PATH
Optionen für ./configure:
./configure --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux
(i386-linux-gnu ist nicht unbedingt notwendig, nur beschwert sich configure, wenn es nicht angegeben ist. Auf 64-Bit-Plattformen oder Nicht-Intel-Architekturen muß es natürlich anders heißen.)
Statisches Linken der Binaries, damit sie keine separaten Libraries benutzen, sondern sie gleich enthalten (funktioniert aber nicht bei jeder Software):
LDFLAGS=-static ./configure ...
Statisch gelinkte Binaries sind einfacher zu installieren, weil sie eben alles enthalten, aber dadurch sind sie größer, und wenn sie mit anderen Programmen gemeinsam genutzte Funktionalität haben, verschwenden sie Speicherplatz. Außerdem müssen sie separat upgedatet werden, wenn z.B. in einer Library eine Sicherheitslücke gepatcht wurde. Es ist also am besten, statische Binaries nur zum Testen, oder wenn es anders nicht geht, zu verwenden.
In manchen Fällen ist es ratsam die CC-Variable explizit zu setzen. Auch die Angabe der CFLAGS kann nicht schaden:
./configure ... CC="mipsel-linux-gcc" CFLAGS="-Os -pipe -march=4kc -Wa,--trap"
Die Datei root/usr/lib/libmodcgi.sh muss um einen Hyperlink erweitert werden.
<div id="fritz_web"><a href="http://fritz.box" target="_blank">FRITZ-Box</a></div>
Nehmen wir an, der neue Benutzer soll picard heißen. Benutzer root macht dann Folgendes:
# Benutzer hinzufügen (Standard adduser Kommando) adduser picard # Paßwort vergeben (Standard passwd Kommando) passwd picard # Persistent speichern modsave flash
# Benutzer hinzufügen echo "picard:*" >> /tmp/flash/shadow.save # Persistent speichern modsave flash # Alle Benutzer neu laden, fehlende Heimverzeichnisse erzeugen modpasswd load # Paßwort vergeben (wird automatisch persistent gespeichert) modpasswd picard # Test login picard
Jetzt der umgekehrte Weg - Benutzer picard soll wieder weg. Benutzer root macht dann Folgendes:
# Heimverzeichnis löschen rm -rf /mod/home/picard # Benutzer löschen (Standard deluser Kommando) deluser picard # Persistent speichern modsave flash
# Heimverzeichnis löschen rm -rf /mod/home/picard # Temporäre Datei mit gelöschtem Benutzer erzeugen grep -v '^picard:' /tmp/flash/shadow.save > /tmp/deleted-user # Benutzerdatei überschreiben mv /tmp/deleted-user /tmp/flash/shadow.save # Persistent speichern modsave flash # Alle Benutzer neu laden (jetzt einen weniger) modpasswd load # Test (schlägt mit "Login incorrect" bei PW-Eingabe fehl) login picard