[Anleitung] Image zu groß. Was tun?

[SIZE="-2"]Edit vom 22.02.2009: Mittlerweile gehört auch Ousourcer der Vergangenheit. Ich hatte Ende 2008 seine Funktionalitäten in "external" von cuma eingebaut. Die Schritte, die in diesem Thread weiter beschrieben sind passieren nun voll automatisch während "make" durchläuft. Wenn einer die Hintergründe dennoch wissen will, kann er trotzdem weiter lesen.
Edit vom 08.01.2008: Basierend auf dieser Anleitung hatte ich nun ein Skript entwickelt: Outsourcer. Der "Outsourcer" erledigt die unten beschrieben Schritte automatisch. Es ist aber trotzdem ratsam zumindest Posting 1 von diesem Thread zu lesen, um zu verstehen, wie Outsourcer funktioniert.
[/SIZE]
Kleinere Boxen mit 4MB Flash haben leider nicht so viel Platz übrig um mehrere und vor allem größere ds-mod-Pakete zu integrieren. Was kann man dagegen tun? Zunächst sollte man sich für einen der drei Wege entscheiden:

1. Man wählt nur das, was in die Box passt
Es gibt keine eindeutigen Rezepte, welche Pakete in eine Box passen und welche nicht. Dadurch, dass viele Pakete gemeinsame Bibliotheken benutzen, hängt die resultierende Größe der gemoddeten Firmware davon ab, ob mehrere Pakete eine gemeinsame Bibliothek benutzen oder nicht. Da ich selbst eine 7050 habe, werden meine Kommentare und Beispiele in erster Linie diese Box betreffen. Die Vorgehensweise kann aber auf die andere Boxen erweitert werden. Infos bzgl. Flash- / RAM-Größe, Prozessortakt usw. findet man in WIKI.
Bei einer 7050 (WLAN+FON+USB-Client) kann man definitiv sagen, dass man für die aktuelle Firmware bestimmte Pakete, wie z.B. OpenVPN, Tor, u.a. wegen deren Größe und vor allem Bibliotheken (engl. libraries) vergessen sollte. Sie passen definitiv nicht in eine 7050 rein. Was man evtl. reinkriegen kann sind Callmonitor, Dnsmasq, vielleicht (aber statt und nicht und) Dropbear. Bei den Boxen mit reduzierter Funktionalität (z.B. ohne WLAN oder/und ohne FON) ist Original-AVM-Firmware etwas kleiner, sodass man mehr Pakete auf der Box plazieren kann.
Um die Arbeit etwas zu erleichtern, sollte man auf der Box etwas Platz schaffen. Wie man es macht, steht weiter im Text.
Die Frage "Warum hat es bei Heinz geklappt, und bei mir klappt es nicht?" kann man durch Abgleich der Datei .config sehr schnell lösen. Diese Datei findet man im Hauptverzeichnis vom mod, z.B. in /bofh/ds26-14.4/. Ich poste hier einige Verweise auf erfolgreiche Versuche, "kleine" Boxen zu modden. Meistens findet man dort auch .config-Dateien:

[SIZE="-2"]ds-mod-26-14.4[/SIZE]
7050 mit 14.04.33 mit dropbear, mini_fo, syslog, virtual-ip, wol;
7050 mit 14.04.33 AVM mit callmonitor, dnsmasq, wol;
Minimal-Config, die auch mit 14.04.31 geht;
Fon mit 06.04.30.

[SIZE="-2"]ds-mod-26-15.1[/SIZE]
Fon WLAN mit 08.04.34

[SIZE="-2"]ds-mod-26-15.2[/SIZE]
7050 mit 14.04.33 mit dropbear, callmonitor, checkmaild
Sonst Suchfunktion benutzen.

