ds-mod bei Sourceforge

knox schrieb:
ich finde die handhabung sehr praktisch, da man nicht mehr unterschiedliche pfade berücksichtigen muss, sondern alles im overlay landet.
Ja aber was wenn das Squashfs ausgetauscht wird (Firmwareupdate), dann kann es doch zu Inkonsistenzen kommen, oder? D.h. wir müssen das Overlay bei jedem Firmwareupdate löschen oder sehe ich das falsch.

EDIT: Mein erster Ansatz war auch, das ganze mit mini_fo zu machen, bis mir das Problem der Inkonsistenz aufgefallen ist.
EDIT2: Insbesondere meine ich das: http://lwn.net/Articles/135939/

Mfg
danisahne
 
Zuletzt bearbeitet:
danisahne schrieb:
D.h. wir müssen das Overlay bei jedem Firmwareupdate löschen
ich denke schon. habe mir das zwar nicht genau angeschaut, wie es abläuft, aber im ergebniss eines firmware updates ist das overlay stets leer - alle änderungen sind weg.
damit kann man aber leben, finde ich, denn die vorteile überwiegen. in der praxis kann man mit scp seine sachen schnell sichern und wieder herstellen.
 
Das Overlay soll aber schon auf ein externes Speichermedium? Loopback Device oder das komplette Medium wieder löschen. Wie hier schon mal als (vielleicht überspitztes) Beispiel angeführt wurde: Was wenn jemand sein Fotoalbum über die Box sharen will?

Ein Loopback Dateisystem kann man nicht nachträglich vergrößern? Beschreibbar geht aber schon? Performance?

Sonstige Möglichkeiten?

Mfg
danisahne
 
danisahne schrieb:
  • Man kann beim Erstellen des Image ipkg Pakete direkt nach / installieren -> landen im squashfs
  • Wenn man eine Box mit USB Host hat, kann man nachträglich nach /opt/ Pakete installieren, wo ein USB Massenspeicher gemounted werden kann

Das hört sich für mich etwas kompliziert an. Insbesondere die Paketentwicklung könnte das IMO beeinträchtigen, wenn es nur ein paar wenige Leute verstehen. Besser alles nach /opt und das standardmäßig mit mini_fo überlagern. Wer weiteren Speicher hat, kann den dann als Storage angeben und weitere Pakete installieren. Dazu muß natürlich auch ipkg und die Paketdatenbank unter /opt liegen.

Und irgendwie sollte ein Paket eine Variable NEED_SWAP setzen können und bei 'yes' nur starten, wenn swap da ist.
 
wenn man sowieso auf mini_fo setzt, verstehe ich nicht, wieso man noch pakete nach /opt installieren sollte - das ist doch nur eine unnötige abweichung vom standard. und durch das overlay ist es total egal, welchen pfad man überlagert.
wie ich schon geschrieben habe, würde ich am liebsten alles nach / installieren und das komplette filesystem mit mini_fo machen.

die änderungen am filesystem würde ich versuchen, ins flash zu schreiben. ich weiss zwar (noch) nicht, wie das genau bei openwrt/freifunk-firmware abläuft, aber da hab ich auch kein externes medium und meine änderungen am fs bleiben trotzdem erhalten (ausnahme: firmware update).

ich werde mir das mal genauer anschauen und versuchen, daraus schlau zu werden. die systematik ist jedenfalls praktisch in der handhabung und ist meiner meinung nach daher gut als vorbild für ds-mod geeignet.
 
Beim OpenWrt haben sie ne weitere JFFS Partition, das wird aber wieder nicht bei allen Fritzboxen gehen. Auf der 7050 zum Beispiel wird das niemals funktionieren, da der Flash schon mit dem squashfs voll ist. Was man dann auch tunlichst vermeiden sollte sind ständige Schreibzugriffe auf den Flash, da der sonst zu schnell hinüber ist. Nen externen Flash kann man einfach ersetzen und kostet nicht viel, beim internen ist die Box nicht mehr zu gebrauchen.

EDIT: Wir können das ja mal experimentell auf den 8MB Boxen machen, aber der Regelfall wird das denke ich erst mal nicht.

Mfg
danisahne
 
Zuletzt bearbeitet:
Hallo danisahne,

ich bin in der ganzen Materie leider nicht so tief drin, finde die sache mit minifoo und ipkg sehr interessant.
Ich habe nur eine FB7050, damit also nicht die möglichkeit das Flash über USB zu erweitern, allerdings habe ich immer eine NFS-Share von meinem NAS gemounted und hoffe das auch die später für minnifoo verwendet werden kann und die FB7050 nicht aussenvorbleibt oder sich mit dem internen Flash begnügen muss.

tschüs

chriwi
 
Hallo, läuft der auf der 7141 ?
Brauche dringend openvpn auf der kiste :)
 
frequenzer schrieb:
Hallo, läuft der auf der 7141 ?
Sorry, du bist in dem Thread ganz falsch. Wir diskutieren gerade über Details der Implementierung der kommenden Versionen auf Sourceforge. Da ist aber noch nichts einsatzfähig.
 
@chriwi: NFS wird sicherlich eine Option für das Overlay sein.

Also Zusammenfassend: Als Overlay kann man...
  • ... ne Ramdisk...
  • ... einen USB Massenspeicher ...
  • ... einen NFS Export ...
  • ... experimentell eine weitere JFFS Partition auf dem internen Flash ...
