Hi !

Um die Dreambox zu sichern benötigt man ja diverse binaries aus dem OE die primär aus den mtd-utils kommen:

mkfs.jffs2 *

sumtool

mkfs.ubifs *

ubinize

nanddump *

buildimage *

Die mit * gekennzeichneten sind allerdings so wie sie im OE für mipsel gebacken werden UNBRAUCHBAR, weil Patches und nötige Anpassungen fehlen.

Ich habe mir daher von all diesen Binaries eigene Versionen gemacht wo die nötigen Anpassungen drinnen sind.

ABER eigentlich ist das für mich UNNÖTIGE Arbeit die ich gerne loswerden würde.

Ausserdem muss ich dann meine Version der binaries immer in die Plugins mit rein packen, statt die vom Feed verwenden zu können und entsprechende Dependencies ins Plugin zu machen.

Meine Frage wäre daher ob wenn ich hier die nötigen Infos und patches zusammentrage man diese BITTE ins OE einchecken könnte?

Beispiele sind z.B. beim mkfs.* fehlen die ignore path Patches, beim mkfs.ubifs fehlt der realpath patch, es fehlt die lzo compression beim mkfs.jffs2, das nunddump braucht ein -cutoff um den secondstage loader aus dem /dev/mtd1 extrahieren zu können, das buildimage sollte wenn das Ergebnis von der Größe her größer als der Flash ist kein Fehler mit Abbruch sondern nur eine Warnung kommen, etc.

Wenn das OK wäre würde ich binary für binary die nötigen Änderungen hier posten, das Ergebnis testen bis wir alle gefixed haben.

Ich habe nämlich ein nfibackup binary geschrieben das für ALLE Dreamboxen mit diesen Binaries mit einem einzigen Aufruf nfi Images erstellen kann. In dem ist die ganze Flashgeometrie und die Parameter für den Aufruf der anderen Binaries hinterlegt. Damit ist es dann WESENTLICH einfacher Sicherungen zu machen und auch entsprechende Plugins dafür zu bauen, und es funktioniert auch am Linux UND am Windows PC.

Nur benötigt das eben funktionierende Binaries damit es auch ein richtiges nfi Image produziert!

LG

gutemine

Im Prinzip verwende ich den aktuellen Snapshot aus dem mtd git.

ABER da sind eben manche Patches wie das --ignore=/path beim mkfs.jffs2 nicht drinnen und ich muss sie dann manuell hinzufügen. Nur compiliere ich die Binaries auf der Box, es geht mir also um die Binaries die im OE für mipsel gebacken werden und am Feed landen, nicht um die mit denen am Linux PC das Image erstellt wird.

Auf dem Linux PC beim nfi machen braucht man manche der Patches zum Image bauen nicht, auf der Box z.B. schon, weil man z.B. mit --ignore=/boot verhindert das /boot im root.jffs2 landet.

Oder im OE wo die Images flashbar sein müssen macht es Sinn abzubrechen wenn sie größer sind als der Flash, auf der Box sichern die Leute aber auch erweiterte oder Multiboot Images, womit man das nfi trotzdem erstellen sollte (mit Warnung das es nicht mehr in de Flash passt) damit das Backup komplett ist - auch wenn es dann ohne 'Hilfe' nicht mehr in den Flash passt.

Das mkfs.jffs2 im OE kann z.B. keine LZO compression weil Ihr nur zlib verwendet, es gibt aber Images die aus Performancegründen lzo verwenden, usw. ...

Wenn man mit nandump den loader aus /dev/mtd1 der box extrahiert wird der letzte Block mit extrahiert und die checksum stimmt dann nicht, daher muss man ein paar codezeilen im nanddump dazu machen das nur bis zu xFF extrahiert wird, was ich über einen -cutoff Parameter aufdrehen kann.

Es ist also ein Mix aus fehlenden Patches die es zwar gibt und auch signed off sind aber nicht im Standard sind, aus kleinen Codechanges die nötig sind damit die Binaries auch auf der Box gehen und aus zustätzlichen build defines um z.B. die LZO compression beim mkfs.jffs2 mitzubauen,...

Ich muss das also auch erst binary für binary zusammensuchen und die diffs erstellen und posten, wenn sich wer das ansieht und ggf. einchecked würde mir das schon reichen.

Machen wir am Abend mal einen kleinen Test mit dem nanddump und dem buildimage, da sind die Changes überschaubar weil nur wenige codezeilen.

LG

gutemine

Besonders weh tut mir das buildimage, weil das ist weil es für das secondstage loader binary umhämmern benutzt wird in jedem image schon drinnen, da wäre nur nötig aus dem Fehler wenn das Image eigentlich zu groß ist ein Warning zu machen und weiterzutun:

--- org/buildimage.c	2013-08-22 23:19:30.453467477 +0200
+++ patched/buildimage.c	2014-02-13 18:38:16.277082444 +0100
@@ -390,8 +390,7 @@
 			num_partitions, (unsigned long long)st.st_size,
 			(unsigned long long)badblock_safe(val), filename);
 	if (st.st_size > badblock_safe(val)) {
-		fprintf(stderr, "Partition #%u (%s) is too big. This doesn't work. Sorry.", num_partitions, filename);
-		return false;
+		fprintf(stderr, "Partition #%u (%s) is too big. This doesn't work in Flash.", num_partitions, filename);
 	}
 
 	f = fopen(filename, "r");

