ipkg und mini_fo

[danisahne]

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

[dsteinkopf]

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

[ptweety]

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.

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.

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.

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

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.

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.

Weitere Ideen oder Probleme?

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:

#!/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

[danisahne]

Wie gesagt:

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

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

[ptweety]

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?

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.

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.

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

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).

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

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?

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:

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:

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

MFG pTweety

[lord-of-linux]

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 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?

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.

[ptweety]

Durch dei 1ste wäre der Ram entlastet, da man sich diesen nicht für die Ramdisk bräuchte.

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

[danisahne]

1. 32MB oder von mir aus auch weniger oder mehr.
2. Eine beliebig Größe, für die dynamischen Pakete

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

[lord-of-linux]

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?

[danisahne]

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

[lord-of-linux]

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?

[kay1234]

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

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?

[McClean]

Oder greift die Box so regelmäßig zu, dass die Platte nie runterfährt?

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

[danisahne]

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?).

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

[ptweety]

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?

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.

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.

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

[lord-of-linux]

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?

Daher kam ja auch mein Vorschlag:

...
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

...

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.

[danisahne]

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?

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

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.

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

[ptweety]

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

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

[danisahne]

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.

[lord-of-linux]

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?