2. Man lagert einiges außerhalb der Box aus
Dazu gibt es wiederum einige Möglichkeiten:
a) Man hat einen USB-Host in der Box. Dann wird dort rein ein Stick oder eine Festplatte eingesteckt und am besten linuxtauglich (z.B. als EXT2) formatiert. Dann wird es beim Booten gemounted und man kann von dort Programme starten. Diese Lösung ist für die meisten irrelevant, weil z.B. 7050 keinen Host hat. Alle anderen bitte Suchfunktion benutzen.
b) Es gibt irgendwo im LAN ein NFS-Server. Wie man einen NFS-Server einrichtet beschreibe ich hier nicht. Ich verweise lediglich auf [1], wo diskutiert wird, wie man die Box mit so einem Server verbindet.
c) Man benutzt RAM der Box als Ersatz für den fehlenden Flash-Speicher und lagert dort die Dateien. Mit einer Box mit 32MB RAM (wie z.B. 7050) ist so eine Lösung begrenzt einsetzbar. Für kleinere Boxen mit 16MB RAM könnte es eng werden. Mit dieser RAM-Lösung kann man sicherlich 2-3 große Pakete, wie z.B. OpenVPN, MC, Dropbear auf der Box unterbringen. Man sollte aber nicht übertreiben, sonst wird es im RAM eng. Ich hatte z.B. einige Probleme mit syslogd festgestellt, die bei ausgelagerten Paketen schnell zum RAM-Überlauf und Box-Stillstand führten. Bitte [2] lesen, wie man die Probleme vermeidet.
Um die ausgelagerten Dateien auf die Box ins RAM beim jeden Neustart zu bekommen, schreibt man entweder ein Paar Zeilen in debug.cfg (alte Methode), oder man benutzt meinen Downloader (bequem, Webbasiert).

Aber wie prepariert man das Image, damit es alles notwendige enthält und auf die Box passt? Was lagert man aus? Dazu mache ich eine Schritt-für-Schritt Anleitung, basierend auf meinem Downloader.

1. Es wird empfohlen nach dem Entpacken von ds-mod den Downloader in ds-mod zu "integrieren". Alternativ geht auch addon-Variante. Sie wird aber nicht alle Pakete rechtzeitig downloaden können.

2. Man führt wie gewöhnlich aus.
a) Man wählt möglichst nur eine Branding (AVM, 1und1, ...) aus. Viel spart man dadurch nicht, aber immer hin.
b) Man wählt alle Patches aus. Vor allem diverse "Removes" werden uns beim Platz sparen helfen.
c) Man wählt die Bibliothek libgcc_s.so aus. Dadurch spart man etwa 155kB [3].
d) Man wählt Downloader unter den Paketen aus. Entweder unter Testing oder unter Addons.
e) Man wählt sich seine Pakete aus, inklusive die, die später ausgelagert werden sollen.
f) menuconfig wie gewöhnlich mit Abspeichern beenden.

3. Wie gewöhnlich ausführen:
make terminiert mit der alten bekannten Meldung "image too big". Wir notieren uns, wieviel es "too big" ist. Bei mir war es z.B. etwas um 900kB.

Nun nehmen wir aus dem Image einige Binaries und Libraries aus, die wir auslagern werden. Ich benutze dafür mc, aber das ist eine reine Geschmacksache. Nehmen wir uns OpenVPN als Beispiel.

4. Im Unterverzeichnis build/modified/filesystem/usr/sbin finden wir die Datei openvpn, die in etwa 450kB (unkomprimiert) beansprucht. Diese Datei verschieben wir in einen Extra-Ordner außerhalb der mod-Ordnerstruktur. Z.B. unter FriBoLi in /bofh/outboard/. In diesem Ordner sammeln wir zunächst alle auszulagernden Dateien. Wir notieren uns die Attribute der verschobenen Datei. In diesem Fall wären es 755.
5. Damit die Datei später auf ihrem neuen Ort gefunden wird, erstellen wir an der Stelle, wo die Originaldatei lag ein Symlink:
Später müssen wir dafür sorgen, dass die Datei unter /mod/sbin auch kommt. Aber das übernimmt für uns Downloader. Wir notieren uns /mod/sbin/openvpn.

6. Schritte 4 und 5 wiederholen wir mit allen Binaries und Libraries, die wir auslagern wollen. Im Falle von OpenVPN machen wir es z.B. mit build/modified/filesystem/usr/lib/libcrypto.so.0.9.8 und build/modified/filesystem/usr/lib/libssl.so.0.9.8. Die beiden kommen später nach /mod/lib. Symlinks erstellen nicht vergessen!
[size=-2]Und bitte nur die wirklichen binaries und libraries auslagern, keine Symlinks! Im gleichen Verzeichnis findet man z.B. ein Symlink libcrypto.so -> libcrypto.so.0.9.8. Den und die gleichen lässt man bitte in Ruhe, obwohl sie in MC ihre Farbe ändern, als ob sie ins leere zeigen. Es ist normal![/size]
In [4] habe ich zwei Beispiele gepostet, was man so alles typisch auslagern kann.

