Modernisierung der Neutrino onlineupdatefunktionalität

[Barf]

Die Onlineupdatefunktionalität bei AlexW-Images war recht hervorragend für sein Zeit, hat aber seitdem in CVS verfällt und verfault. Siehe auch http://forum.tuxbox.org/forum/viewtopic.php?t=40281. Ich habe in newmake das Erzeugen von konfigurations- und updatelists /etc/cramfs.urls und *.list) automatisiert, und die, in den zitierte Thread "versprochen" update von update.cpp ist hier. Ein mehr ausführliche Beschribung ist hier erhältlig. Ich widerhole nicht alles dadrin hier.

Bitte testen, so dass wir den Patch reinchecken kann.

[JtG-Riker]

Hm da ich leider nicht coden kann blick ich durch den Patch nicht durch, ich hoffe du bedenkst aber das für die cramfs Images extra eine Libcramfs gibt die den CRAMFS-Superblock prüft.

Sowas gibts bei SquashFS nicht, mogway hat dafür einen MD5-Check beim Download der Images eingebaut, beim Manuellen Update wird das Update per LOOP gemountet und die .version geprüft.

Hast du das umgebaut, oder so gelassen?

Wieso baut man CRAMFS nicht aus, SquashFS ist doch mittlerweile der passende Nachfolger, so hat man auch nicht soviel zu supporten...

Gruß Riker

[Barf]

Uhhh, was für eine Dose Wurmer habe ich aufgemacht?

für die cramfs Images extra eine Libcramfs gibt die den CRAMFS-Superblock prüft.

Der cramfs_name-Anruf, richtig? Davon wird "Versionsinformation" gewonnen (Zeile 336-338) womit es kontrolliert wird, dass z.B. Releasezyklus stimmt. Leider ist die Verionsinformation nicht die von .version, sondern aus dem Superblock des cramfs. Dadrin steht version des cramfs (1.6 in aktuelle Version?), nicht die Version des Images. Datum ist die Kreationszeit des images, nicht die werte aus .version. Also, der Check ist völlig daneben.

Sowas gibts bei SquashFS nicht, mogway hat dafür einen MD5-Check beim Download der Images eingebaut,

wobei ich einfach nicht raffe, wie der tickt, der ein MD5-Test für squashfs, und nur für squashfs implementiert.

beim Manuellen Update wird das Update per LOOP gemountet und die .version geprüft.

eigentlich eine gute Idee (auch für cramfs und jffs2); leider etwas fehlerauffällig, aus irgendein Grund scheint loopback mounting in meinem aktuellen Image/YADD nicht zu funktionieren "Block device required". Weiss jemand über das Problem?

Hast du das umgebaut, oder so gelassen?

In Patch oben nicht angefasst, auch wenn es offensichtlich sinnvoll wäre...

Wieso baut man CRAMFS nicht aus, SquashFS ist doch mittlerweile der passende Nachfolger, so hat man auch nicht soviel zu supporten...

Mache gerne ein Thead zu dem Thema auf.

[JtG-Riker]

Uhhh, was für eine Dose Wurmer habe ich aufgemacht?

für die cramfs Images extra eine Libcramfs gibt die den CRAMFS-Superblock prüft.

Der cramfs_name-Anruf, richtig? Davon wird "Versionsinformation" gewonnen (Zeile 336-338) womit es kontrolliert wird, dass z.B. Releasezyklus stimmt. Leider ist die Verionsinformation nicht die von .version, sondern aus dem Superblock des cramfs. Dadrin steht version des cramfs (1.6 in aktuelle Version?), nicht die Version des Images. Datum ist die Kreationszeit des images, nicht die werte aus .version. Also, der Check ist völlig daneben.

Nein ist er nicht, er ist nur im CVS nicht richtig beim Image-Build eingebaut, man muß beim aufruf von mkcramfs die .version auslesen und den Versions-string mit an mkcramfs übergeben, dafür gibt es einen extra Parameter ich habs gerade nicht mehr im Kopf wie das war, im Superblock steht dann die gleiche Versionsnummer wie in der .version - dafür gibts ja extra die libcramfs, wenn da rumgepatcht wurde mit Windows-Tools und so stimmt das nicht mehr und das Image wird nich mehr als gültig erkannt.

Sowas gibts bei SquashFS nicht, mogway hat dafür einen MD5-Check beim Download der Images eingebaut,

wobei ich einfach nicht raffe, wie der tickt, der ein MD5-Test für squashfs, und nur für squashfs implementiert.

