ipkg und mini_fo

[ptweety]

Ich würde gerne Punkt 1-5 gleich behandeln, nur eben mit einem Konfigurations-Parameter "Wo ist die Storage".

Egal, ob eine Festplatte dran ist oder Flash, es ist immer darauf zu achten, dass permanent wiederkehrenden Schreibzugriffe (z.B. Logs) immer in die Ramdisk kommen.

Klar. Ich sag' ja nichts anderes Wenn man das dann noch in ein schickes Skript packt und dem Anwender sagt, dass er für wichtige Daten eine zusätzliche Partition braucht, welche dann unter /var/lib (wie bei Debian) oder sonst wo gemountet wird, ist alles fein.

a)-c) will ich eigentlich auch nicht unterscheiden. Warum auch? Das muss jeder für sich wissen, was er fest im Squashfs drinnen haben will und was nicht. Macht sonst die Pakete wieder unnötig kompliziert. Da das austauschen des Root Filesystems durch den mini_fo Mountpoint vor(!) init geschehen wird, ist es für den weiteren Bootverlauf völlig egal, ob ein Paket im Squashfs ist oder nicht.

Stimmt. Solange alle relevanten Pakete sich in die IPKG-Datenbank eintragen, kann es egal sein, ob das beim bauen der FW oder später passiert.

MFG pTweety

 

[danisahne]

Wenn das Storage verfügbar ist, dann wird die Ramdisk nicht benötigt, das heißt, mehr Ram bleibt verfügbar?

Nein, die Ramdisk unter /var bleibt. Das Storage Verzeichnis wird nur dann beansprucht, wenn Dateien geändert werden (und nur in dem Fall, in welchem das Storage Verzeichnis in der Ramdisk ist). Die Ramdisk wächst dynamisch.

 

[lord-of-linux]

Hallöchen,

wie sieht es den mit mini_fo und ipkg zurzeit aus?
Lohnt es sich den noch, an meinem OpenVPN-Paket weiter zu entwickeln oder nicht?

 

[danisahne]

Wird leider noch ein bisschen dauern, bis ich dazu komme. Sorry.

 

[maceis]

Ich hätte mal ne Frage, die nur am Rande mit diesem Thema hier zu tun hat und mir beim Lesen dieses Threads (von dem ich zugegebenermaßen max. die Hälfte verstanden habe) in den Sinn gekommen ist.

Bei Cisco Routern ist es möglich, das Firmware Image beim Booten von einem tftp Server zu laden.
Würde das bei einer Fritz!Box grundsätzlich auch möglich sein?

Das hätte mE zwei Vorteile:
1. Die Größe des Flash Speichers ist nicht mehr maßgeblich für die Größe des verwendbaren Images.
2. Man kann (z.B. beim Experimentieren) durch einfaches Umbenennen auf dem tftp Server unterschiedliche Images Booten.

Nachteile hat's natürlich auch:
1. Das Booten übers Netz dauert natürlich länger
2. Bei Cisco Routern wird die Konfiguration im nvram gespeichert.
Wenn man nun eine Firmware läd, die bestimmte Einstellungen nicht kennt und dann die Konfiguration ändert (und speichert), werden alle Einstellungen der "besseren" Firmware beim Speichern verworfen.

Zumindest das zweite Problem wäre, soweit ich das beurteilen kann, bei uns nicht zu befürchten.
Dafür sind vermutlich relativ tiefgreifende Eingriffe erforderlich, falls das überhaupt umsetzbar wäre.

 

[olistudent]

Nein, das geht bei der FritzBox nicht.
Du kannst jedoch einen Kernel aus dem SDRAM booten.
Ich hab mir ein Kernel mit init-Ramdisk gebaut, der wird aus dem RAM gebootet und danach der Inhalt der RAM-Disk aufgerufen.
Das original Dateisystem kann dann später gemountet werden.
Funktioniert hervorragend als Recover-Image...

C:\>ftp 192.168.1.1
Verbindung mit 192.168.1.1 wurde hergestellt.
220 ADAM2 FTP Server ready.
Benutzer (192.168.1.1:(none)): adam2
331 Password required for adam2.
Kennwort:
230 User adam2 successfully logged in.
ftp> bin
200 Type set to I.
ftp> deb
Debugging EIN .
ftp> quote MEDIA SDRAM
---> MEDIA SDRAM
200 Media set to SDRAM.
ftp> put kernel.image kernel
---> PORT 192,168,1,20,6,48
200 Port command successful.
---> STOR kernel
150 Opening BINARY mode data connection for file transfer.
226 Transfer complete.
FTP: 64d Bytes gesendet in 0,87Sekunden 684,63KB/s
ftp>