Wenn Ihr das so einchecken könntet würde es mir schon sehr helfen weil ich dann das binary aus dem dreambox buildimage ipk direkt verwenden könnte OHNE ständig mein Eigenes zu benutzen, wo auch NUR diese 2 Zeilen angepasst sind.

Bezüglich des nanddump - kann mir wer das aktuelle nanddump.c aus dem OE 2.0 posten, dann diffe ich meine changes dagegen, weil das sind auch nur ein paar Zeilen.

Bitte & Danke!

LG
gutemine

Für die die nicht glauben wollen das so ein nfibackup binary funktioniert habe ich jetzt einen Testkit im nfiBACKUP Thread bei OoZooN hochgeladen, ABER der hat eben auch alle nötigen binaries noch von mir entsprechend gepatched mit rein reingepackt.

>>> Bezüglich des nanddump - kann mir wer das aktuelle nanddump.c aus dem OE 2.0 posten, dann diffe ich meine changes dagegen, weil das sind auch nur ein paar Zeilen.

Kann nicht mal wer kurz in seinem OE nach dem nanddump.c suchen und mir das File hochladen ???

Und nein, damit war und ist sicher nicht Ghost gemeint!

Und ja ich weis das ich mir selber wieder mal ein OE 2.0 runterladen könnte, aber es geht ums Prinzip das sich schon wieder alle zurück lehnen.

Und wenn es eh niemandem Interessiert dann können wir den Thread hier auch closen aber es braucht dann KEINER mehr jammern das man mit den Binaries aus dem OE nicht so einfach auf der Dreambox ein nfi image machen kann!

LG
gutemine

Der Total Commander sucht noch

Du wirst die Datei auch nicht auf der dreambox finden, es geht umd das OE auf dem Linux PC wo das Image gebaut wird. Dort holt sich das buldscript die mtd-utils sourcen und X-compiliert es zu einem mipsel binary das dann in ein ipk gepackt wird und auf deiner box über den Softwarefeed nachinstalliert werden kann.

Aber weil OoZooN sein Board noch nicht wieder online ist findet Ihr im Thread weiter unten die aktuelle Version vom nfibackup wo auch das aktuelle nanddump mit der --truncate Option gepatched drinnen ist um den Loader aus dem Flash zu extrahieren mit folgenden Befehl:

nanddump --truncate --noecc --bb=skipbad --omitoob --file secondstage.bin /dev/mtd1

Aber das nfibackup macht natürlich auch das für Euch

LG
gutemine

Ich verstehe nur Bahnhof, tut mir Leid aber da bin ich raus

Der Thread ist nicht umsonst hier im enigma2 Developer Bereich, wenn du kein OE zum entwicklen auf deinem Linux PC hast wird es schwierig hier was beizutragen.

Aber genau deswegen hätte ich eben gerne das wenigstens das was nötig ist im OE gleich mitgebaut wird und dadurch in allen Images richtig auf dem Feed bzw. im Image landet.

Und wenn es eh jedem egal ist bin ich AUCH raus, nur dann hat keiner mehr ein Recht Kritik zu üben wenn Ihm meine Binaries nicht gefallen

Zitat von gutemine

.... bin ich AUCH raus ...

bitte nicht nur versprechen, sondern auch halten!

Schau, wenn ich anbiete zu helfen damit Ihr es alle einfacher habt und das Angebot geht ins Leere, dann werde ich mich nicht aufdrängen und du musst mich deswegen auch nicht beleidigen.

ABER dann ziehe ich auch daraus meine Schlüsse, und handle entsprechend. Und Jeder der mich dann ab jetzt anjammert warum das Sichern nicht so einfach ist oder meine Binaries plötzlich nicht mehr funktionieren, oder auf Klonen nicht funktionieren,... DER kann dann gerne hier nachlesen das ich NICHT ich schuld daran bin das es weiterhin so ist.

LG
gutemine

eigentlich sollten die alle gleich sein, weil DMM eben keine Pathes anwendet - aber poste mir bitte das erste im *dream3* directory, dass andere müsste das aus dem git sein.

Ich muss eh nur testen ob mein patch gegen den aktuellen snapshot auf das file applied.

Weil der snapshot basiert natürlich auf 1.5.0 und nicht auf dem 2 Jahre alten 1.4.9 das DMm verwendet. Und ich habe wenig Lust den zu backporten.

Beim nanddum wird das kein Problem sein, aber beim mkfs.ubifs auf jeden Fall, weil da hat sich viel getan in den letzte 2 Jahren.

Insofern müsste Ghost das ganze Rezept wohl wenigstens auf 1.5.0 pushen.

@Fred*

Du unterstellst mir da etwas das ich jetzt besser NICHT kommentieren, schon weil es hier nichts zu suchen hat.

