Mit den bootlogs der 8000 die Ihr mir gemacht habt denke ich habe ich den Fehler gefunden, am Abend gibt es neues Marsu wo man dann auch die Images der 8000 hoffentlich ubifizieren kann.

Die Frage ist halt ob ich es auch für 500hd und 800se machen soll, durch den kleine Flash geht das eigentlich gar nicht, bzw. bringt nicht so viel Bootzeit wie auf den Boxen mit 256MB. Und letztendlich würde es nur im Zusammenspiel mit SqueezeOut funktionieren das der Flash nicht voläuft, weil die üblichen 10% mehr die ubifs nunmal hat bringen uns dort von 90% voll nach dem Flashen auf 100% voll - was wenig sinnvoll ist

Na ja mal sehen, wenn sich willige User finden die das probieren wollen soll es an mir nicht scheitern, Marsu ist es im Prinzip egal auf welcher Boxe es läuft (nur die alte 800 geht nicht mehr, daher ist es auch nur ein mips32el ipk) ich habe das extra so gebaut das die boxen nicht hardcoded sind sondern die Flashgeometrie mit mtdinfo und ubinfo ausgelesen wird befor es sich an die Arbeit macht.

LG

gutemine

Auf meiner 8k mit aktuellem standardkernel aus einem OE 2.0 Image sieht es jetzt so aus:

df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 225.0M 87.2M 137.8M 39% /
devtmpfs 72.9M 0 72.9M 0% /dev
none 73.0M 416.0K 72.6M 1% /var/volatile
/dev/mtdblock2 7.0M 3.8M 3.2M 55% /boot

Damit das auch funktioniert braucht man aber Marsu 0.4 - das kommt aber bald.

PS: Bootzeit ist 2 Sekunden langsamer als auf der 7020HD - also 67 Sekunden statt 65 Sekunden.

LG
gutemine

Bei Merlin und OoZooN im Board gibt es im Marsu Thread auch Kernel zum Testen auf der 800se und 500hd. Man sollte aber SqueezeOut oder ähnliches benutzen sonst passt ein ubifiziertes Image nicht mehr in den Flash.

EDIT: Und Marsu 0.4 ist jetzt auch dort zu finden.

Also kurzer Zwischenbericht nach 2 Tagen Ubifizieren (da das Marsu Plugin jetzt auf 8000, 7020hd und mit der Einschränkung das man halt den Flash irgendwie expanden muss auch auf 500hd und 800se funktioniert):

Bis jetzt hat sich noch KEINER beschwert, was recht selten ist für meine Plugins

Die um 15-20 Sekunden kürzere Bootzeit wird sehr positiv aufgenommen und die Boxen sind durch die lzo Komprimierung statt dem zlib im jffs2 auch spürbar agiler.

Insofern würde ich das ubifs NICHT mehr hergeben wollen!

Probleme mit dem Filesystem hat bist jetzt auch keiner gemeldet, spätestens bis zum Wochenende denke ich sollten wir wissen ob das so bleibt.

Ich würde daher bitten die Patches ins OE 2.0 ehebaldigst einzuchecken, damit mit dem nächsten Kernelupdate schon ein passender Kernel mitkommt bzw. man bei neu gebauten Images keinen Kerneltausch mehr vornehmen muss (so wie bei der 8000) sondern nur mehr mit Marsu konvertieren.

In der autoexec*.bat schreibe ich jetzt:

ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs

statt dem:

root=/dev/mtdblock3 rootfstype=jffs2

Wäre es freundlicherweise noch möglich mit einem postins im kernel-image ipk zu verhindern das diese wieder mit dem jffs2 überschrieben ist, damit das Ganze updatesicher ist und sich die Images ganz normal upgraden lassen ?

So was in der Art als postinst:

#/bin/sh 
if [ `grep ubi0:rootfs /proc/mounts | wc -l` -gt 0 ]; then 
sed -ie s!"root=/dev/mtdblock3 rootfstype=jffs2"!"ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs"!g /boot/autoexec*.bat 
fi 
if [ -z "$D" ] && mountpoint -q /boot; then mount -o remount,ro /boot; fi

LG

gutemine

dann hast du aber eine menge Müll im Image, bei mir sind es 67sek mit Marsu.

Ich habe auch absichtlich keinen Rückweg eingebaut, wenn musst du wieder ein jffs2 Image flashen, aber ich denke nicht dass dies viele tun werden

Netto sind es immer 15-20 Sekunden soweit ich bis jetzt mitgekriegt habe, wenn das image sehr voll war evt. auch mehr.

Nein, die ubifs Images sind nur ca. 10% größer, aber wenn du z.B. Squeezeut verwendest kannst du ubifs haben und nachher trotzdem noch 18MB frei haben. Es macht halt sinn schon vorher Sachen auszulagern als dann ein ubifs image zu haben das den Flash sofort propenvoll hat.

git.opendreambox.org Leser wissen mehr ... wenn/falls es soweit ist.

Eigentlich sollte das anders funktionieren, ich habe das Plugin gemacht, jetzt solltet Ihr berichten was sich verändert/verbessert hat.

Dafür das immer alle über die Bootzeit jammern kannst du 15-20 Sekunden nicht so einfach abtun, aber da die Komprimierung schwächer ist sind die boxen auch flotter beim Upgraden und insgesamt einen Hauch agiler. Und gerade bei großem Flash sind die Performanceunterschiede beachtlich, schließlich hat jffs2 schon einige Jahre auf dem Buckel und wird nicht mehr aktiv weiter entwickelt.

Der Flash zerfleddert durch oftmaligem Upgraden beim ubifs auch nicht so leicht, und da das mkfs.ubifs auch brauchbar performt ist es einfacher Images > 100MB zu sichern. Ubifs braucht eben 10% mehr Platz, weswegen es bei den Boxen mit nur 64MB Flash nur begrentzt tauglich ist, und es braucht auch einen Hauch mehr Memory weil es für seine Performancevorteile mehr cached, deswegen habe ich mit Marsu auch gewartet bis das swapproblem mit den Aufnahmen gefixed war.

Ob du ubifs brauchst oder haben willst musst du selber entscheiden, bei mir haben jetzt sowohl 8k als auch 7020HD ubifs und ich mach das wohl nicht mehr rückgängig.

Und die autoexec*.bat wird nur bei einem kernel update überschrieben, mehr als bitten das beim nächsten alles dabei ist, so das es keine Probleme macht kann ich nicht tun. Allerdings werde ich sicherheitshalber auch ins Marsu plugin 0.5 einbauen das er falls die autoexec*.bat bei einem Upgrade wieder auf jffs2 geändert wurde das vor dem runterfahren wieder zurückpatched. Schöner wäre es halt wenn das kernel-image Paket das gleich selbst machen würde, weil dort geht das mit 3 codezeilen wie weiter oben gepostet.

PS: Und was ich noch vergessen habe, bitte auf der 7020HD beim nächsten kenrel Update auch den SSL87 fürs OE 2.0 reinmachen

LG
gutemine