wenn ich mich recht erinnere wird nur der xz compression patch fürs mkfs.ubifs.c angewandt, aber die beiden Patches sollten sich nicht wehtun.

Aber wie schon gesagt, es wäre besser wenn das OE bereits die ganz aktuellen sourcen verwenden würde. Aber ich schaue mal wegen dem mkfs.jffs2.c, weil da ist die chance höher das der Patch funktioniert, weil der ist dort auch schon so alt.

Ich habe mir mal das mkfs.jffs2.c angeschaut - da ist im OE der --ignore patch schon drinnen - Glück gehabt, der einzige Unterschied ist das mein Patch gegen die aktuellen sourcen geht, aber da sich beim jffs2 kaum was getan hat denke ich kann man das so lassen.

Das Einzige was da bei mir anders ist das ich die minilzo.c benutze um dem lzo support zu kriegen und dabei nicht gegen die liblzo gelinked zu sein und die deswegen nicht in die Dependencies machen zu müssen.

ldd mkfs.jffs2 
libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x77ec0000)
libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x77d38000)
/lib/ld.so.1 (0x55550000)
mkfs.jffs2 -L
mkfs.jffs2: error!: 
lzo priority:80 enabled
zlib priority:60 enabled
rtime priority:50 enabled

Weil im OE wird das binary derzeit glaube ich ohne den lzo support gebaut und wenn man die libary als dependency dazu braucht verschwendet das unnötig Platz.

Ich compiliere das dann so damit es ein möglichst kleines binary gibt:

gcc -Os  -fdata-sections -ffunction-sections -o mkfs.jffs2 mkfs.jffs2.c 
compr.c compr_rtime.c compr_zlib.c compr_lzo.c rbtree.c minilzo.c  
lib/libcrc32.o -I include -lz -Wl,--gc-sections
strip  mkfs.jffs2

Damit bleibt eigentlich an Patches nur das Equivalent des --ignore über für das mkfs.ubifs:

--z, --exclude=PATH   	exclude PATH from output relative to the root

Also warten wir mal ob wir die anderen Patches inklusive Push auf das aktuelle 1.5.* der mtd-utils bekommen, dann poste ich auch meinen Patch fürs mkfs.jffs2 und wir wären fertig mit dem Frühjahsrputz bei den mtd-utils für die Dreamboxen.

Ich war mal Optimist und habe meinen mkfs.ubifs patch einfach mit den altem mkfs.ubifs.c aus dem OE probiert.

patching file mkfs.ubifs.c
Hunk #1 succeeded at 111 (offset -2 lines).
Hunk #2 FAILED at 140.
Hunk #3 succeeded at 161 (offset -3 lines).
Hunk #4 succeeded at 201 (offset -4 lines).
Hunk #5 FAILED at 235.
Hunk #6 succeeded at 378 (offset 38 lines).
Hunk #7 succeeded at 602 (offset 33 lines).
Hunk #8 succeeded at 719 (offset 30 lines).
Hunk #9 succeeded at 811 (offset 29 lines).
Hunk #10 succeeded at 1279 (offset 33 lines).
Hunk #11 succeeded at 1577 (offset 33 lines).
Hunk #12 succeeded at 1747 (offset 33 lines).
Hunk #13 succeeded at 2340 (offset 33 lines).
Hunk #14 succeeded at 2362 (offset 33 lines).
2 out of 14 hunks FAILED -- saving rejects to file mkfs.ubifs.c.rej

Ist also gar nicht so schlimm wie ich dachte, weil die 2 Fehler sind nur so wie beim mkfs.jffs2 auch das Problem das der command line options string sich natürlich geändert hat und das zweite meine Anpassungen in der make_path routine.

Ersteres wäre leicht von Hand anpassbar im Patch und für zweiteres könnte ich statt für die exclude paths die normale make_path routine zu pimpen auch eine eigene make_exclude_path routine machen, dann würde es auch mit dem alten code gehen.

Trotzdem wäre es nicht gescheit es noch in die alten sourcen von den mtd-utils 1.4.9 reinzumachen, weil eben die command line options sich teilweise geändert haben und dann erst wieder die Optionen unterschiedlich wären.

Damit hätten wir aber jetzt eigentlich alles beisammen um es auch ins OE 2.0 für die Dreamboxen zu machen, nur ist das nicht meine Entscheidung es auch zu tun, ich kann nur nochmals Bitte, Bitte sagen

LG
gutemine

OK. ich habe den Patch nochmals umgeschrieben damit auch mit dem alten mkfs.ubifs.c nur mehr die Anpassung des optstring um die zusätzlivche z option failed, was aber leicht von Hand im Patchfile gefixed werden kann wenn DMM unbedingt bei den alten mtd-utils 1.4.9 bleiben will:

patching file mkfs.ubifs.c
Hunk #1 succeeded at 111 (offset -2 lines).
Hunk #2 FAILED at 140.
Hunk #3 succeeded at 161 (offset -3 lines).
Hunk #4 succeeded at 201 (offset -4 lines).
Hunk #5 succeeded at 231 with fuzz 2 (offset -4 lines).
Hunk #6 succeeded at 433 (offset 38 lines).
Hunk #7 succeeded at 657 (offset 33 lines).
Hunk #8 succeeded at 774 (offset 30 lines).
Hunk #9 succeeded at 866 (offset 29 lines).
Hunk #10 succeeded at 1334 (offset 33 lines).
Hunk #11 succeeded at 1632 (offset 33 lines).
Hunk #12 succeeded at 1802 (offset 33 lines).
Hunk #13 succeeded at 2395 (offset 33 lines).
Hunk #14 succeeded at 2417 (offset 33 lines).
1 out of 14 hunks FAILED -- saving rejects to file mkfs.ubifs.c.rej

Der entsprechende Patch für die -z Option des mkfs.ubifs.c ist im Anhang.

Und ja ich compiliere es noch gegen die lib*.a damit es möglichst klein bleibt und man die libraries nicht als dependency braucht:

gcc -Os -fdata-sections -ffunction-sections -o mkfs.ubifs mkfs.ubifs.o crc16.o lpt.o compr.o devtable.o hashtable/hashtable.o hashtable/hashtable_itr.o ../lib/libcrc32.o ../ubi-utils/libubi.a /usr/lib/liblzo2.a -lm -luuid -lz ./liblzma.a -Wl,--gc-sections
+ strip mkfs.ubifs

Womit ich jetzt nur freudvoll darauf warte das die 4 Patches eingechecked werden und im Idealfall die Build rezepte angepasst, damit man die vorhandenen mtd-utils binaries und das buildimage auf der Box zum Sichern verwenden kann

Wobei mir der Umstieg auf die neueren Sourcen wie schon erklärt noch lieber wäre

BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE BITTE

LG
gutemine

Als 'PoC' gibt es jetzt auch schon den aktuellen nfibackup kit für die Dreamboxen wo alle binaries aus dem aktuellen Snapshot der mtd-utils und des buildimage mit den hier geposteten Patches drinnen sind.

Damit man sieht das es damit klaglos geht auf der Dreambox ein Image in ein nfi zu sichern, z.B das aktuelle Image im Flash:

nfibackup / /media/hdd/backup

WENN die ganzen patches im OE wären wurde ich ALLE binaries bis auf das nfidump selbst aus dem ipk rausschmeissen und nur mehr Dependencies zu den Paketen aus dem OE setzen so wie es eigentlich sein SOLLTE.

Der --ignore Patch ist zwar im OE schon drinnnen, aber eben nur für den alten Releasestand.

Im Anhang habe ich ihn noch gediffed geten den aktuellen mkfs.jffs2.c code aus einem aktuellen snapshot der mtd-utils.

Mit den Patches die ich also jetzt alle gepostet habe kann man sich in 5min wenn man sich die aktuellen mtd-utils als snapshot zieht auch alle nötigen binaries auf dem Linux PC bauen.

Gerade ausprobiert damit ich auch den versprochenen nfibackup kit für den Linux PC machen kann.

LG
gutemine

Nachdem OoZooN's Board wieder funktioniert habe ich die nfidump kits hier entfernt.

Bei OoZooN im nfiBACKUP Thread gibt es jetzt auch schon nfiBACKUP kit für den Linux PC, wo auch die aktuellen Binaries mit den Patches aus diesem Thread drinnen sind.

Damit kann man zusammen mit dem nfidump für den Linux PC mit Drag und Drop jedes aktuelle Dreambox nfi Image aus- und auch wieder einpacken.

Und wenn Ihr brav testet und die Patches im OE landen mache ich auch eine Windows Version

LG
gutemine

Und wenn Ihr brav testet und die Patches im OE landen mache ich auch eine Windows Version

Brav wart Ihr zwar nicht, aber bei OoZooN gibt es jetzt auch die Windows Version vom nfidump und vom nfibackup zum Testen.

Damit wäre der PoC das die Patches es wirklich wert sind sie rein zu machen erstmal abgeschlossen.

für viele user wäre es doch viel einfacher eine nfi erzeugen zu können wie bei dflash, was denn auch einfach über browser zu flashen ist.
das gab es ja schon zur db2 zeiten im image, es gibt ja genus sachen unter softwareaktualisierung nur eben kein komplettes auslesen des flashes! Dflash ist eigentlich schon ok, nur ohne gm zu nah zu treten ist es manchmal sehr schwer verständnis für ihn zu haben!

Zitat von obi

Ich habe das Thema kurz überflogen und erst mal eine Frage dazu: Ich verstehe den Sinn der Änderung an buildimage nicht ganz. Wieso soll man ein nfi-Image erzeugen können, das sich nicht flashen lässt? Wäre es da nicht besser und einfacher, z.B. einen Tarball oder ein cpio-Archiv als Backup zu erzeugen?

In jedem Fall würde ich den Patch so wie gezeigt nicht übernehmen. WENN, dann nur mit einem Kommandozeilenschalter.

Wenn man auf der Box sichert und eine Flash Erweiterung benutzt ODER das Image von einem USB device bootet ist das Limit eines nfi backups auf die echte Flashgröße der Box eben NICHT ein echtes Limit.