Der MD5-Check ist ja in der squashfs.list drin - und die wird ja ausgelesen beim download des online-Updates.

beim Manuellen Update wird das Update per LOOP gemountet und die .version geprüft.

eigentlich eine gute Idee (auch für cramfs und jffs2); leider etwas fehlerauffällig, aus irgendein Grund scheint loopback mounting in meinem aktuellen Image/YADD nicht zu funktionieren "Block device required". Weiss jemand über das Problem?

Du musst in der Busybox den Loop Mount mit einbauen, dann sollte das gehen, könnt man auch ma ins CVS einchecken

Hast du das umgebaut, oder so gelassen?

In Patch oben nicht angefasst, auch wenn es offensichtlich sinnvoll wäre...

Wieso baut man CRAMFS nicht aus, SquashFS ist doch mittlerweile der passende Nachfolger, so hat man auch nicht soviel zu supporten...

Mache gerne ein Thead zu dem Thema auf.

Könnte man einen Thread zu aufmachen, ich bin aufjedenfall dafür, denn wieso 2 Filesystem zu supporten wenn es keiner mehr nutzt...

Riker

[Barf]

Ich habe eine neue Version des Patches http://www.bengt-martensson.de/dbox2/ne ... 02-27.diff. Da werden die Probleme, die JtG-Riker ansprochen hat, addressiert. Auch ftp-images werden jetzt geprüft. Kein Bedarf für filesystemspezifische checks besteht. Kode etwas aufgeräumt. Weil die Klasse CCheckSquashfs (ich HASSE diese blöde "ungarische Namenskonvention"! ) überhaubt nichts squashfs-spezifisches tut, habe ich den Inhalt in flashtool rübergeschaufelt.

leider etwas fehlerauffällig, aus irgendein Grund scheint loopback mounting in meinem aktuellen Image/YADD nicht zu funktionieren "Block device required". Weiss jemand über das Problem?

Mann muss nur CONFIG_FEATURE_MOUNT_LOOP in busybox einschalten. Eigentlich ist es bizarr, loopback support in kernel zu haben, aber nicht in dem mount-programm. Deswegen habe ich diese Änderung in CVS eingecheckt (nur newmake). Loopback mounten funktioniert, wird als Test oben benutzt.

[JtG-Riker]

Ich habe eine neue Version des Patches http://www.bengt-martensson.de/dbox2/ne ... 02-27.diff. Da werden die Probleme, die JtG-Riker ansprochen hat, addressiert. Auch ftp-images werden jetzt geprüft. Kein Bedarf für filesystemspezifische checks besteht. Kode etwas aufgeräumt. Weil die Klasse CCheckSquashfs (ich HASSE diese blöde "ungarische Namenskonvention"! ) überhaubt nichts squashfs-spezifisches tut, habe ich den Inhalt in flashtool rübergeschaufelt.

leider etwas fehlerauffällig, aus irgendein Grund scheint loopback mounting in meinem aktuellen Image/YADD nicht zu funktionieren "Block device required". Weiss jemand über das Problem?

Mann muss nur CONFIG_FEATURE_MOUNT_LOOP in busybox einschalten. Eigentlich ist es bizarr, loopback support in kernel zu haben, aber nicht in dem mount-programm. Deswegen habe ich diese Änderung in CVS eingecheckt (nur newmake). Loopback mounten funktioniert, wird als Test oben benutzt.

Kannst du das im HEAD auch ma einschalten für die Busybox - Danke

Riker

[JtG-Riker]

@Barf

Ich hab mal den neuen Patch getestet und im JTG Image drin, geht soweit alles mit SquashFS - wie es bei cramfs ist kann ich nicht mehr sagen, hab ich nix mehr auffm Rechner

Gruß Riker

[Tommy]

@Barf:

ist der Patch mitlerweile ins CVS eingeflossen? Ist mir beim Patch-Versuch gründlich um die Ohren geflogen.
(8 of 9 Hunks failed) habe den von Deiner Page genommen

[Barf]

ist der Patch mitlerweile ins CVS eingeflossen?

Ja. Mit ein Paar kleine Verbesserungen.

[mb405]

also ich hab mir mal die änderungen angesehen. ich begreife mit meinen bescheidenen codewissen nicht den eintrag in der flashtool.cpp

Code: Alles auswählen

CFlashVersionInfo::CFlashVersionInfo()
{
	load("0200200001010000");
}