Leider hat Daniel diesen Parameter aus dem angepassten Recover-Skript rausgenommen. Warum?
Außerdem weiß ich nicht, ob das mit deiner Box (7170) funktioniert.

MfG Oliver

 

[maceis]

Danke für die Info. Mit ADAM2 hab ich noch nichts gemacht.
Werde ich wohl irgendwann mal nachholen.

 

[lord-of-linux]

Wird leider noch ein bisschen dauern, bis ich dazu komme. Sorry.

OK, dann werde ich nach meinem Urlaub und dem Abschluß mal an OpenVPN weiterarbeiten.

 

[theborg]

hm ere es net sinvoll wenn ipkg eingefürt wirt jffs2 als datei system zu benutzen? für den kompletten flash ist zwar nicht so hoch komprimirt dafür kann mann dann alles auf der box editiren wie man lustig ist.

In openwrt ist des auch so ich fummel mir das grade auf die box das meiste leuft auch schon an die 300 pakete stehen mir per ipkg zur vferfügung es ist klasse wenn man auf der box programme zum testen in den ram zihen kann per ipkg und wenn man sie dauerhaft nuten möchte einfach ins filesystem instalirt.

ob die pakete auch mit dem ds mod laufen ka anber denke mal schon das des geht fals jemand testen möchte die pakete ligen auf http://www.grautier.com/fbf/ipkg/ mein server kann leider kein indexing b.z.w. habs deaktivirt deswegen hier die paketlist http://www.grautier.com/fbf/ipkg/Packages

 

[lord-of-linux]

hm ere es net sinvoll wenn ipkg eingefürt wirt jffs2 als datei system zu benutzen? für den kompletten flash ist zwar nicht so hoch komprimirt dafür kann mann dann alles auf der box editiren wie man lustig ist.

Ich halte das mini_fo für viel vernünftiger. Da ist nicht gleich der komplette Falsh zu und man hat auch ne Chance, falls man sich etwas zerschießt, durch das deaktivieren des von mini_fo genutzten Filesystems, alles wieder auf ausgangszustand zu bringen.

Noch ne kleine Frage: Werden die AVM-Einstellungen trotzdem im Flash gespeichert, sodass bei Ausfall des Filesystems trotzdem telefoniert werden kann.

 

[theborg]

naja ipkg unterstützt ja auch des deinstaliren von paketen ehnlich wie apt logs und pid files kann man ja wie immer im ram ablegen.

also ich würde nen komlettes rw systen vorteielhafter sehen das ewige image neubasteln nerft im der zeit

 

[lord-of-linux]

also ich würde nen komlettes rw systen vorteielhafter sehen das ewige image neubasteln nerft im der zeit

Wieso musst du den das Imag immer rumbasteln?

 

[ptweety]

also ich würde nen komlettes rw systen vorteielhafter sehen das ewige image neubasteln nerft im der zeit

Ich gláube, damit übertreibst du etwas. Ich habe jetzt trotz vieler Spielereien nur dreimal ein Image auf meine FB gespielt.

MFG pTweety

 

[ptweety]

mini_fo ist ein overlay Dateisystem ähnlich unionfs, aber viel kleiner (unter 100 KB).

[...]

Weitere Ideen oder Probleme?

EDIT: In wie weit mini_fo noch ernsthafte Bugs enthält muss auch erst noch getestet werden.

Um ehrlich zu sein: mini_fo erweckt den Eindruck etwas unfertig zu sein. Insbesondere das Behandeln von Hard-Links geht noch nicht so richtig. Unionfs scheint dagegen einen ausgereiften Stand zu haben. IMO könnte man also auch darauf mal einen genaueren Blick werfen und evtl. mal einen Test damit machen.

Letztlich sind wohl die Techniken (pivot_root, ...) um mini_fo oder unionfs zum Laufen zu bekommen etwas die Gleichen, oder?

MFG pTweety

 

[danisahne]

Noch ne kleine Frage: Werden die AVM-Einstellungen trotzdem im Flash gespeichert, sodass bei Ausfall des Filesystems trotzdem telefoniert werden kann.

Ja, daran ändert das ja nichts. Die Einstellungen von AVM werden ja weiterhin im TFFS gespeichert.

also ich würde nen komlettes rw systen vorteielhafter sehen das ewige image neubasteln nerft im der zeit

Unmöglich. Ohne Kompression passt nicht mal ein unmodifiziertes Image in den Flash! Die starke Kompression haben wir aber nur mit einem read-only Dateisystem wie squashfs.

Unionfs scheint dagegen einen ausgereiften Stand zu haben. IMO könnte man also auch darauf mal einen genaueren Blick werfen und evtl. mal einen Test damit machen.

