Modernisierung der Neutrino onlineupdatefunktionalität

Beitrag von **mb405** » Montag 3. April 2006, 18:11

ja, das mit cramfs verstehe ich nicht in der update.cpp

#define LIST_OF_UPDATES_LOCAL_FILENAME "cramfs.list"
#define UPDATE_LOCAL_FILENAME          "update.cramfs"
#define RELEASE_CYCLE                  "2.0"
#define FILEBROWSER_UPDATE_FILTER      "cramfs"
#define FILEBROWSER_UPDATE_FILTER_ALT  "squashfs"

ich bau ja nur squashfs, und da war es bist jetzt immer.

Code: Alles auswählen

#define LIST_OF_UPDATES_LOCAL_FILENAME "squashfs.list"
#define UPDATE_LOCAL_FILENAME          "update.squashfs"
#define RELEASE_CYCLE                  "2.0"
#define FILEBROWSER_UPDATE_FILTER      "squashfs"

kann man das nicht ändern ?? aber eigentlich ist es ja wurst, wie das heisst.

Beitrag von **Barf** » Montag 3. April 2006, 21:38

dixidix hat geschrieben: @barf
Andere Versionsnummer werden von den Imagezüchtern definiert
Na damit wäre auch ein gewisser Standard möglich oder?

Irgendwie mussen sie ja sich profilieren

. Spass beiseite, ich sehe es genau umgekehrt: Es ist durchaus Sinnvoll das Imagezüchter A nicht ein update des Root-partition mit einem rootfilesystem von Imagezückter B unterstützen will.

Am Bestens wäre es ein "Updatefamilieidentifikator" einzuführen. Dies soll eine beliebige Zeichenfolge sein (gerne, aber nicht a priori notwendig, für ein Mensch sinnvoll). Image lassen sich mit rootimages mit dem gleichen Updatefamilieidentifikator updaten, aber nicht mit andere. Eigentlich nicht SOO grosser Unterschied zu Releasezykeln...

kann man das nicht ändern ?? aber eigentlich ist es ja wurst, wie das heisst.

Alle erwünschte Funktionalität ist da, alle gänglige Fileextensions wird erkannt, es ist nur das der Name /etc/cramfs.urls anachronistisch und leicht irrefürhend ist. Ich glaube, der name zu ändern hat mehr Nachteile als Vorteile. (Wurscht, nicht wurst, sowas isst man.)

Falls mann bei Vollimages der Relesezyklus (oder "Updatefamilienindikator") ignorieren soll, heiss dies leider dass wir erst die Datei runterladen muss, weil sonst keine sichere möglichket gibt, updates von Vollimages zu unterscheiden. (Falls alle newmake und die Fileextensions drin benutzen wurde es gehen

)

dwilx · Beitrag von **dwilx** » Montag 3. April 2006, 21:58

@barf

"Updatefamilieidentifikator"

Na das klingt ja wie beim Onkel Doktor

, aber wahrscheinlich nicht besser zu benennen.

Das Wort muss man sich auf der Zunge zergehen lassen! Erinnert mich an die indikative Sakazität, was das auch sein mag... Scherz bei Seite.

Ich denke sowas wäre wohl am sinnvollsten!

Beitrag von **Tommy** » Montag 17. April 2006, 20:13

evtl. kann mal jemand troubleshooten?

ich habe eine /etc/cramfs.urls mit folgendem inhalt

Code: Alles auswählen

http://192.168.178.100:8080/updates/cramfs.list
http://192.168.178.100:8080/updates/squashfs.list
http://192.168.178.100:8080/updates/img.list

wenn ich http://192.168.178.100:8080/updates/squashfs.list vom browser aufrufe wird ordnungsgemäß angezeigt:

Code: Alles auswählen

http://192.168.178.100:8080/updates/Special-root-neutrino-2006-04-17.squashfs df8a48aafd9677ca7c7a9536c46c8223 1200200604171930 Special-root-neutrino-2006-04-17.squashfs

wenn ich http://192.168.178.100:8080/updates/Spe ... 7.squashfs vom Browser aufrufe beginnt der download - Datei ist also da

Gehe ich jetzt auf der Box unter Service/Software aktualisierung/nach neuer Version suchen bekomme ich einen Fehler "kann Info nicht laden". Updatemodus steht auf "Internet"