... nutzen. Als Speicherort auf nem externen Medium würde ich sowas wie ds-mod-0.x.y_<md5 hash des dateisystems> bevorzugen, wobei die md5 Summe direkt vor dem Erstellen des squashfs noch ins Dateisystem eingefügt wird. Wäre ne Lösung für das Problem der Inkonsistenzen, weil bei jedem Image ein neuer Overlay-Pfad benutzt wird. Natürlich muss man jetzt wieder dafür Sorge tragen, dass man auf das Verzeichnis nicht über FTP zugreifen kann.

Ich bin aber immer noch der Meinung, dass mini_fo optional sein muss. Ok, das mit /opt/ können wir auch wieder vergessen, aber für die SL kann ich kein mini_fo gebrauchen, also ist es optional. Wer daher Pakete im laufenden Betrieb nachinstallieren will, muss halt mini_fo mitinstallieren, alle anderen können es auch rauslassen.

Mfg
danisahne
 
Hallo danisahne,

> Wer daher Pakete im laufenden Betrieb nachinstallieren will, muss halt
> mini_fo mitinstallieren, alle anderen können es auch rauslassen.

Soll mir recht sein zumindest ist so ein Overlay-Filesystem genau das was ich mir schon immer für all meine Diskless-Embeddedsysteme gewünscht habe und davon die erste Umsetzung, eigentlich würde ich mir das auch für die Dreambox wünschen, aber dfas ist zu (deinem) Glück (oder zu meinem Pech) nicht dein Problem. Und ipkg ist schon auf dem NSLU2 ne tolle sache. :)

tschüs

chriwi
 
ipkg nach / oder nach /opt; alles per overlay?

danisahne schrieb:
Ich bin aber immer noch der Meinung, dass mini_fo optional sein muss. Ok, das mit /opt/ können wir auch wieder vergessen, aber für die SL kann ich kein mini_fo gebrauchen, also ist es optional. Wer daher Pakete im laufenden Betrieb nachinstallieren will, muss halt mini_fo mitinstallieren, alle anderen können es auch rauslassen.
Ist der Ansatz, alle dsmod-Pakete nach / statt nach /opt zu installieren, wirklich eine gute Idee, wenn Ziel des dsmod ist, parallel zu verschiedenen avm firmware Versionen zu laufen?

Overlay (per mini_fo): soll wirklich der gesamte dsmod (also /opt bzw. /) per overlay gemountet werden? Programme haben sehr viele verschiedene Möglichkeiten, auf Dateien zuzugreifen, und wenn das overlay-Dateisystem nur eine davon nicht implementiert, dann läuft das Programm nicht (ist mir mit asterisk, Laborfirmware und unionfs passiert; gewisse Dateien waren für asterisk unsichtbar, die für busybox zugänglich waren; war eine ziemlich unangenehme Fehlerquelle; hatte aber keine Zeit für eine genaue Analyse). Jedenfalls ist das ein Argument dafür, dass mini_fo optional sein sollte.

spblinux
 
Welche "Art" auf Dateien zuzugreifen war das denn?
 
Kann ich nicht genau sagen; der asterisk hat einfach Module (so-Dateien) nicht geladen, obwohl sie vorhanden waren, und ohne unionfs hat alles wieder funktioniert. - Aber wie gesagt, das war mit unionfs und ich hatte keine Zeit, dem genauer nachzugehen. Eventuell ist mini_fo da besser.

spblinux
 
spblinux schrieb:
Ist der Ansatz, alle dsmod-Pakete nach / statt nach /opt zu installieren, wirklich eine gute Idee, wenn Ziel des dsmod ist, parallel zu verschiedenen avm firmware Versionen zu laufen?

Ich würde unter anderem daher niemals / überlagern. Da kann bei fehlerhaften Paketen dann auch wieder zu viel schief gehen. Eine saubere Trennung der Basis-Firmware und der Zusatzpakete ist IMO sehr erstrebenswert. Wenn man optional bei Boxen mit 8MB Flash eine JFFS2 Partition zum Überlagern von / dazunimmt, ok. Aber der Default sollte immer auch ohne Overlay auskommen.
 
ptweety schrieb:
der Default sollte immer auch ohne Overlay auskommen.
soweit ok für mich.
aber ich finde auch, man sollte im default auf jeden fall auch ohne externes medium auskommen (boxen ohne usb), und möglichst trotzdem änderungen am dateisystem vornehmen können, zumindest änderungen an konfigurations- und nutzdaten.
ist nur ne doofe anforderung aus usersicht :-Ö
 
knox schrieb:
aber ich finde auch, man sollte im default auf jeden fall auch ohne externes medium auskommen (boxen ohne usb), und möglichst trotzdem änderungen am dateisystem vornehmen können, zumindest änderungen an konfigurations- und nutzdaten.
Wird sich eben nicht auf allen Boxen realisieren lassen können.
 
wäre es nicht möglich, auch den aktuellen labor kram von olistudent bei sourceforge im svn zu halten?
so wäre das arbeiten in der gruppe, das viele rumgepatche und pakete-aktualiseren sicher viel einfacher.
der weg über das forum ist zum veröffentlichen von dateien und updates wirklich sehr umständlich.
 
Ein Problem sehen olistudent und ich noch: Ich weiß nicht, ob die Patches von AVM Copyright geschützen Dateien unter der GPL veröffentlich werden dürfen, daher wird die neue Version (im SVN in der Entwicklung) ohne solche Patches auskommen. Ansonsten hab ich nichts dagegen, aber die Patches (z.B. des Webinterface) wollt ich dort nicht hochladen.

Mfg
danisahne
 
Wie ist den eigentlich der aktuelle Stand in der Sache mini_fo / ipkg?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.