Spark Onlineupdate

[dietmarw]

eine planung für ein "nicht opkg" basierendes onlineupdate gibt es bisher nicht?

ich würde mir das so wünschen:
- man definiert einen speicherort für die zu sichernden daten (stick, (s)ftp, share, ...)
- backup var
- download, flash, restore der sicherung
- reboot

über symlinks in /boot könnten die *.elf dateien im var liegen.
legt man das im inet ab, könnte man einen tarball mit einer hardware-id verschlüsseln.


die einzigen probleme wären:
- kann man direkt nach dem flashen in die jffs2 partition schreiben?
- wer würde das implementieren?

[schufti]

wenn man gleich gar keine Dateien ins update packt, die stören könnten, ist's noch viel einfacher....

und ein ganzes jffs2 Image solltest (kannst ???) du auf dem Weg sowieso nicht flashen solange das root-fs r/w gemounted ist.

pinkys Methode war da gar nicht soooo übel.

[graugans]

Ich verstehe zwar nicht was an opkg auszusetzen ist. Funktioniert hier super.
Aber hier ein paar Ideen.

Fritzbox style
Hier wird das image beim shutdown geflasht, quasi als letzte Aktion. Nachdem das fs readonly gemountet wurde. Die verwenden allerdings auch eine RAMdisk.

Spark style / Pinky
Alles per tar erledigen. Ist etwas schiefgelaufen gibt es ein rescue system. Wie das rescue system aufgebaut ist findest Du hier:
https://github.com/project-magpie/meta- ... dia-990-CR

Falls das mit opkg doch noch in Frage kommen würde ich bastel da gerade an einer Lösung

[martii]

Ein Live-Update mit Überschreiben von Kernel- und Root-Image ginge mit gewisser Wahrscheinlichkeit schon. Ich habe das quick-and-dirty eben mal probiert; zwar mit YAFFS2 (und ohne Konfig-Daten zu sichern und wieder einzuspielen), aber mit JFFS2 sollte das genauso oder besser tun: Zumindest bei YAFFS2 ist (weshalb auch immer) das nandwrite-Binary erforderlich, das bei Spark dabei ist. Das Spark-nandwrite hatte ich mir unter /media/sda1/nandwrite abgelegt.

Code: Alles auswählen

mount -o remount,ro /
mkdir /tmp/root
cd /tmp/root
mkdir dev sys proc tmp media bin sbin lib media/sda1 sys
tar -C /dev -cf - . | tar -C dev -xf -
cp -p /bin/spark_fp /bin/busybox bin/
cp -p /sbin/nandwrite sbin/
cp -p /lib/libc.so.6 /lib/ld-linux.so.2 lib/
A=`ps ax | egrep -v "\[|inetd|dropbear|getty|init|-sh|ps ax|PID|egrep|cut" | cut -c -5`
kill -9 $A
mount -o move /tmp/media/sda1 /tmp/root/media/sda1
mount -o move /sys /tmp/root/sys
chroot . /bin/busybox sh
cd /media/sda1/enigma2
busybox flash_eraseall /dev/mtd5
/media/sda1/nandwrite -a -p -m /dev/mtd5 uImage
busybox flash_eraseall /dev/mtd6
/media/sda1/nandwrite -a -o /dev/mtd6 e2yaffs2.img
cd /
busybox umount /media/sda1
spark_fp -L 0 -L 1 -w 1

Ich weiss nicht, ob das jetzt wirklich keine Seiteneffekte mit sich bringt oder ob's unter irgendwelchen Rahmenbedingungen doch nicht geht. Jedenfalls bootet's und läuft.

Wer's ausprobiert, sollte sich darüber im Klaren sein, dass auch was schiefgehen kann und bekommt von mir kein Mitleid.

(Edit: nandwrite aus mtd-utils 1.3.1 tut für yaffs2, downgrade in meinem GIT ist erfolgt)

[dietmarw]

erstmal vielen dank dafür schon mal..

es wäre echt genial wenn das einer zur "marktreife" weiterentwickeln würde,
ich verstehe da leider zu wenig von..

[dietmarw]

ist schon schade, das online-updates die auf der db2 zehn jahre lang gut funktioniert haben
auf der spark scheinbar nicht mehr nützlich sind..

so kann man "otto-normal-verbraucher" auch zu "anderen" distributionen treiben.

[martii]