7. Nun können wir überprüfen, ob wir genug ausgelagert haben. Wir bauen uns das Image neu auf [5]:
wobei Image Name in dl den eigenen Bedürfnissen anzupassen ist.
Image hat einen etwas ungewöhnlichen Namen und liegt unter build. Wenn wir alles richtig gemacht haben, dann wird unser Image funktionieren, aber wie es oben zu Recht steht "This can result in invalid images!!!". Im Unterschied zum normalen make haben wir hier einige Manipulationen nachträglich durchgeführt, die in diesem dritten STEP nicht kontrolliert werden! Deswegen übernehme ich keine Haftung für evtl. zerschossene Boxen!

Es kann uns wieder passieren, dass wir "image too big"-Meldung erhalten. Nicht schlimm, einfach Schritte 4-7 nochmal (oder zweimal) durchlaufen und noch eine oder andere Datei "rausschmeißen". Übung macht den Meister: Irgendwann hat man so ein Fingerspitzengefühl und kann anhand "image too big"-Größe genau entscheiden, was raus muss und was bleiben darf.

8. Nun haben wir unser Image gebaut und können die Box damit flashen. Hier gibt es auch keine Unterschiede zum normalen Prozess.
9. Jetzt müssen wir die Dateien, die wir bei Seite gelegt haben auf einen Server legen, von dem sie beim Neustart der Box runtergeladen werden. Der Downloader erwartet die Dateien in .gz-Format. Man kann die Dateien z.B. bequem mit MC einzeln zippen: [F2][y]. Ich benutze einen externen FTP-Server mit Benutzer und Passwort, der Downloader versteht aber auch http-Server.
10. Im ds-mod finden wir den Downloader Menüeintrag mit allen möglichen Einstellungen. Nachdem die Einstellungen eingerichtet und gespeichert sind, sollte man die Box rebooten, damit der Downloader alle Dateien runterlädt. Alternativ kann man den Dienst downloader starten.
Damit sind wir mit unserer "softi"-Lösung fertig. Für ganz "harte" Jungs und Mädels gibt es noch eine Möglichkeit:

3. Man lötet
[6]: Ist wirklich nur für Hardware-Profis empfohlen.

In dieser Zusammenfassung habe ich lediglich das zusammengesucht und aufgeschrieben, was jeder hier im Forum durch die Suchfunktion für sich finden konnte. Verbesserungsvorschläge und Kommentare sind erwünscht.

Edit: Ganz vergessen hatte ich Wiki-Beitrag [7] von kriegaex zu erwähnen. Für diejenigen, die etwas mehr über die Hintergründe wissen wollen ist es auf jeden Fall empfehlenswert den Beitrag zu lesen. Aber das wird sicherlich nicht die einzige Quelle sein, die ich vergessen hatte zu erwähnen.

MfG

Symlinks. Warum sollen sie gemacht werden

Da xsapling eine berechtigte Frage stellt, erkläre ich, was diese Geschichte mit symlinks überhaupt soll. Wer mehr Interesse dazu hat, kann unsere urspüngliche Diskussion dazu in [1] nachlesen.
Normalerweise existieren unter ds-mod Verzeichnisse mod/bin, mod/sbin, mod/usr/bin, mod/usr/sbin und mod/lib. Sie liegen physikalisch in RAM. Die Variable PATH wird sogar so gesetzt, dass diese Verzeichnisse dem Flash bei der Suche bevorzugt werden. So dass man theoretisch überhaupt keine symlinks braucht. Und das funktioniert auch mit einigen binaries und vielleicht sogar mit libraries.
Die nackte Tatsache der Praxis sieht aber nicht so rosig aus. Innerhalb des Dateisystems sind schon diverse symlinks angelegt, die leider absolut sind. So zeigt beispielsweise /usr/lib/libcrypto.so -> /usr/lib/libcrypto.so.0.9.8. Nehmen wir nun /usr/lib/libcrypto.so.0.9.8 weg, so zeigt Symlink /usr/lib/libcrypto.so ins leere. Und es hilft nicht, dass die Bibliotheken auch in /mod/lib zunächst gesucht werden. Ähnliche Querverknüpfungen hatte ich auch bei dropbearmulti und mc.bin entdeckt. Und damit ich nicht erstmal untersuche, ob man symlinks braucht oder nicht, lege ich sie grundsätzlich immer an.
Deswegen empfehle ich auch bei den Originalnamen der Binaries und Libs zu bleiben und den Symlinks auch sinnvollerweise die gleichen Namen zu geben. Also, im Beispiel von xsapling hieße es dann:
(aber bitte im Verzeichnis ausführen, wo screen.bin auch vorher lag!) und entsprechende gezipte Datei für Downloader würde dann screen.bin.gz heißen.