übrigens - img.list und cramfs.list gibt es nicht. Der Server ist ein thttpd auf meinem NAS und ist uneingeschränkt aus dem Intranet erreichbar.

Beitrag von **Barf** » Montag 17. April 2006, 22:15

Ich kann kein Fehler entdecken; alles scheint OK zu sein. Ich kann auch nicht das Problem reproduzieren.

Die Fehlermeldung bekommt mann, siehe update.cpp, hier

Code: Alles auswählen

if (urls.empty())
	{
		ShowHintUTF(LOCALE_MESSAGEBOX_ERROR, g_Locale->getText(LOCALE_FLASHUPDATE_GETINFOFILEERROR)); // UTF-8
		return false;
	}

falls kein einziges *.list runtegeladen werden kann. Also klappt es nicht mir squashfs.list. Kucke in Konsolelog für Fehlermeldungen. Probiere auch falls wget http://..../squashfs.list (auf der dbox) läuft.

Beitrag von **JtG-Riker** » Montag 17. April 2006, 22:19

@Barf

Wie wär es wenn man die /etc/cramfs bzw. squashfs.urls in /etc/update.urls umbenennt, dann wär die Namensgebung Dateisystem unabhängig.

Gruß Riker

Beitrag von **mb405** » Montag 17. April 2006, 22:29

@Tommy
kann es sein, das dein inhalt der squashfs.list falsch ist ??

Beitrag von **Tommy** » Dienstag 18. April 2006, 05:05

@Barf: Jetzt ist glaube ich der Moment für einen USB<->seriell Adapter gekommen. Ich bin alles zigmal durchgegangen . auch ein

Code: Alles auswählen

cd /tmp
wget http://192.168.178.100:8080/updates/squashfs.list
cat squashfs.list

von der box aus ist erfolgreich. Inhalt wird angezeigt.

@Riker: dafür

@mb405: mhh - die wird ja automatisch gebaut. Da habe ich keinen Einfluß drauf. Ich glaub da mal einfach Barf wenn er sagt: unauffällig

Beitrag von **Barf** » Dienstag 18. April 2006, 10:06

Tommy hat geschrieben:@Barf: Jetzt ist glaube ich der Moment für einen USB<->seriell Adapter gekommen.

Theoretisch wäre vielleicht die "Netzkonsole" (suche nach "netconsole") eine Alternative....

Ich bin alles zigmal durchgegangen . auch ein
Code: Alles auswählen
cd /tmp
wget http://192.168.178.100:8080/updates/squashfs.list
cat squashfs.list
von der box aus ist erfolgreich. Inhalt wird angezeigt.

Falls dein WWW-server loggen kann bringt dies möglicherweise ein Hinweis.

@Riker: Ich finde den Vorschlag gut. Einizige Nachteil ist dass Leute die ihre neutrino.conf bei Updates rezykeln (und das sind schätzungsweise 95%...) manuell ändern muss (Service -> Softwareupdate -> Expertenfunktionen -> Konfigfile). (Auch falls default in neutrin richtig ist!) Aber falls sowas ein Killerargument wäre könnte mann ja niemals was ändern... FAlls jemand dagegen ist, bitte melden. Sonst ändere ich es.

@mb405: Die Fehlermeldung bedeutet dass die Datei (URL eigentlich) nicht geladen werden kann, unabhängig von Inhalt.

Beitrag von **JtG-Riker** » Dienstag 18. April 2006, 10:10

Ich würd das beim nächsten Komplettimage mit einbauen, solang kann ich es mir lokal ja noch zurückpatchen.

Da ja eh kein Unterschied mehr zwischen squash und cramfs gemach wird ist es sicher auch nur logisch so einen speziellen Namen zu verbannen.

Riker

Beitrag von **mb405** » Dienstag 18. April 2006, 10:10

also netconsole geht zwar bei mir, nur loggt die leider nicht alles. es fehlen ne menge loggausgaben, die im comlog erscheinen.

Beitrag von **Tommy** » Dienstag 18. April 2006, 10:43