die versionsinfo wird doch von der /cdk/makefile.am geschieben. und in der update.cpp wird der release cyklus (hier release 2.00) verglichen.

wenn ich nun nicht 2.00 (sondern 1.12 zbsp) machen will, muss ich da jetzt in 3 dateien rumfummeln ?

flashtool.cpp

Code: Alles auswählen

CFlashVersionInfo::CFlashVersionInfo()
{
	load("0112200001010000");
}

/cdk/makefile.am

Code: Alles auswählen

echo "version=0112`date +%Y%m%d%H%M`" > $(flashprefix)/root/.version

update.cpp

Code: Alles auswählen

#define RELEASE_CYCLE                  "1.12"

ansonsten ist das ja genial, was Barf da wieder gemacht hat

[JtG-Riker]

In der flashtool.cpp musst du nix machen, das ist nur ein beispiel der Stellen soviel wie ich das verstehe, ich hab zumindest nix geändert dort und es geht trotzdem.

Riker

[Barf]

Code: Alles auswählen

CFlashVersionInfo::CFlashVersionInfo()
{
	load("0200200001010000");
}

Aus irgendwelche Grunden (erinnere mich z.Z. nicht genau welche) ist ein Konstruktur ohne Augmente für die Klasser CFlashVersionInfo erforderlich. Im Programm wird sonst nur der Konstruktur mit einem Argument benutzt. Wie Riker sagt, NO PROBLEMO.

Das Problem ist eher, dass, weil Tuxbox in Sinn von CVS keine Releases kennt, und deswegen hat "Version" keine eigentliche Bedeutung (in CVS). Anstatt hat Imagebuilders ihre eigene Semantik zu "Version" definiert.

Natürlich wäre es kein größeres Problem, die Versionsnummer in .version und Neutrino-update (wie seht es mit Enigma aus?) aus eine gemeinsammen Quelle zu erzeugen. Ich kucke mir es an.

[Tommy]

@Barf:

Die Archivierung der Komplettimages klappt ja mit Deinem Vorschlag und den *-local.sh sehr gut. Ist für die root updates ähnliches auch angedacht/möglich bzw ist die vorsehung für ein diesbezügl. -local.sh eingebaut? Ich würde gerne das gesamte Imagebauen automatisieren und die updates auf einen lokalen Webserver (NAS) im Heimnetz zur verfügung stellen. Nun sollte es aber so sein, das pro Tag auf diese Art ein update dazukommt. Ich habe mir das so gedacht:
1. images und root update wird gebaut
2. images und root update wird archiviert
3. img.list und und squashfs.list wird erstellt
4. automatischer ftp upload der files die das aktuelle Tagesdatum tragen und der beiden lists

Da ich für die root updates keine Archivierung -local.sh (gefunden) habe wird es immer wieder überschrieben und ich habe immer nur das aktuelle auf dem server.

Vermutl. habe ich wieder nur ein Ei aufm Kopf und es noch nicht gefunden. Danke für Eure Hilfe

[Barf]

Genau sowas geht recht flott. Hier ist, falls es dir oder jemanden anderen hilft, mein Testskript mit den Namen cramfs.list-local.sh, img.list-local.sh, squashfs.list-local.sh. Die relevante Verzeichness des WWW-Servers ist gemounted als /net/www/dbox2 (ja, ich benutze den Automounter in mein Heimnetzwerk!) Dabei wird dein 4. einfacher.

Code: Alles auswählen

#!/bin/sh

flashprefix=$1
webserverdir=/net/www/dbox2