MfG

xsapling schrieb:

Starting ssh server...done.

Zum Vergrößern anklicken....

Das ist schon mal was. Dann kannst du zumindest auf die Box drauf, um dort zu schauen, ob deine Symlinks wirklich dorthin zeigen, wo sie sollen. Dafür gehst du bitte in /usr/sbin/ und suchst dort nach dem Symlink tor. Wo er hin zeigt. Das wird vermutlich die Fehlerquelle sein. Sonst bin ich kein tor-Experte.

So wie ich sehen kann, lief es bei dir schon mal mit dem Downloaden und Rechte setzen erfolgreich, sonst hättest du keine "Download completed"-Meldung bekommen. Wie Alex schon sagte, Symlinks brauchen nicht ausgelagert zu werden. Das bringt gar nichts, außer Ärger. In deinem Falle solltest du dropbear, libz.so.1 und libncurses.so.5 im Flash lassen. Das sind nur reine Symlinks, die höchstens Paar Bytes unkomprimiert belegen. Ich sagte oben nicht umsonst: MC benutzen. Dann sieht sogar der Windows-Otto-Normal-Mausschubser (wie ich) die Größen der Dateien, und das es binaries und nicht Symlinks sind. Aber ok, ich pflege es irgendwie in die Anleitung, dass sowas keinem mehr passiert.

MfG

Bevor du nachfragst: es ist ein kleines eL gemeint, keine eins oder kein großes I.
Bei mir liefert es:
Du siehst, dropbearmulti ist ausgelagert und openvpn auch.

Ich verstehe nicht was du meinst? Dein Image ist definitiv falsch erstellt. In der laufenden Box kann man nichts mehr tun. Nur Image neu erstellen. Sprich STEP3. Wenn du vorher alles sauber gemacht hast, außer Symlinks anlegen, dann musst du nichts von vorne an machen.
Dein Fehler vermute ich liegt daran, dass du die Symlinks nicht aus dem Verzeichnis erstellt hast, wo sie hin gehören. Schau mal auf deinem Linux/FriBoLi System, vielleicht liegen die Links im Hauptverzeichnis oder anders wo unter build. Ich würde sowieso vor dem STEP3 (Punkt 7, meiner Anleitung) noch alles gründlich überprüfen. Auf dem Linux/FriBoLi hast du sicherlich MC, mit dem es bequemer geht.
Und wenn du es wirklich alles von vorne machen willst. Klar geht es:
aber vorher würde ich dl-Verzeichnis und vielleicht noch toolchain absichern. Sie sind an den Problemen sicherlich nicht schuld. Man kann beide Verzeichnisse sogar auslagern und als Symlinks anlegen. Dann geht es noch einfacher.

MfG

Kannst du bitte auf der Box telnet aktivieren und dann das tun, was im Posting #8 beschrieben ist. Existieren bei dir beide Symlinks auf der box?

Edit: Ich habe nicht gesagt, dass es nicht benötigt wird. Alexander und ich haben lediglich darauf hingewiesen, dass man es nicht auslagern sollte. Wenn du ein vom System angelegtes Symlink im build-Verzeichnis per Hand gelöscht hast, dann wird es dein Problem sein

MfG

Kompilieren brauchst du nicht. Denn nach dem Kompillieren ersetzt er dir wieder alle deine Symlinks durch richtige binaries und du bekommst wieder "image too big". STEP3 würde in deinem Fall völlig ausreichen, wenn du vorher den gelöschten Symlink per Hand anlegst.
Für alle anderen hatte ich die Anleitung etwas modifiziert, damit es etwas eindeutiger steht.

MfG