ist schon schade, das online-updates die auf der db2 zehn jahre lang gut funktioniert haben
auf der spark scheinbar nicht mehr nützlich sind..

So schlimm ist's nun doch nicht. Es muss nur jemand tun. In meine(n) Clone(s) habe ich den OPKG-Manager von dbt drin, der (nach einer kleinen Änderung der "opkg-cl"-Argumente) auch funktioniert. Sprich, ich habe da jetzt einfach mal testweise bei mir im LAN das pkgs/opkg per Web zugänglich gemacht, die pkgs/opkg/Packages[.gz] erzeugt, die /etc/opkg/opkg.conf auf dem Receiver angelegt und das tat dann hinreichend, um über die GUI tcpdump installieren zu können (und mehr hab ich nicht überprüft).

Aber selbstverständlich bringt das alles nur was, wenn sich tatsächlich jemand die Arbeit macht, die Pakete irgendwo konsistent zur Verfügung zu stellen.

Ciao,

martii

[dbt]

In meine(n) Clone(s) habe ich den OPKG-Manager von dbt drin, der (nach einer kleinen Änderung der "opkg-cl"-Argumente) auch funktioniert. Sprich, ich habe da jetzt einfach mal testweise bei mir im LAN das pkgs/opkg per Web zugänglich gemacht, die pkgs/opkg/Packages[.gz] erzeugt, die /etc/opkg/opkg.conf auf dem Receiver angelegt und das tat dann hinreichend, um über die GUI tcpdump installieren zu können (und mehr hab ich nicht überprüft).

Also prinzipiell geht das auch, zumal ich das nur für meine Zwecke mal schnell hingebaut hatte, nur hatte ich ja schon mal erwähnt, dass man den Manager für den "echten" Gebrauch, also für den Otto Normalverbraucher, noch erweitern müsste. zB. Müsste man überwachen, ob das mit dem Speicherplatz hinhaut, oder nur solche Sachen zur Auswahl angezeigt werden, die auch "gefahrlos" installiert werden können. Also etwas flexibler müsste das dann halt schon noch werden. Prinzipiell sollte das schon zu machen sein.

[martii]

In meinem -MP-Clone habe ich den OPKG-Manager überarbeitet, so dass eine Massentauglichkeit m.E. schon eher gegeben wäre: Es gibt einen Upgrade-Menüpunkt, das Menü wird abhängig vom Paketstatus angepasst, die opkg-cl-Ausgaben werden angezeigt. Checks, z.B. auf Speicherplatz, sind bewusst keine drin. Das wäre IMHO eher Aufgabe von opkg-cl, da aufzupassen.

Ciao,

martii

[dbt]

...Checks, z.B. auf Speicherplatz, sind bewusst keine drin. Das wäre IMHO eher Aufgabe von opkg-cl, da aufzupassen.

Ja Sicher, diesbezüglich meinte ich ja genau die Interaktionen mit opkg-cl, um diese auf die Benutzerführung umzulegen. Nochmal das Rad neu zu erfinden, wäre ja nicht so toll.

[doc]

opkg-cl ist das reine Tool für die CommandLine, da kann man die Infos auch alle $irgendwie abgreifen aber das kann nicht Sinn der Übung sein. Als API gibt es die libopkg welche jedoch auch noch sehr rudimentär ist. Um überhaupt dies mal durchforsten zu können hatte ich mir da mal doxygen [1] reingefummelt. Die Patches [2] sind upstream jedoch nie applied worden. Naja, die Kommunikation ist etwas "zäh". Da ich bisher keine Intention hatte da weiter rum zu basteln habe ich es nicht weiter verfolgt. So machte das keinen Spaß.

Das opkg-cl ist meines Wissens bisher statisch gelinkt, also wird opkg ohne die libopkg paketiert. Ich hatte das mal umgebaut, aber wo das jetzt rumliegt ... ist aber ja kein Hexenwerk das umzustellen, wobei, da gab es noch mehr Probs wie die klassische Datei config.h die installiert wird. Auch das hatte ich angepasst, aber auch hier sieht man das Upstream anders. Ohne Aussicht auf eine erfolgreiche Zusammenarbeit hatte ich mich anderen Dingen gewidmet. Kann den Kram mal zusammen suchen und auf Github/Gitourious pushen.