kann man als zwischenlösung nicht beide Dateien checken? Erst update.urls und falls nicht vorhanden cramfs.urls. Irgendwann kann man ja dann die Abfrage cramfs.urls weglassen.
Das mit der neutrino.conf ließe sich in den Startdateien fixen WENN man ein Interface zur neutrino.conf hätte (anderer Thread) oder in der neutrino.cpp selber beim ersten Start (ich weis nicht ob es sowas wie "run once" unter windows gibt)

@Barf: thttpd.log - guter Tipp - teste ich gleich heute abend. Der thttpd auf dem All6200 kommt mir nicht sonderlich stable vor. Was mich nur irritiert ist, das das wget klappt. Allerdings habe ich nach dem wget Versuch heute morgen nicht noch einmal einen updateversuch von neutrino gemacht. Ausführlicher Test heute abend

Edit: kann es sich um einen timeout handeln? Die Platte im NAS pennt meist und muß erst anlaufen. Die Rückmeldung vom thttpd kann also schon mal 5 Sek. dauern. Nicht das wget von der console da toleranter ist - oder wird im update.cpp auch wget genommen?!

Beitrag von **Barf** » Dienstag 18. April 2006, 11:19

Tommy hat geschrieben:kann man als zwischenlösung nicht beide Dateien checken? Erst update.urls und falls nicht vorhanden cramfs.urls.

NO WAY! Code zu schreiben, debuggen. Code die veraltet wird, weil nicht mehr gebraucht. Das alle um "faule" Benutzer zu "schützen". Ein anderen schlechten Vorschag wäre ln -s /etc/update.urls /etc/cramfs.urls. Symlinks sind für das Filesystem was GOTO für Programmcode ist.

Irgendwann kann man ja dann die Abfrage cramfs.urls weglassen.

Ist nicht anderes als die Benutzerumstellung zu Zeitpunkt "irgendwann" zu verschieben.

Das mit der neutrino.conf ließe sich in den Startdateien fixen WENN man ein Interface zur neutrino.conf hätte (anderer Thread) oder in der neutrino.cpp selber beim ersten Start (ich weis nicht ob es sowas wie "run once" unter windows gibt)

Es gibt schon dies in rcS (newmake only (z.Z.))

Code: Alles auswählen

if [ -e /var/etc/.initialize ]; then
        /etc/init.d/initialize && rm /var/etc/.initialize

fi

kann es sich um einen timeout handeln? Die Platte im NAS pennt meist und muß erst anlaufen. Die Rückmeldung vom thttpd kann also schon mal 5 Sek. dauern. Nicht das wget von der console da toleranter ist - oder wird im update.cpp auch wget genommen?!

In update.cpp wird die (Neutrinoeigene) Klasse httptool benutzt, die in wesentlichen ein Wrapper um libcurl darstellt. Es ist möglich, dass du ein neuen Bug dadrin entdeckt hast. Ich habe schon einmal httptool gefixt.

Ein Möglichkeit ist dass du erst neutrino-update versucht, dies schlägt wegen langsamme responszeit fehl, hat aber als Nebeneffekt, dass Dornröschen geweckt wird. Danach klappte es auch mit dem N....

Beitrag von **Barf** » Dienstag 18. April 2006, 11:57

Von http://forum.tuxbox.org/forum/viewtopic ... 308#297308

Ich wäre für eine einzige "updates.list". updates.cpp sollte so intelligent sein die Informationen aus der updates.list aufzudröseln und nur die updates anzuzeigen (bzw. die nicht passenden "auszugrauen") die auf das System und in den Release cycle passen. Ich glaub das wäre der optimalzustand denke aber das es ganz schön aufwendig ist.

