.titleBar { margin-bottom: 5px!important; }

ipkg und mini_fo

Dieses Thema im Forum "Freetz" wurde erstellt von danisahne, 23 Apr. 2006.

  1. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    #1 danisahne, 23 Apr. 2006
    Zuletzt bearbeitet: 23 Apr. 2006
    Erstmal, warum komme ich auf die Idee (neu ist die nämlich nicht):
    Diskussion im OpenWRT Forum
    mini_fo Homepage

    Ich habe jetzt mal auf meinem Rechner etwas mit mini_fo rumgespielt und werde es mal nächstes Wochenende auf die Fritzbox bringen. mini_fo ist ein overlay Dateisystem ähnlich unionfs, aber viel kleiner (unter 100 KB). Damit kann man ein read-only Dateisystem mit einem beschreibbaren kombinieren, so dass Änderungen im read-only Dateisystem transparent in ein Storage Verzeichnis geschrieben werden. Als Storage Verzeichnis wären denkbar:
    • Eine Ramdisk für Boxen ohne USB Host Anschluss (die Änderungen überleben so natürlich keinen Reboot, weshalb die Konfiguration über das Webinterface weiterhin im TFFS landen muss)
    • USB Stick
    • JFFS im Flash der Box (darauf würde ich erstmal verzichten)
    • vielleicht auch Samba Share oder NFS Export eines Rechners im privaten Netzwerk

    Damit ist es auch möglich (mit einem externen permanenten Storage Verzeichnis und ipkg) Pakete nachträglich zu installieren und zu entfernen. Die Symlinks von /mod/... nach /... würden entfallen.

    Ein weiterer Vorteil ist, dass wenn z.B. der USB Stick nicht eingesteckt ist, dann kann man trotzdem ohne diese zusätzlichen Änderungen ganz normal die Firmware im Squashfs booten. Nur die zusätzlichen Pakete werden nicht geladen, aber die Firmware ist konsistent.

    Umgesetzt ist davon noch nichts, sind erstmal nur Gedanken, die mich aber sehr begeistern ;) Ein Problem dabei ist für mich, dass man das Storage Verzeichnis auf dem externen Datenträger nicht manipulieren darf (und schon garnicht im Netzwerk freigeben sollte), da das die Box instabil macht und sie darauf hin auch einfach abstürzen kann.

    Weitere Ideen oder Probleme?

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

    Mfg,
    danisahne
     
  2. dsteinkopf

    dsteinkopf Mitglied

    Registriert seit:
    29 Juli 2005
    Beiträge:
    263
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Klingt ziemlich gut. Für mich wäre die Nutzung eines externen NFS-Rechners interessant.

    Damit wäre ja dann so ziemlich alles möglich, weil der "Plattenplatz" quasi unbegrenzt wäre.


    Dirk
     
  3. ptweety

    ptweety Neuer User

    Registriert seit:
    3 Apr. 2006
    Beiträge:
    138
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #3 ptweety, 24 Apr. 2006
    Zuletzt bearbeitet: 24 Apr. 2006
    Als mount point für weitere Software würde ich /opt empfehlen. Damit kann Firmware (/bin, /lib, /sbin, /usr) und zusätzliche Software schön getrennt werden.

    Ja, das ist eine gute Lösung. Damit kann ein Anwender immer auf einen funktionierenden Zustand zurückgehen.

    Wenn / mit einer Ramdisk als Storage gemountet wird, kann man Änderungen ohne große Gefahr testen. Es sollte einfach noch zusätzlich eine Warnung dokumentiert werden, irgendwas direkt in der Ramdisk zu ändern.

    Sollte ein USB-Stick oder eine USB-Platte an einer FB zum Einsatz kommen, so kann mit dem richtigen Owner (root) und entsprechenden Rechten auch hier einer voreiligen Änderung am Storage vorgebeugt werden. Zur Not kann man ja auch mehrere Partitionen anlegen; eine für zusätzliche Pakete und weitere für Freigaben, etc.

    Ein NFS- oder SMB-Mount kann entsprechend (allerdings dann im Netz) eingerichtet werden.

    Wer am Storage was ändert, sollte einfach wissen was er tut. Eine entsprechende Warnung in der Doku (oder Wiki) sollte ausreichen.

    BTW: von einer Integration des JFFS würde ich hier auch erst mal Abstand nehmen.

    Wie gesagt:

    / mit einer Ramdisk dahinter
    /opt mit einem NFS, SMB, USB mount dahinter

    Letzteres sollte mit einem in der Firmware integrieten Start-Stop-Skript dynamisch eingebunden werden. Dazu sollte ein Verfahren entwickelt werden, um im Flash den gewünschten mount point und die mount source zu speichern. Als Anregung hier mal das unsling script von unslung:

    Code:
    #!/bin/sh
    
    usage="Usage: $0 disk1|disk2"
    
    # Set target disk
    
    if [ $# -gt 1 ] ; then
        echo $usage
        exit 1
    fi
    
    if [ $# -eq 1 ] ; then
        if [ "$1" = "disk1" ] ; then
    	targ=/share/hdd/data
    	flag=.sdb1root
        elif [ "$1" = "disk2" ] ; then
    	targ=/share/flash/data
    	flag=.sda1root
        elif [ "$1" = "hdd-data" ] ; then
    	targ=/share/hdd/data
    	flag=.sdb1root
        elif [ "$1" = "hdd-conf" ] ; then
    	targ=/share/hdd/conf
    	flag=.sdb2root
        elif [ "$1" = "flash-data" ] ; then
    	targ=/share/flash/data
    	flag=.sda1root
        elif [ "$1" = "flash-conf" ] ; then
    	targ=/share/flash/conf
    	flag=.sda2root
        else
    	echo $usage
    	exit 1
        fi
    else
        echo $usage
        exit 1
    fi
    
    # Check it's a real mount point
    
    if grep $targ /proc/mounts >/dev/null 2>&1 ; then
        echo "Target disk is $targ"
    else
        echo "Error: $targ is not a mounted disk"
        exit 1
    fi
    
    # Start at the root directory
    
    cd /
    
    # Save the existing ipkg database.
    
    rm -rf $targ/usr/lib/ipkg.old
    if [ -f $targ/usr/lib/ipkg/status ] ; then
    	mv $targ/usr/lib/ipkg $targ/usr/lib/ipkg.old
    fi
    
    # Copy the complete rootfs to the target.
    
    echo "Copying the complete rootfs from / to $targ."
    /usr/bin/find / -print0 -mount | /usr/bin/cpio -p -0 -d -m -u $targ
    rm -rf $targ/dev ; mv $targ/dev.state $targ/dev
    rm -rf $targ/var ; mv $targ/var.state $targ/var
    
    # Copy over the existing ipkg database.
    
    if [ -f $targ/usr/lib/ipkg.old/status ] ; then
    	echo "Preserving existing ipkg database on target disk."
    	( cd $targ/usr/lib/ipkg.old ; tar cf - . ) | ( cd $targ/usr/lib/ipkg ; tar xf - )
    fi
    
    echo "Linking /usr/bin/ipkg executable on target disk."
    rm -f $targ/usr/bin/ipkg ; ln -s /usr/bin/ipkg-cl $targ/usr/bin/ipkg
    
    # Create the boot flag file.
    
    rm -f /.sd??root $targ/.sd??root
    
    echo "Creating /$flag to direct switchbox to boot from $targ."
    echo > /$flag
    echo > $targ/$flag
    
    exit 0
    

    EDIT: BTW: die aktuelle unslung-source gibt's hier.


    MFG pTweety
     
  4. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    #4 danisahne, 24 Apr. 2006
    Zuletzt bearbeitet: 24 Apr. 2006
    Ich wäre gleich einen Schritt weiter und hätte den Ort des Storage Verzeichnis konfigurierbar gemacht und es für ganz / benutzt. Standardmäßig also eine Ramdisk, bei Bedarf aber auch ein USB Massenspeicher oder ein NFS Export. So kann man das ganze Dateisystem auch dauerhaft editieren, diese ganzen sed Skripte sind dann nicht mehr notwendig. Oder wird das eher als Nachteil angesehen?

    Unabhängig davon können wir sämtliche Pakete nach /opt/ packen. Also /opt/bin, /opt/sbin und /opt/lib, wenn ich das richtig verstehe.

    EDIT: Wegen JFFS: Man kann sich ja mal die Option offen lassen, freien Platz hinter dem Squashfs später auch als Storage Verzeichnis zu nutzen (natürlich raubt das dem / Squashfs an Platz). Wie gut ist denn der verbaute Flash? Natürlich sollten dann alle Logs etc auch weiterhin nur in die Ramdisk geschrieben werden, um unnötige Schreibzugriffe auf den Flash zu vermeiden. Auf wieviele Schreibzyklen ist der verbaute Flash ausgelegt?

    Mfg,
    danisahne
     
  5. ptweety

    ptweety Neuer User

    Registriert seit:
    3 Apr. 2006
    Beiträge:
    138
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #5 ptweety, 24 Apr. 2006
    Zuletzt bearbeitet: 24 Apr. 2006
    Ich kann hier ja nur für mich sprechen:

    Ich sehe die Firmware (wenn erstmal auf die FB gespielt) als relativ fix an. Jegliche Änderung sollte erstmal nicht persistent sein, da letztlich umfangreiche Recovery-Maßnahmen oder gar ein reflash der FW notwendig werden kann (weil AW etwas kaputt gemacht hat). Das gilt letztlich zwar nur bei Integration von JFFS; aber Mensch hat ja Prinzipien ;)

    Ein regulärer FW-Update kann im Zusammenhang mit einem dahinterhängenden persistenten Storage zu unvorhergesehenen Ergebnissen führen. (Da wäre etwa ein Start-Stop-Skript, welches von Nutzer verändert wurde und dann später per FW-Update auch geändert werden soll. Letztlich müssten solche Updates dann gemerget werden.)

    Daher der Vorschlag mit / und /opt. Weiterhin könnte man wie bisher einen Zugang anbieten, um ins Flash zu schreiben.

    Ich würde hier FW und zusätzliche Paket getrennt halten. Das sollte in der Wartung für einen Anwender besser verständlich sein.

    Ist das Squashfs immer von gleicher Größe?
    EDIT: Ähm, vergiss die Frage. Ich habe gerade das gelesen.

    Keine Ahnung. Aber normalerweise hält doch Flash-Speicher immer so mehrere 100 Schreibzyklen durch.

    BTW: wie wäre es denn, wenn man die Start-Stop-Skripte mit Hooks versieht, bei denen ein User ganz regulär seinen eigenen Senf einbauen kann:

    Code:
    if ( [ -f /opt/etc/rc.d/rc.??? ] && . /opt/etc/rc.d/rc.??? ) ; then return 0 ; fi
    
    EDIT2: Ach du Schreck. Ich habe mir gerade das erste mal die Start-Skript der FB angesehen und bin .... erstaunt. ;)
    Unter diesen Umständen macht obiger Vorschlag keinen Sinn. Eher sollte dort am Ende so was angehängt werden:

    Code:
    for i in /opt/etc/rcS.d/S??*
    do
            # Ignore dangling symlinks for now.
            [ ! -f "$i" ] && continue
            $i start
    done
    

    MFG pTweety
     
  6. lord-of-linux

    lord-of-linux Mitglied

    Registriert seit:
    3 Dez. 2005
    Beiträge:
    568
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    Hallo,

    ich kenne mich nicht so gut mit der ganzen Flash und Ramdisksache nicht, werde aber mal trotzdem meine Meinung dazu schreiben, die dann eben mehr mit den Tatsachen als mit der Realisierung zu tun hat.
    Ich wäre auf alle Fälle für etwas ähnliches. Was mit vorhin, ohne von dem Thread zu wissen, durch den Kopf schoß (wollte es nacher kurz als PN oder Mail an danisahne schicken) war folgendes:
    Auf dem Stick/der Platte folgende Partitionen anzulegen:
    1. 32MB oder von mir aus auch weniger oder mehr.
    2. Eine beliebig Größe, für die dynamischen Pakete
    Auf der ersten liegt dann der ganze Inhalt des Flashimages und auf der 2ten die dynamischen Pakete des Mods.
    Durch dei 1ste wäre der Ram entlastet, da man sich diesen nicht für die Ramdisk bräuchte.
    Die zweite könnte man in ein Verzeichnis der Ersten mounten.
     
  7. ptweety

    ptweety Neuer User

    Registriert seit:
    3 Apr. 2006
    Beiträge:
    138
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Wo du das gerade schreibst fällt mir noch ein, dass auch unbedingt die Möglichkeiten zur Nutzung einer swap Partition geschaffen werden sollten.

    MFG pTweety
     
  8. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    Ehrlich gesagt würde ich gerne das overlay filesystem mini_fo verwenden, um solche Verkomplizierungen zu eleminieren. Dass ein Storage Verzeichnis nach einem Firmware Update nicht mehr als gültig erkannt wird und die Firmware sich weigert es zu mounten ist realisierbar (und auch nötig, da sonst die Konsistenz des Dateisystems futsch ist).

    Ich möchte eben nicht mehr zwischen dynamischen und statisch einkompilierten Paketen unterscheiden müssen, genau diesen Vorteil würde mini_fo ja bringen.

    Swap find ich gut, wenn machbar, allerdings macht das nur im Zusammenhang mit einer Festplatte Sinn (und wird denke ich mal auch weniger Leute interessieren, aber warum nicht optional).

    EDIT: btw, warum sollte mini_fo das RAM belasten?

    Mfg,
    danisahne
     
  9. lord-of-linux

    lord-of-linux Mitglied

    Registriert seit:
    3 Dez. 2005
    Beiträge:
    568
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    #9 lord-of-linux, 24 Apr. 2006
    Zuletzt von einem Moderator bearbeitet: 24 Apr. 2006
    EDIT von danisahne: Vollzitat entfernt. Bitte gezielt zitieren, mein ganzes Posting steht ja direkt darüber

    Könntest du mir das mini_fo kurz erklären? Ich verstehe das Prinzip nicht wirklich. Die Website hat mir leider nicht viel gebracht.
    Muss min_fo nicht in den Ram entpacken? Wohin kommen die ganzen Dateien dann?
     
  10. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    mini_fo nimmt zwei Dateisysteme (bzw eigentlich Verzeichnisse) und fügt sie zusammen. Das erste - auch base genannt - wird nicht verändert und ist daher in der Regel read-only (das ist unser squashfs). In das zweite - auch storage genannt - werden dann alle Veränderungen des base Dateisystems geschrieben, so dass das neue Dateisystem wie ein rw Dateisystem zu benutzen ist, jedoch ein ro Dateisystem als Basis hat. Ist beispielsweise die storage eine Ramdisk, dann kann man das mini_fo Dateisystem (und ich würde dieses nach root mounten) komplett nach Herzenslust verändern, nach einem Reboot wäre aber wieder das alte Dateisystem hergestellt (so wird es oft in Linux Live CDs gemacht). Nimmt man als storage einen persistenten Speicher, wie z.B. Flash, dann bleiben die Änderungen auch nach einem Reboot erhalten.

    Mfg,
    danisahne
     
  11. lord-of-linux

    lord-of-linux Mitglied

    Registriert seit:
    3 Dez. 2005
    Beiträge:
    568
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    OK, habe es nun verstanden. Nur noch eine kleine Frage:
    Die Änderungen der Einstellungen der Statischen Paketet werden weiterhin im Flash gespeichert, die Dynamischen dann auf dem Stick/NFS-Mount/SMB-Mount?
     
  12. kay1234

    kay1234 Mitglied

    Registriert seit:
    25 Jan. 2006
    Beiträge:
    262
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Schon richtig, die FW sollte einigermaßen persistent sein. Davon kommt ja überhaupt die Idee, ein Overlay-Dateisystem zu nutzen. Damit ist es sehr einfach, "mal eben was auszuprobieren", ohne dass gleich ein recover fällig wird. Die Box kommt in jedem Fall wieder hoch.

    Ich wäre aber schon dafür, die Änderungen auch auf einem USB-Device persistent zu machen. Wenn die Kiste nicht mehr hoch kommt schalte ich sie ab, entferne das Speichermedium und alles ist wieder gut. Und wenn ich ein Firmware-Update mache, muss ich eben damit rechnen, dass die Daten auf dem USB Filesystem nicht mehr zur FW passen. Das kann man entweder abfangen oder ausprobieren (z.B. bei identischer Firmware mit mehr/weniger Paketen könnte es ja auch klappen, oder?).

    Ich bin auch für optionalen swap, hier gibt es eh einige Leute, die eine HDD an ihre Box anschließen (siehe z.B. die bittorrent-auf-der-Box Diskussion - oder auch Faxempfang auf der Box...). Wenn wir dann auch noch sdparm haben, kann man die Platte rund um die Uhr dran lassen. Oder greift die Box so regelmäßig zu, dass die Platte nie runterfährt?
     
  13. McClean

    McClean Neuer User

    Registriert seit:
    21 Apr. 2006
    Beiträge:
    24
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Normalerweise klappt der spindown recht problemlos bei Linux, solange die HDD nicht die Systemplatte is - aber dann liegt es normal auch nur am syslog der eben ständig irgendwas schreiben will.
    Wenn man jetzt Pakete auf die HDD installen würde wäre das auch relativ ungünstig mit spindown. Beispiel: callmonitor wäre auf der HDD installiert. Bei jedem Anruf müsste nun die Festplatte erstmal hochfahren. Das dauert natürlich auch seine Zeit bis dann das Programm gestartet werden kann...

    Daher würde ich sagen, dass man auf die Festplatte ausschliesslich Daten lagern sollte. Die Programme usw. sollten alle auf einen USB-Stick wandern, der dann ja immer sofort ansprechbar ist. Die USB-Sticks kosten ja nichts mehr und selbst mit kleinen 128MB Sticks kommt man bei den kleinen Anwendungen sehr weit...

    Gruss Steffen
     
  14. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    Das ist nicht die Regel, dass das noch passt, da sich oft im base Dateisystem ja auch Dateinamen verändern bzw. wenn man eine Datei der base verschoben hatte und die existiert nun nicht mehr? Auch problematisch: Eine Datei in der base ändert sich vom Inhalt, man hatte aber eine Kopie der alten Datei bearbeitet, so schlagen sich die Änderungen der base nicht durch.

    Sobald das base Dateisystem ausgetauscht wird, muss also auch die storage geplättet werden. Ich würde das über eine Zufallszahl im Squashfs lösen. Beim ersten mount wird diese in eine 2te Datei kopiert, welche dann in der storage landet. Stimmen diese beiden Dateien irgendwann nicht mehr überein, weiß man, dass das squashfs ausgetauscht wurde und damit die storage ungültig ist.

    Mfg,
    danisahne
     
  15. ptweety

    ptweety Neuer User

    Registriert seit:
    3 Apr. 2006
    Beiträge:
    138
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Problem wird hier aber sein, dass viele USB-Gehäuse Chipsätze verbaut haben, welche keinen vollständigen Befehlssatz (insbesondere für Spinup/Spindown) eingebaut haben.

    BTW: USB-Sticks sollte man unbedingt mit noatime mounten. Dann halten die länger.

    Boah, wie brutal. Wenn ich mühevoll meine Anwendung (Fax2Mail-Gateway, Samba mit meiner Fotosammlung, Mailserver mit Mailstorage, NFS, etc.) konfiguriert habe, dann eine FW-Update mache und wieder boote ist alles im A... ;) Willst du darüber nicht noch mal nachdenken?

    Es wäre imo mindestens eine Strategie vonnöten, bei der die Anwendungen und die Daten getrennt liegen. Also sollte man Anwender dazu motivieren, die Daten alle unter /var oder /srv abzulegen und dafür vorher auch eigene Partitionen anzulegen.

    MFG pTweety
     
  16. lord-of-linux

    lord-of-linux Mitglied

    Registriert seit:
    3 Dez. 2005
    Beiträge:
    568
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    Daher kam ja auch mein Vorschlag:
    So wäre dann sichergestellt, das die eigenen Sachen in der 2ten Partition nicht angerührt werden und nur die 1te Partition überschrieben wird. Die Konfiguration der statischen Pakete sollte sowieso im Flash der Box landen wie bisher (oder wenigstens otpional in den Flash schreibbar sein), damit auch bei Problemen mit dem Stick / der Platte die Box normal arbeiten kann.
     
  17. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    Fotosammlung etc. muss unbedingt in eine andere Partition. Wie gesagt, mini_fo läßt uns keine andere Wahl, sobald das base Dateisystem ausgetauscht ist, wird es inkonsistent, wenn man die alte storage weiterverwendet. Ich würde mich nur weigern sie zu mounten, die Daten kann man ja aus der alten storage noch rausziehen, aber wenn man dann die alte storage weiterbenutzen würde, dann kann es zu unvorhersebaren Ergebnissen kommen
    Genau das ist notwendig oder wir finden noch eine andere elegante Lösung. Allerdings würde ich diese Lösungen allerhöchstens als experimentell bezeichnen und nicht für die Sicherheit der Daten garantieren. Weiß jemand eine bessere Lösung? Ansonsten müßte halt klar sein:

    / : alle Änderungen gehen beim Firmware Update drauf (bzw. Neustart, wenn keine externe storage angegeben
    /srv : Änderungen bleiben erhalten
    /var : Ramdisk wie bisher; alle Änderungen überleben keinen Neustart

    Aber idiotensicher ist das dummerweise nicht, wie dein Beispiel mit der Fotosammlung zeigt. Wenn man weiß, wie der Firmware Mod aufgebaut ist, ist es praktisch, wenn man's nicht, tappt man leicht in eine Falle. Ich möchte halt gerne / beschreibbar haben, damit man ohne großen Aufwand auch nach dem Flashen der Firmware mit ipkg Pakete installieren kann. Natürlich könnte man auch die ganze Firmware auf einen externen Speicher kopieren und dann mit pivot_root wechseln, allerdings gestaltet sich hier ein Firmware Update genauso problematisch (neue Firmware einfach drüberkopieren?? ist auch unsauber). Vorschläge?

    @lord-of-linux:
    Was mir an deinem Vorschlag nicht so gut gefällt ist, dass ich für dynamische und statische Pakete unterschiedliche Pfade braucht, man also alles statische symlinken muss oder ähnliches. Zudem kann man sich Konflikte durch ein Firmware Update einfangen, wenn z.B. callmonitor 1.0 als dynamisches Paket installiert ist und man in der neuen Firmware callmonitor 1.1 statisch einbaut. Ich wäre schon dafür, dass ein Firmware Update ein tabula rasa für alle Pakete ist (statisch und dynamisch). Man könnte ja die storage auf 16 MB beschränken. Zu wenig für ne Fotosammlung und genug für zusätzliche Pakete.

    Mfg,
    danisahne
     
  18. ptweety

    ptweety Neuer User

    Registriert seit:
    3 Apr. 2006
    Beiträge:
    138
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ok, folgende Szenarien haben wir also:

    1. FB ohne persistenten Speicher (außer Flash)
    2. FB mit lokal angebundenem USB-Stick
    3. FB mit gemountetem NFS-Share
    4. FB mit gemountetem SMB-Share
    5. FB mit lokal angebundener USB-Platte

    Bei 1. braucht man nur / mit einem Storage im RAM zu hinterlegen.

    Für 2. gilt das eigentlich auch, allerdings ist das Storage auf dem Stick. Dabei sollte vorsichtshalber vermieden werden, irgendwelche Daten mit hoher Änderungsrate in das Storage zu schreiben, sonst hat man nach ein paar Wochen den USB-Stick gehimmelt. Als Option sollte hier eine zusätzliche Ecke für Daten vorgesehen werden. Eine 2. Partition auf /var/lib gemountet, bietet sich hier z.B. an. (mount mit noatime) Allerdings muß hier noch ein Weg gefunden werden, die Funktionalität der FW (automount, webfrontend und ftp-server verteilt die Daten) abzuschalten oder parallel zu nutzen.

    Zu 3. fällt mir spontan ein, dass man mit o=soft mountet. Als Partitionen bieten sich für / und /var/lib separate exports an. Als Swap könnte man sich auch eine Datei unter /var/swap anlegen und die dann mounten (Bsp. hier).

    4. stelle ich mir problematisch vor, wegen der Dateirechte.

    Und 5. ist der Königsweg mit / auf einer Systempartition, extra Swap und einem Bereich /var/lib für die Daten. (auch hier wäre ein override der Funktionen der originalen FW nötig)

    Im weiteren würde ich eine zweiteilige Strategie mit der Firmware fahren und Pakete einteilen in die Kategorieen:

    a) sinnvoll nur als statisches Paket, da für die Grundfunktion der FB erforderlich (dropbear, callmonitor, ...)
    b) sinnvoll nur als dynamisches Paket, da ohne externen Speicher nutzlos (samba, php, perl, apache, ...)
    c) der ganze Rest (also Mischformen, die irgendwie überall Sinn machen könnten (vsftp, bftp, ...)​

    Für a) würde ich in keinen Fall Pakete für IPKG erstellen, aber Einträge in die IPKG-Datenbank (wegen dependencies) machen. Bei b) ausschließlich Pakete und c) ist imo zu untersuchen. Es könnte für c) Sinn machen, die Pakete quasi virtuell zu installieren; d.h. in die Firmware und in die IPKG-Datenbank aufzunehmen und parallel IPKG-Pakete zu erstellen.

    Letztlich wäre also a) und c) etwa das Gleiche, nur b) wäre ganz was anderes.

    MFG pTweety
     
  19. danisahne

    danisahne Aktives Mitglied

    Registriert seit:
    30 Juli 2005
    Beiträge:
    1,493
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Informatik Studium
    Ort:
    Marktoberdorf
    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.

    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.
     
  20. lord-of-linux

    lord-of-linux Mitglied

    Registriert seit:
    3 Dez. 2005
    Beiträge:
    568
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    Egal ob nacher die Dateien auf Storage oder nicht liegen, was ich wichtig finde ist:
    Die Konfiguration der FB und der Pakete muss das FW-Update überleben. Der Rest ist mir ja eigentlich egal.

    Nochmal ne Frage, die ich bisher nicht 100%ig verstanden habe:
    Wenn das Storage verfügbar ist, dann wird die Ramdisk nicht benötigt, das heißt, mehr Ram bleibt verfügbar?