Aiusserdem müsste das buildimage dann ehrlicherweise bereits bei 128MB verweigern ein Image zu erstellen weil das Bios dann sowieso das image nicht flashen kann.

Meinem nfiwrite binary und den damit bestückten Recovery sticks sind diese 128MB aber egal, also wäre für mich auch in diesem Fall maximal ein Warnung sinnvoll.

Ich kann auch gerne eine wi Option reinmachen mit der man eben aus dem error ein warning macht, aber ich brauche die eben nicht, weil es sollte ausreichen wenn man für den benutzer ein Warning ausgibt und das image trotzdem erstellt.

Meinem nfidump ist es dann z.B.auch egal ob das image beim Auspacken auf USB gräßer als der Flash ist-

Letztendlich ist es dem User ja lieber er hat wenigstens eine Sicherung und es ist meines Erachtens sinnvoller auch für größere Images das selbe Format zu benutzen als einmal ein tar bal und einmal ein nfi zu machen.

Im Normalfall sollte die Grenze wenn echter Flash gesichert wird ja eh nicht erreicht werden, also wo ist das Problem da nur zu warnen statt abzubrechen ?

Wenn ich Flasherweierungen und Multibooten anbiete und damit auch so grosse nfi Images sinnvoll und benutzerfreundlich benutzen kann dann will ich mir nicht stäendig das buildimage patchen müssen um es sinnvoll benutzen zu können. Gerade nachdem es jetzt wegen dem loader ipk standardmässig sowieso in jedem Image ist finde ich es halt bitter wenn ich dan nein eigenes mitliefernb muss das unnötig Platz kostet.

Aber wie schon gesagt, wenn Ihr eine Opton haben wollt kann ich gerne einen Patch damit machen, wobei meines Erachtens die Optionen vom Buildimage jetzt schon nicht sehr ausgegoren und benutzerfreundlich sind womit jede weitere Option das nur noch schlimmer machen würde.

Das Buildimage und die mkfs.* mit allen Optionen für alle boxen richtig aufzurufen sind nicht umsonst der größte Hemmschuh für ordentliche Backup Plugins, das sollte man meines Erachtens nicht noch komplizierter machen.

Und ich habe angeboten die sourcen vom nfibuild.c zu posten das auf Dreambox, Linux UND Windows PC ein Dreambox Image als nfi packen kann, nur das ist ein Geben und Nehmen und bis jetzt sind meine kleinen Wünsche noch unterfüllt

PS: Mir fäll es auch manchmal schwer für manche User Verständnis zu haben

LG
gutemine

OK, langes Gerede bringt nichts, im Anhang ist ein patch fürs buildimage mit einer -w option wo aus dem error ein warning wird.

Danke fürs Feedback.

Im Prinzip gebe ich dir ja bei den meisten Sachen Recht, nur die Macht des Faktischen was die User wollen ist leider stärker gewesen.

Ich habe schon jahrelang sowohl Sicherungen als tar als auch als nfi Image in vielen meiner Tools, du brauchst nicht mal raten was immer verwendet wurde und was davon ignoriert wurde.

Und nein mit dem busybox tar wirst du zum Sichern auf der box auch nicht immer glücklich werden, weil das z.B. bei sehr langen filenamen schon recht eng wird wenn man die root mit bind mounts wo hinmountet um die ganzen mountpoints los zu werden oder aus einem imagedirectory eines Multiboot tools gesichert wird und damit der Pfad noch länger wird. Nicht umsonst verwende ich dann mein selbst compiliertes volles tar binary für diese Form der Sicherungen.

Den Patch hattae ich noch mit -i als neue Option getestet und dann nur mehr von Hand auf -w editiert (weil -i oft für info verwendet wird oder für -image stehen könnte, um endlich den imagenamen anzugeben statt mit > xxx.nfi arbeiten zu müssen, was eigentlich auch nicht so wirklich hübsch ist)
Dabei habe ich eine Zeile übersehen, jetzt sollte er aber stimmen, danke für den Hinweis.

LG
gutemine

OK, dann lösen wir das eben ... anders.

Danke für den Fisch.

LG
gutemine

Dann schreibe ich dir hier auch was ich bei OoZooN im Board geschrieben habe:

Zitat

Das bringt mir aber überhaupt nichts, in allen Kits auf der ersten Seite
sind die entsprechenden Binaries ja für die jeweilige Plattform mit
drinnen. Ich hätte gerne das es im OE 2.0 angepasst ist das die binaries
in jedem image bereits richtig drinnen sind damit ich sie als depend
ins nfibuild machen kann statt sie mit zu liefern.

So bringt es auch den Usern wenig wenn die leute 5 ipks installieren
müssen statt eines und die restlichen 4 davon vom Feed zu ziehen, das macht
die Sache was die usability und die Stabilität angeht nur noch
schlimmer.

Und ja ich weis eh das es ganz einfach ist sich das im OE 2.0 selber
anzupassen, aber wenn es nicht in allen Images so ist weil es aus dem
Standard OE kommt wird die Sachen für mich sogar schlimmer weil ich
nicht vertrauen kann das die binaries das tun was sie sollten.

Alles anzeigen