Unionfs ist was ich weiß leider viel zu groß. mini_fo braucht halt nichtmal 100KB. Btw: Hardlinks brauchen wir nicht.

Mfg,
danisahne

 

[ptweety]

Unionfs ist was ich weiß leider viel zu groß. mini_fo braucht halt nichtmal 100KB. Btw: Hardlinks brauchen wir nicht.

Hm, gerade gelesen:

Unionfs is available as a module extension for Linux Kernel 2.4.20 / 2.6.9 and higher.

Dann wird's wohl eh nix mit unionfs

MFG pTweety

 

[ptweety]

Ich wollte selber mal testen, bekomme aber mini_fo leider nicht kompiliert:

~/ds-0.2.5-ptweety/mini_fo-0-6-2-pre1$ PATH=../toolchain/kernel/mipsel-unknown-linux-gnu/bin:$PATH make
gcc -D__KERNEL__ -DMODULE -O2 -finline-limit=10000   -c -o meta.o meta.c
/tmp/ccNu6WAG.s: Assembler messages:
/tmp/ccNu6WAG.s:213: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,40($16)'
/tmp/ccNu6WAG.s:215: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,40($16)'
/tmp/ccNu6WAG.s:244: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,40($16)'
/tmp/ccNu6WAG.s:246: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,40($16)'
/tmp/ccNu6WAG.s:249: Error: opcode not supported on this processor: mips1 (mips1) `sync '
make: *** [meta.o] Fehler 1

Kann mir da jemand weiterhelfen?

MFG pTweety

 

[ptweety]

Ich hasse es, mir selber zu antworten. Aber es soll ja weitergehen:

Ich wollte selber mal testen, bekomme aber mini_fo leider nicht kompiliert.

Ich habe mit -mips2 bis -mips4 kompiliert und jeweils keinen Erfolg erzielt. Dann habe ich auch noch Hinweise gefunden, dass die Toolchain ebenfalls mit den Parametern übersetzt sein sollte. Insbesondere habe ich auf die gleichen Optionen bei Toolchain und min_fo-Treiber geachtet; hat aber auch nix gebracht

Kann mir da jemand weiterhelfen?

Leider bleibt also diese Bitte bestehen.

@danisahne: Können wir auch eine neuere Version des gcc für den Kernel verwenden oder ist die aktuell verwendete, die einzige, die fehlerfreien Code erzeugt?

MFG pTweety

 

[danisahne]

@danisahne: Können wir auch eine neuere Version des gcc für den Kernel verwenden oder ist die aktuell verwendete, die einzige, die fehlerfreien Code erzeugt?

Neuere Compiler kompilieren den Kernel nicht. Darum gibt es zwei Toolchains, an sich würde ja eine reichen.

Mfg,
danisahne

 

[ptweety]

mini_fo wird laut Homepage ab jetzt nur noch im git repository aktualisiert. Da sich da was getan hatte, hab' ich den Faden mal wieder aufgenommen und bin leider am gleichen Punkt hängen geblieben, wie beim letzten Mal.

entweder (-mips1):

gcc -D__KERNEL__ -DMODULE -DFISTGEN -I. -I~/ds-0.2.7-ptweety/source/ref-ohio-8mb-04.06/kernel/kernel_ohio-8mb_build/kernel/linux-2.4.17_mvl21//include -O2 -Wall -Wno-unused -g -fno-common -fno-schedule-insns -fno-schedule-insns2 -fno-strict-aliasing -msoft-float -Werror    -c -o meta.o meta.c
/tmp/ccW7SkeQ.s: Assembler messages:
/tmp/ccW7SkeQ.s:403: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,40($16)'

oder (-mips2 bis -mips4):

gcc -D__KERNEL__ -DMODULE -DFISTGEN -I. -I~/ds-0.2.7-ptweety/source/ref-ohio-8mb
-04.06/kernel/kernel_ohio-8mb_build/kernel/linux-2.4.17_mvl21//include -O2 -Wall
 -Wno-unused -g -fno-common -fno-schedule-insns -fno-schedule-insns2 -fno-strict
-aliasing -msoft-float -Werror  -finline-limit=10000 -mips3   -c -o file.o file.
c
/tmp/ccLgp3MS.s: Assembler messages:
/tmp/ccLgp3MS.s:1307: Error: Cannot branch to symbol in another section.
make: *** [file.o] Fehler 1

Zumindest für letzteres Problem scheint es aber einen Fix der binutils-2.15 zu geben. Ich verstehe nun nur leider nicht, wie ich den genau in crosstool einbringen kann.

Kann mir da wer auf die Sprünge helfen?

EDIT: ich habe mal einen Snapshot des Repositories von mini_fo angehängt.

MFG pTweety