Keine Frage die libopkg ist bis jetzt nur auf Grundfunktionen benutzbar und müsste umgebaut werden, scheinbar hat außer uns keiner diese Probleme. In der libopkg gibt es z.B. alle Funktionen die die Daten entsprechen sammeln, wie die Größe des installierten Paketes [3] als auch Datum, Maintainer, md5, Plattform etc.
Ich will sagen, statt den Output von opkg-cl zu parsen sollte man die libopkg nutzen da dort schon alles drin ist, und wenn etwas fehlt oder verändert werden muss dann entsprechend anpassen.

[1] http://openmct.org/misc/libopkg/
[2] https://groups.google.com/forum/?fromgr ... up2zkVGBVA möglich das das nur für Google Mitglieder sichtbar ist
[3] http://openmct.org/misc/libopkg/structp ... fb63c624de

[graugans]

Hi,

opkg-cl ist das reine Tool für die CommandLine, da kann man die Infos auch alle $irgendwie abgreifen aber das kann nicht Sinn der Übung sein. Als API gibt es die libopkg welche jedoch auch noch sehr rudimentär ist. Um überhaupt dies mal durchforsten zu können hatte ich mir da mal doxygen [1] reingefummelt. Die Patches [2] sind upstream jedoch nie applied worden. Naja, die Kommunikation ist etwas "zäh". Da ich bisher keine Intention hatte da weiter rum zu basteln habe ich es nicht weiter verfolgt. So machte das keinen Spaß.

Ich bin ganz Deiner Meinung. Ich habe die libopkg in Neutrino eingebunden. Dies ist mir allerdings erst nach dem Patchen selbiger gelungen:
Bug-Eintrag beim opkg Projekt

Da die lib ein globales Symbol conf exportiert welches mit Neutrino kollidiert. Das habe ich in opkg_conf_ umbenannt.

Danach funktioniert die lib auch nicht out of the box man muss jedesmal die globale config sichern und wiederherstellen sonst crash die lib. Da gibt es einen Bug in der Initialisierung. Den wollte ich aber erst reporten sobald irgendeine Reaktion auf meinen ersten Bug stattgefunden hat ;-)

Theoretisch könnte man die Symbole auch beim Linken "verstecken" wie es im Makefile.am auch vorgesehen ist:

Code: Alles auswählen

# make sure we only export symbols that are for public use
#libopkg_la_LDFLAGS = -export-symbols-regex "^opkg_.*"

Dann müsste nur noch das Initialisieren gefixt werden...

Das opkg-cl ist meines Wissens bisher statisch gelinkt, also wird opkg ohne die libopkg paketiert. Ich hatte das mal umgebaut, aber wo das jetzt rumliegt ... ist aber ja kein Hexenwerk das umzustellen, wobei, da gab es noch mehr Probs wie die klassische Datei config.h die installiert wird. Auch das hatte ich angepasst, aber auch hier sieht man das Upstream anders. Ohne Aussicht auf eine erfolgreiche Zusammenarbeit hatte ich mich anderen Dingen gewidmet. Kann den Kram mal zusammen suchen und auf Github/Gitourious pushen.

Keine Frage die libopkg ist bis jetzt nur auf Grundfunktionen benutzbar und müsste umgebaut werden, scheinbar hat außer uns keiner diese Probleme. In der libopkg gibt es z.B. alle Funktionen die die Daten entsprechen sammeln, wie die Größe des installierten Paketes [3] als auch Datum, Maintainer, md5, Plattform etc.
Ich will sagen, statt den Output von opkg-cl zu parsen sollte man die libopkg nutzen da dort schon alles drin ist, und wenn etwas fehlt oder verändert werden muss dann entsprechend anpassen.

Ich habe einen Entwurf eine Klasse erstellt welche die libopkg wrappt und Handler für eine Fortschrittsanzeige bereitstellt:
opkg_manager.h
opkg_manager.cpp

Mir ist leider ein komplettes Buildsystem dazwischen gekommen ansonsten hätte ich an dem Thema weitergearbeitet.

Also wir können das Thema gerne weiter bearbeiten.

Das OpenWrt Projekt (luci)verfolgt übrigens ebenfalls den Ansatz den Output zu parsen. Was angesichts des aktuellen Zustands der Lib vermutlich auch der praktikabelste ist.

[flk]

Mir persönlich reicht opkg-cl aus, trotzdem finde ich, dass das eine wichtige Erweiterung für Neutrino-MP wäre. Wenn ihr da was auf die Beine stellen könnt, wäre das