Open SvenRoederer opened 8 years ago
mach doch "einfach" ALLES als jffs2.
Ich denke nicht, das der bootloader jffs lesen kann, um an den Kernel zu kommen
@SvenRoederer der kernel inkl. initrd wird direkt ohne filesystem aus einer mtd-partiton rausgepuhlt. es geht also ohne squashfs.
Ein Anbieten einer neuen Firmware-Variante mit geändertem Dateisystem macht uns Arbeit; eine Unterstützung der 4MB-Router ist vermutlich wegen der schlechteren Kompression und Verwaltung im JFFS2 nicht möglich; wer soll das überhaupt warum wollen/wer legt Wert darauf, dass die Packages in JFFS2 und nicht SquashFS liegt?
Ein "Rolling Release" könnten wir auch machen, indem wir ganz normal Firmware-Images anbieten, dann halt täglich oder wöchentlich. Machen das nicht andere Communities auch so?
@sarumpaet der einzige vorteil bei einem jffs2-only system ist halt, das es keinen platz kostet z.b. den kernel zu tauschen und das ein sysupgrade risikoreicher ist als ein "opkg upgrade"
@sarumpaet ich hatte mal mal mit @booo drüber gesprochen und da kam schnell das Problem auf, wenn Dateien geändert werden, die schon im SquashFS-liegen. Die kosten dann halt immer doppelt Platz im Flash.
@SvenRoederer Schon klar. Mein Vorschlag (siehe letzter Satz meines letzten Kommentars) wäre halt, dass Du Dich direkt in OpenWrt einbringst, wenn Du ein JFFS2-only OpenWrt haben willst (evtl. kann man das ja auch jetzt schon via weitere Build-Parameter bauen, weiß ich gerade nicht), oder wir uns für FF Berlin/Kathleen mal über unseren (nicht-technischen) Umgang mit Releases zusammensetzen, falls wir häufiger Images oder gar einen optionalen Auto-Updater anbieten wollen, so wie das die anderen Communities bereits machen (wäre ich durchaus für). Ein JFFS2-only Kathleen sehe ich nicht als sonderlich sinnvoll an aus den in meinem letzten Kommentar genannten Gründen, es sei denn, der, der das umsetzt, kümmert sich auch um die 4MB-Router. :-)
@sarumpaet images als jffs2-only zu bauen ist nur ein haken in menuconfig
+1 rolling release !!
IMHO würde zumindest die Backbone-Firmware sehr davon profitieren, sofern dann auch wirklich automatisch aktuelle Packages aus dem OpenWRT-Routing-Feed und ein frischer Kernel enthalten sind. Upgrade-kompatibel halte ich hier für nicht relevant, da zwischen den Router-Upgrades entweder Jahre liegen und deswegen ziemlich wahrscheinlich nicht funktioniert oder Standort-Maintainer versiert genug für Neuinstallationen sind.
Please clarify what this ticket is about. Is the idea to move to JFFS2, then merely updating packages through opkg, instead of running sysupgrade? What about configuration migration? This would have to get rewritten completely. What about kernel updates? The kernel isn't part of SquashFS/JFFS2. If you really want to upgrade individual packages with the current setup, does anyone actually care if that 400k or something olsrd package ends up both in SquashFS and JFFS2? You can do that only on a 8+MB flash router which has several MB of free ROM anyways.
-1. we can not even handle "usual" firmware release atm. but we could change the structure of the firmware directory to: stable/ unstable/ (only weekly) snapshots/ (contains the PR builds and seperate branch builds).
Ich hab mal mit Philipp über die Firmwareentwicklung gesprochen und dabei sind die alten Firmwares ein Thema gewesen.
Das Problem bei rolling-releases ist das Squash-FS, in dem die Änderungen zum ROM-Image liegen, dass dann ruck-zuck voll ist.
Meine Idee: nur ein minimales ROM-Image basteln (mit Kernel und winzigem initrd) dass dann das eigentliche Root-fs lädt (wieder squash-fs). Damit sollte doch beim Update eines Pakages die alten Dateien im Squashfs überschrieben werden und der Platz aber nicht doppelt belegt werden.
Was denkt ihr?