set -x
case `basename $0` in
    img.list-local.sh)
        cp -p $flashprefix/*.img*x $flashprefix/img.list $webserverdir;;
    squashfs.list-local.sh)
        cp -p $flashprefix/*.squashfs $flashprefix/squashfs.list $webserverdir;;
    cramfs.list-local.sh)
        cp -p $flashprefix/*.cramfs $flashprefix/cramfs.list $webserverdir;;
esac

[Tommy]

ok das hilft mir schon mal weiter - nur suche ich immer noch eine möglich keit zum archivieren der *.squashfs vor dem make squashfs.list . Zur zeit wird ja immer nur ein *.squashfs gefunden und in die liste aufgenommen. Ich bin also auf der Suche nach einer "root-neutrino.squashfs-local.sh" (in der ich archivieren kann) die bei mir irgendwie nicht ausgeführt wird. Ich habe auch leider nirgendswo das skript/makefile gefunden in dem die customizing skripte aufgerufen werden um zu schauen ob etwas derartiges vorgesehen ist

[Barf]

Sowas wie

Code: Alles auswählen

mv root-neutrino.squashfs Tommy-root-neutrino-`date --iso-8601`.squashfs

zum Bleistift? Hier ist etwas mehr allgemeineres, was mann modifizieren kann.

Ich habe auch leider nirgendswo das skript/makefile gefunden in dem die customizing skripte aufgerufen werden um zu schauen ob etwas derartiges vorgesehen ist

@TUXBOX_CUSTOMIZE@ (bzw. @TUXBOX_YADD_CUSTOMIZE@) in Regeln in cdk/make/*.mk. Definiert in configure.ac (am Ende). Beantwortet dies deine Frage?

[Tommy]

Sowas wie

Code: Alles auswählen

mv root-neutrino.squashfs Tommy-root-neutrino-`date --iso-8601`.squashfs

zum Bleistift? Hier ist etwas mehr allgemeineres, was mann modifizieren kann.

ja - genau sowas Deine Seite kenn ich mittlerweile fast auswendig

Nur irgendwann muß ich das "mv" im Ablauf des bauens durchführen. Für die images macht das die

Code: Alles auswählen

neutrino-squashfs.img1x-local.sh
bzw.
neutrino-squashfs.img2x-local.sh

nur eine von mir erstellte

Code: Alles auswählen

root-neutrino.squashfs-local.sh

wird (scheinbar) nicht ausgeführt

EDIT:
Natürlich könnte ich auch die Skripte oben dafür mißbrauchen aber mit dem unteren skript wärs ordentlicher?!

EDIT2:
Hab mich mal durchgehangelt - die entsprechende Stelle wäre dann vermutl. in der partition-images.mk im Bereich "##### root -$gui.$fstype" da müßte dann unter der stelle wo das squashfs gebaut wird der Aufruf zum @TUXBOX_CUSTOMIZE@ drunter ?

[Barf]

nur eine von mir erstellte

Code: Alles auswählen

root-neutrino.squashfs-local.sh

wird (scheinbar) nicht ausgeführt

Es gibt z.Z. keine @TUXBOX_CUSTZOMIZE@ in der Regel für (z.B.) root-neutrino.squashfs. Der Grund war, dass ich mich nicht vorstellen konnte, warum mann diese Regel customizen sollte. Jetzt weiss ich ein Grund dafür, und werde dies zufügen. Sobald CVS wieder da ist....

[Tommy]

nur eine von mir erstellte

Code: Alles auswählen

root-neutrino.squashfs-local.sh

wird (scheinbar) nicht ausgeführt

Es gibt z.Z. keine @TUXBOX_CUSTZOMIZE@ in der Regel für (z.B.) root-neutrino.squashfs. Der Grund war, dass ich mich nicht vorstellen konnte, warum mann diese Regel customizen sollte. Jetzt weiss ich ein Grund dafür, und werde dies zufügen. Sobald CVS wieder da ist....

Das hört sich supi an - habs jetzt als workaround erstmal in neutrino-squashfs.img2x-local.sh eingebaut. (funktioniert, verwirrt aber vermutl. wenn man später mal die funktion sucht)

[dwilx]

Die Updategeschichte ist ja wohl super praktisch, aber mich stört da immer noch die Prüfung des Releasezyklus. Ich kann nicht genau nachvollziehen, wie die tickt, aber korrigiert mich bitte, wenn ich da jetzt was verhaue.
Was etwas doof ist, wenn man ein Update reinspielen will, welches 100% zum Image passt und für die Kennzeichnung man nur eine Revison raufzählen möchte (damit meine ich den String in .version erste Zeile z.B. 0200.. > 0201.. ), wird das Update trotzdem abgelehnt.
Meiner Meinung nach sollte das anders gelöst werden. Wäre es nicht sinnvoller ähnlich wie die anderen .list-Files eine version.list zu erzeugen die wie die primär zur Prüfung verwendet werden kann. Darin müsste dann eine Liste (bestehend aus bisherigen .verision-Strings und etwa Erstellername, Typ, usw.) der Images sein, die mit diesem Update updatebar sind. Die bisherige Releaseprüfung könnte dann sekundär mitlaufen, wenn eine solche Kontrolle bei fehlender version.list nicht möglich ist.
Auch finde ich eine Rel.-Prüfung für Images irgendwie unnütz, weil ja beim Komplettimageflashen sowieso alles platt gemacht wird. Da reicht eigentlich eine Warnung, dass alles hinterher weg ist.

Wäre das eine Alternative?

[JtG-Riker]

Also die Prüfung muss schon sein, du musst ma bedenken das es soviele User gibt die sich damit nicht auskennen, wenn die dann alles flashen können was möglich ist gibts hier noch viel mehr Threads das dies und das nicht geht.

Eigendlich braucht man den Release-Zyklus ja nur ändern wenn sich was grundlegendes an der Struktur des Images geändert hat, ansonsten gibts bei den offiziellen Images eh nur Updates die dann auch passen sollten und geprüft werden. Da Yadi damals die Kernel-Partition ausgelagert hatte musste dort bei jeder Änderung die den Kernel betrifft eine neue Versionsnummer her, sonst wär man da sicher auch noch bei 1.8 oder 1.9 zugegeben unklug gelöst aber man muss das ganzen eben "enduser-fähig" machen.

Ich hab beim Jtg-Image die Grundstruktur von alexW übernommen und bei mir gibts auch nicht für jeden Snapshot eine neue Versionsnummer weil ich das Unsinn finde, ich hab nur wegen Yadi die Versionnummer angepasst, wenn ich noch 1,8 oder so hätte, kannst dir sicher denken wiviele Leute sagen die Images sind ja "alt" Yadi hat aber schon 2.1 oder sowas.

Riker

[Barf]

Die CVS-Software als solches hat keine Versionen. Alle Images die mit unverändertes CVS (HEAD sowie newmake) erzeigt wird, trägt die "Versionsnummer" 200 (umformattiert: "2.0"). Andere Versionsnummer werden von den Imagezüchtern definiert. Irgendjemand hat dann in update.cpp es so geschrieben, dass bei nicht-Expertenupdate, ein Image weigert upzudaten falls die Versionnummer (in Sinn oben) nicht identisch ist.

Die Entscheidung, was mit was updatebar ist, liegt also bei den Imagezüchtern. Benutzt du CVS/dietmarw ist alles sowieso Version 200.

Auch finde ich eine Rel.-Prüfung für Images irgendwie unnütz, weil ja beim Komplettimageflashen sowieso alles platt gemacht wird.

Finde ich ein guter Vorschlag (also Releasezyklus bei Vollimages zu ignorieren). Einwände, Riker?

[dwilx]

@Riker

Also die Prüfung muss schon sein, du musst ma bedenken das es soviele User gibt die sich damit nicht auskennen, wenn die dann alles flashen können was möglich ist gibts hier noch viel mehr Threads das dies und das nicht geht.

Das wäre natürlich nicht im Sinne des Erfinders und ich hatte das so auch nicht gemeint. Die version.list würde da sogar mehr Sicherheit bringen, da man ja konkrete Vergleichsdaten hätte, um Irrtümer 99%ig auszuschalten!
Welche Daten da rein kommen, müsste man mal abwägen. Und für Internetupdates ware das sicher sehr nützlich.
Wie bereits erwähnt, würde die Standardzyklusprüfung ja nicht zwangsläufig wegfallen müssen, sondern weiter greifen, sofern eine version.list-Prüfung fehlschlägt (weil nicht vorhanden oder Daten nicht zutreffen).

@barf

Andere Versionsnummer werden von den Imagezüchtern definiert

Na damit wäre auch ein gewisser Standard möglich oder?

[mb405]

also in der "alten" updatefunktion klappte das prima mit dem test des zyklus.
es kann ja sein zbsb. das an der partitionsaufteileung etwas geändert wurde. dann kann man mit einer neuen nummer das verhindern, das geflasht wird. bei vollimages (komplettimages) ist ja die nummer egal. also ist die nur für root-updates wichtig. eine sehr nützliche sache, wie ich finde. nur wird die in manchen images sehr stiefmütterlich behandelt.

[Nico 77]

Das erste MD5 Check Zeug was da im CVS kahm war Quark, mein Squashfs wurde immer als Cramfs erkannt. So Fehler gab es vorher nicht.
Zudem ist der md5 Check eh irrelevant da sich ein Update eher durch nicht mehr ausreichenden Ram abschießt als durch Fehler beim downloaden. Das sollte wenn dann gecheckt werden meiner Meinung nach.

Ich habe die aktuelle Version des Onlineupdates noch nicht getestet, denke aber das da der Fehler behoben wurde(thx Barf).