Ich sehe es nicht so. Neutrino/update.cpp hat nur zugang zu den Filenamen, die nicht einmal einheitlich sind. In der Vergangenheit war es die Verantwortung der Imagezüchter, durch /etc/*.urls und *.list nur geeignete Updates anzubieten. Deswegen macht es u.U. Sinn, sowohl (z.B.) cramfs.list und squashfs.list zu haben.

In dem "modenisierte" update.cpp wird einige checks mehr gemacht, aber erst nach Download (die Information stehen in *.list nicht zu verfügung). So wird ein Vollimage nur geflasht falls die Größe (exakt) stimmt, und als Update nur falls sie <= Partitionsgröße ist.

Beitrag von **Tommy** » Dienstag 18. April 2006, 13:14

die Information stehen in *.list nicht zu verfügung

warum eigentlich nicht?
Update/File Typ 1-9 (oder ein anderer aussagekräftigerer Schlüssel) - muß natürlich während der "Bauzeit" identifiziert werden und mit in die updates.list und auf der Box werden dann halt nur updates des Types angezeigt der paßt.
Evtl wäre auch ein separates Programm/skript sinvoll was make *.list ersetzt und auch standalone ausführbar ist. Dann könnte man erst alle updates ins www Verzeichnis packen und das "List-Erstellungs-Programm" drüberbügeln lassen. (evtl. auch als cronjob direkt auf dem Server)

Evtl. sollten aber auch Riker, dietmarw und die Yadi's mit einbringen und Vorschläge bringen. Wenn's einmal angepackt wird sollte vllt gleich ein neuer Standard etabliert werden der für alle offiziellen Imager OK ist.

Beitrag von **Barf** » Dienstag 18. April 2006, 13:36

Code: Alles auswählen

<download-images>
  <image type="full" hardware="dbox2" hardware_variant="2x" size="8257536" bad_magics="checked" MD5_sum="91339d686829f38d1f781fd98cba4158" maturity="release" builder_identifier="dietmarw" URL="http://www.trale.de/..." release_cycle="314" creation_year="2006" creation_month="04" ... />
  <image type="rootpartition" fstype="squashfs" readonly="yes" hardware="dreambox" size="..." ...>
    <requirements>
        <requirement>
           <image type="full" builder_identifier="...">
              <required-version least="..."/>
            </image>
        </requirement>
   </requirements>
   <!-- beim Update wird diese Skript runtergeladen und ausgefüht,
          kann z.B. /etc/cramfs.urls in neutrino.conf gegen /etc/update.urls
          ändern -->
   <update-script URL=".../update.sh" download_location="/tmp"/>
   </image>
   <image type="var-partition" fstype="jffs2" URL="...">
</download-images>

zum Bleistift?

Beitrag von **Tommy** » Dienstag 18. April 2006, 13:45

Also von mir aus gern - sieht toll und verdammt nach neuem Standard aus. Warum nicht XML - wo's paßt

vor allem der Part gefällt:

Code: Alles auswählen

<!-- beim Update wird diese Skript runtergeladen und ausgefüht, 
          kann z.B. /etc/cramfs.urls in neutrino.conf gegen /etc/update.urls 
          ändern -->

Beitrag von **dietmarw** » Dienstag 18. April 2006, 14:02

da die von mir erstellten images nicht auf sourceforge usw. liegen,
sondern von mehreren leuten freundlicherweise privat zur verfügung gestellt werden, (thx martin, hardy, homar)
wäre von meiner seite aus eine angabe von mehreren quellen
mit zufälliger auswahl zwecks lastverteilung wünschenswert.

Beitrag von **Tommy** » Dienstag 18. April 2006, 14:14

Mal so als Einwurf - Bit Torrent? ctorrent auf der Box?

*duck und wech*

Beitrag von **Barf** » Dienstag 18. April 2006, 18:47

Ich hat geschrieben:
Tommy hat geschrieben: kann ich "make squashfs.list" einanderes Verzeichnis als $flashprefix vorgeben?
Z.Z. nein; ich bin aber gerne offen Verbesserungen zu diskutieren. Eigentlich bin ich gar nicht mit den *.list-targets (in distribution-lists.mk) zufrieden. Ins besonderes das Operieren auf Files die sich "zufälligerweise" in $(flashprefix) sich befindet ist kein gesundes Maketarget. ( $(shell echo $(flashprefix)/*.squashfs) als prerequisites.) Ich könnte mich vorstellen, falls es ein Skript/Programm z.B. $(customizationdir)/ls-distributionfiles gibt, dass die gewünschte Filenames auf stdout schreibt, dann wird dies benutzt. Ausserdem frage ich mich, falls wirklich alle drei Targets squashfs.list, cramfs.list, img.list notwendig sind. Also, sowas (nicht getestet)
Code: Alles auswählen
$(flashprefix)/update.list: $(shell $(customizationdir)/ls-distributionfiles || echo $(flashprefix)/root-*.*fs $(flashprefix)/*.img*x)
        ....

Ich habe in Wesentlichen diesen Vorschlag implementiert und eingecheckt (in newmake). Neue Target update.list. Dazu wird $(customizationsdir)/ls-distributionfiles mit den zwei Argumente $(flashprefix) und $(buildprefix) ausgeführt, falls es existiert (ausführbar). Es ist kein Zufall, dass der Name nicht *-local.sh ist

Das Skript/Programm soll dann die Files auf stdout listen, ggfl mit volle Pfadnamen. So kann z.B. es aussehen:

Code: Alles auswählen

#!/bin/sh

flashprefix=$1
buildprefix=$2

myfiles="neutrino-jffs2.img1x neutrino-jffs2.img2x neutrino-squashfs.img1x \
neutrino-squashfs.img2x root-neutrino.squashfs var-neutrino.jffs2"

for f in $myfiles ; do
	echo $flashprefix/$f
done

Hat auch die viellecht nicht unerwünschte Nebeneffekt, dass "make update.list" genau die gewünschte Files baut.

Beitrag von **Tommy** » Dienstag 18. April 2006, 21:27

ich habs gefunden

im Menü unter "Expertenfunktionen" gibt es einen Punkt "Konfigfile". Dort stand weis der Geier warum der Eintrag "/etc/squashfs.urls" vermutl. wie Barf oben schon erwähnte vererbt von einer alten neutrino.config die ich per customizing immer ins image reinkopiere um mir die settings zu sparen.

Beitrag von **Tommy** » Dienstag 18. April 2006, 22:33

@Barf: bin gerade beim einbauen Deiner Neuheiten und hab 2 Fragen:

1.
$buildprefix lege ich in configure mit --with-buildprefix=/.... fest? was passiert in buildprefix? Werden dort die image/updatefiles + update.list automatisch abgelegt - kann also schon /www/updates/ sein?

2.
an welcher Stelle führe ich make update.list am besten aus? In meinem allumfassenden skript als letzten Punkt? Sprich nachdem der make flash-neutrino-squashfs-all fertig ist?

Beitrag von **Barf** » Dienstag 18. April 2006, 22:52

Tommy hat geschrieben: 1.
$buildprefix lege ich in configure mit --with-buildprefix=/.... fest? was passiert in buildprefix? Werden dort die image/updatefiles + update.list automatisch abgelegt - kann also schon /www/updates/ sein?

$(buildprefix) war immer die Verzeichnis cvsroot/cdk. Falls du gebaute images rüberschaufeln willst, muss du es in customiztations machen -- mein newmake artiken enthält sowohl begrundung als auch beispiele.

an welcher Stelle führe ich make update.list am besten aus? In meinem allumfassenden skript als letzten Punkt? Sprich nachdem der make flash-neutrino-squashfs-all fertig ist?

Du kannst es wahrscheinlich als einzige (!) Target aufrufen; siehe meine frühere Post. Am mindestens mit einem vernünftigen ls-distributionfiles.

Beitrag von **Tommy** » Dienstag 18. April 2006, 23:42

@Barf:

wg. 1 sorry dumme Frage

wg. 2 funktioniert wunderbar. Ich lasse es in meinem "mainskript" direkt nach make flash-neutrino-squashfs-all ausführen.

nächste frage ist nun - wie kriege ich historische files mit in die list? Gibt es ein clean target was nicht pauschal rm* im cdk-flash macht sondern die durchs customizing umbenannten dateien unangetastet läßt? Ich nehme bis jetzt immer make flash-semiclean und das löscht alles. Oder kann ich mir am Ende das flash-semiclean sparen? Dann werden aber diverse Sachen nicht neu gebaut?!

Beitrag von **Barf** » Dienstag 18. April 2006, 23:56

Tommy hat geschrieben:wie kriege ich historische files mit in die list?

Ich schlage vor:

Tag 0:
Erzeuge images. Kopiere sie (z.B. mit einem cust.-skritp) zu $museum, gerne mit aussagkräftige namen.

Tag n > 0:
Benutze ls-distributionsfiles wie

Code: Alles auswählen

....
for f in $myfiles ; do
   echo $flashprefix/$f
done 
echo $museum/*

$flashprefix ist und bleibt "workspace".