Ich kann auch einfach die Patches posten wie sie sind ohne Erklärung und mich wieder verziehen nach dem Motto Friss oder Stirb.

Statt desssen versuche ich zu erklären was und warum fehlt, aber wenn das wieder ein Monolog wird und nichts rauskommt ausser das ich es mir selber machen darf dann geht es in dem Fall hier ins Leere, weil das habe ich schon vor langer Zeit.

Jetzt wo auf einmal alle jammern das und warum man mein dFlash zum Sichern verwenden muss lache ich mir eben NICHT ins Fäustchen, sondern biete an zu helfen das jeder das selbe machen kann. Ich habe mir sogar die Arbeit gemacht mit dem nfibackuo ein Binary zu machen das die ganze Komplexität des Sicherns rausnimmt, womit jeder Idi*t damit eine Sicherung oder ein entsprechendes Plugin machen kann,

NUR dazu müsstet Ihr wenigstens ein bisschen was mithelfen, wenn du das schon wieder als Spielchen oder unfair ansiehst tut es mir leid, aber ich sehe das nicht so.

Und ich habe versprichen wenn ich die nötigen Patches im Standard habe und der auch die aktuellen sourcen verwendet und ICH mir damit in Zukunft die Arbeit erspare das ständig mitzuschleppen, das ich dann gerne auch die Sourcen vom nfibackup.c z poste damit man auch das einchecken kann und endlich Ruhe ist was das Sichern angeht.

Also überlege dir bitte was du schreibst bevor du hier kritisierst.

marthom

Danke, ich probiers gleich aus.

LG
gutemine

Hunk #1 succeeded at 53 (offset 1 line).
Hunk #2 succeeded at 89 (offset 1 line).
Hunk #3 FAILED at 103.
Hunk #4 succeeded at 114 (offset 1 line).
Hunk #5 succeeded at 182 (offset 7 lines).
Hunk #6 succeeded at 215 (offset 4 lines).
Hunk #7 succeeded at 452 (offset 4 lines).

Fast geschafft, der eine Hunk der failed ist nur die short_option - weil in der 1.4.9 da eine option h noch nicht existiert (was eigentlich ein bug ist weil help in den long optionen sehr wohl da ist) und in der 1.5.0 schon. Trotzdem bringt das wenig den Patch einfach nur backzuporten, weil im aktuellen nanddum das -bb=skipbad die -b option ersetzt und ich mich nicht mit alten Optionen ärgern will, also bitte, bitte auch die Version raufziehen.

Im Anhang ist der Patch für den aktuellen stand, falls Ihn wer trotzdem auf das alte 1.4.9 anwenden will muss er die eine Zeile halt noch anpassen, aber wie gesagt das bringt wenig, spätestens beim mkfs.ubifs müssten wir den aktuelleren Stand verwenden, beim ubifs hat sich einfach zu viel getan das ich das zurückportieren würde, weil dort wäre das mehr als 1 Zeile.

Und was macht der Patch:

das nanddump kriegt eine zusätzliche -t option für truncate wo beim dumpen nur solange gelesen wird bis man FFFFFFFF findet. Damit kann man den secondstage loader aus dem /dev/mtd1 lesen ohne ihn nachher noch mühsam trimmen zu müssen. Diesen Patch haben ich und adenin schon vor Jahren geschrieben als es mir zu blöde wurde das die Leute zum Sichern ständig den Laoder aus dem OE runterladen mussten um ihm ins nfi dazu zu packen

nanddump --noecc --omitoob --bb=skipbad --truncate --file=/tmp/secondstage.bin /dev/mtd1

Im alten nanddump müsste es dann so sein wenn ich mich recht erinnere:

nanddump -t -n -o -b -f /tmp/secondstage.bin /dev/mtd1

Die restlichen beiden Patches (also fürs mkfs.jffs2 und mkfs.ubifs.c) gibts aber erst wenn der fürs buildimage und der fürs nanddump im OE sind und die Versionen passen

Wenn jemandem fade ist kann er sie aber auch schon hier nachlesen:

https://github.com/SIFTeam/ope…n-to-mkfs-jffs2-git.patch

http://patchwork.ozlabs.org/patch/166053/

Wobei der fürs mkfs.jffs2 eh passt, nur der fürs mkfs.ubifs hat ein paar schwere bugs und ich habe Ihn noch ein bisschen gepimped damit man steuern kann ob nur directory inhalt oder auch directory selbst excluded wird. Vor allem hat sich im mkfs.jffs2 kaum mehr was getan, im mkfs.ubifs.c schon, ich musste den zweiten Patch also gegen die aktuellen sourcen komplett von Hand einbauen und auch noch die ganzen Fehler fixen.

Sobald man die Patches drinnen hat muss man nicht mehr mühsam mit bind mounts die anderen mounts eines images losewerden, etc.

LG
gutemine

marthom

Kannst du noch nach dem mkfs.jffs2.c und dem mkfs.ubifs.c suchen, dann kann ich dafür auch schauen ob, bzw, wie gut die Patches zum derzeit aktuellen code im OE passen.

LG
gutemine