Pinned OE2.5: Rückmeldungen zum weekly Image für DM920UHD

ja, das ist strange - in /boot hat der Kernel nach dem Flashen den korrekten Namen 'zImage-3.14-1.17-dm920'
am Ende habe ich mich in 496 "verlesen", am 14" Notebook sah es nach einem kleinen "i" im Archiv aus



nach dem manuellen Flashen des kernels ist die Box auch normal gestartet


Jetzt haben wir zwar einen Workaround - aber warum die Fehlermeldung beim Flashen kommt ist noch nicht klar

so, jetzt habe ich den Fehler gefunden

@Newnigma2 devs

seht euch mal bitte das Paket 'flash-scripts' im OE2.5 an. Wie es aussieht, ist euch das Paket flash-scripts aus dem OE2.6/AiO ins OE2.5 gerutscht.


In den Scripten /usr/sbin/librecovery und /usr/sbin/flash-kernel etc. sind nur die One, Two und Seven im Script enthalten - alle OE2.5 Boxen (dm9x0, dm820, dm7080, dm5x0) jedoch nicht! Daher die Fehlermeldung "unsupported Maschine" beim Flashen. Am Dreambox OE2.5 unstable feed sind die OE2.5 Boxen in den scripten vorhanden.


Wie es aussieht, wird beim Flashen das korrupte script /usr/sbin/flash-kernel aus dem Image und nicht aus dem rescue-loader gestartet - was zum Fehler führt.



Führt man flash-kernel /tmp/flash/boot/zImage-3.14-1.17-dm920 im rescue-loader aus, wird das korrekte flash-kernel script im rescue-loader gestartet was zum erfolgreichen Flashen des Kernels führt. Will man im gebooteten Image den Kernel flashen, erhält man den selben Fehler wie beim Flashen übers Webinterface.


Aufgefallen ist mir das nur, weil ich den Fehler im rescue-loader vermutete und versucht habe den loader "downzugraden"
Am weekly OE2.5 feed liegt übrigens auch das korrupte flash-script Paket ohne support für OE2.5 Boxen

komisch nur, das an den feeds überhaupt gar nichts geändert wurde in den letzten Wochen, wodruch dieser Fehler entstanden sein hätte können...

es wird sich drum gekümmert wenn der Chef Zeit dafür hat und der BVB nicht Meister wird, ansonsten dauert es noch was länger... (ALK usw )

ich glaube, dass das falsche Paket schon länger im Image inkludiert ist - also schon vor dem 9.5.

erklärt auch die Fehlermeldung beim Flashen älterer Backups

Nachfrage eines Nicht-Wissenden:
Liesse sich die Korrektur auch "von Hand" eingeben, so dass ein neu erstelltes Backup gleich passt?
Bin halt einfach seit meinen vielen Frust-Versuchen vorgestern Nacht ein Schisser geworden....

du könnstet im image die flash scripte tauschen - entweder aus einem noch älternen Backup oder vom dmm unstable feed klauen. Aber nicht das .deb installieren, sondern manuell auf der Box entpacken und in die entsprechenden Ordner schieben.

Ich könnte am Abend nochmal nachsehen welche Dateien betroffen sind. Auf jeden Fall /usr/sbin/librecovery und /usr/sbin/flash-rescue.
/usr/sbin/flash-kernel vermutlich nicht - das ruft /usr/sbin/librecovery auf - die Fehlermeldung kommt aus dem script.

oder du holst die scripte aus dem rescue loader

Aber warte mal ab bis das gefixt ist. Dann einfach updaten dann sollten auch wieder die korrekten Scripte installiert werden.
Falls man bis dahin wieder ein Backup flashen muss, dass die falschen scripte includiert hat, kann am immer noch den workaroud nutzen und im rescue-loader im Terminal den kernel flashen. dauert 1 Sekunde


Mit dpkg -L flash-scripts kann man sich ansehen, welche Dateiein im (korrupten) Paket enthalten sind

ok, und wieder danke. Dann befolge ich mal lieber deinen Rat und warte, bis es gefixt ist.
Zusatzinfo an die devs:
Auch bei update-rescue -v kommt die Meldung "Fatal: Unsupported machine!". Keine Ahnung, ob das dieselbe Ursache ist. Im Script update-rescue finde ich weder die Abfrage noch die Fehlermeldung.

ja, das ist die selbe Ursache.

Ich weiss nicht, wie lange es dauert bis das gefixt ist - scheint ja "Fussballergebnisorientiert" zu sein

Zur Not könnte man einen tarball bereitstellen, mit dem man die files im flash mit den korrekten scripten überschreibt ohne die die Paketversion des debian Paketes zu ändern. Beim nächsten Update wird dann wieder alles überschrieben und es ist wieder alles beim alten.

Der tarball wäre in wenigen Minuten erstellt bzw. auf der Box entpackt. Es gibt zwar ein armhf und mipsel deb am feed, aber nachdem das eigentlich nur shell scripte sind, müsste ein tarball für alle OE2.5 Boxen reichen.
Aber auch das kann man überprüfen um sicher zu gehen.

Allerdings hätte ich frühestens am späteren Abend dafür Zeit


\\Edit:

Aber viel Sinn hätte das nicht. Im Image am feed ist der Fehler bereits enthalten. D.h. entweder ein älteres Image ohne diesen Fehler flashen oder nach dem flashen den kernel im rescue loader im terminal als workaround "nachflashen"
Wenn man ein Backup flasht, dass auch diesen Fehler enthält gilt der selbe workaround.

Worst case wäre nur, wenn man gar nicht mehr in den rescue-loader kommt und den loader updaten oder reinstallieren müsste. Dann kann man sich die korrekten scripte noch immer einbauhen oder das rescue-loader bin von USB starten und dann flashen.

ok, halbwegs verstanden...
nur wegen mir und meiner Fragerei musst du dir die Arbeit sicher nicht machen, wie gesagt, im Moment alles ok. Der Autor eines anderen Plugins hat mich nur gebeten, ein paar Tests zu machen, und das werd ich dann halt verschieben, bis ich einigermassen sicher bin, dass mir der Schreck von Samstag Nacht (Box tot ? ) erspart bleibt, wenn ich wieder versuche, ein Backup zu flashen
Danke trotzdem fürs Angebot, deine Suche und deine Geduld.

Das liegt wohl daran, dass DP die alten Box aus dem aktuellen recovery.git seit 21.04.2023 rausgeschmissen hat.
Wenn man nun damit ein Image für die alten Boxen baut, ist das wohl ungünstig.

git.opendreambox.org/?p=recove…ec2762bf5f8921296;hb=HEAD

Keine Ahnung, ob man da zum Imagebauen auch einen älteren Stand des gits (vor dem 21.04.2023) verwenden kann.

Hier mal das Diff vom 21.04., wo die alten Boxen rausgeflogen sind (hauptsächlich in der librecovery):
git.opendreambox.org/?p=recove…51fa59a7e15a542d5ab0278ac

na, da will DP wohl seine Kunden (und damit sein Geschäft) endgültig loswerden, wenn jetzt schon die 9xx-Boxen als alt und nicht mehr unterstützungswürdig angesehen werden
schlimm genug, dass DP es nicht schafft, SSL auf die OE2.0-Boxen zu bringen, was andere wirklich alte Boxen/Images problemlos schaffen; wenn das mit OE2.5 nun aber auch schon losgeht, Gute Nacht Dreambox.

d.h. aber auch, dass seit 21.4.23 kein neues flash-script Paket am DP feed gebaut wurde. In den flash-scripts auf dem DP OE2.5 feed noch die alten scripte mit OE2.5 support zu finden (Stand 01.12.2020)

Dann dürfte das Paket beim Imagebauen nicht neu erstellt, sondern vielleicht direkt von DP eingebunden werden.
Aber davon habe ich keine Ahnung

wie geschrieben: nachträglich die richtigen scripte einzubauen ist nicht das Problem - aber sie sollten auch im (jungfräulichen) Image enthalten sein, dass man flasht

die letzten OE2,5 flash-scripts Pakete vom DP feed liegen jedenfalls schon auf meinem "home mirrow server"

das aktuelle Paket vom NN2-Feed für die 920 lautet so:
flash-scripts_1.1+git1+530b1eb807-r0.0_armhf.deb
und entspricht somit wohl dem letzten commit 530b1eb8075d0fa66f1d20288fac9a5eb81f6c62 vom 21.04.2023

das letzte Paket vom DP-Feed für die 920 lautet so:
flash-scripts_1.1+git8+81ff8d40bb-r0.0_armhf.deb
und entspricht somit dem commit 81ff8d40bbe21ec4bff1e397e4afdd2f1f3337e3 vom 24.07.2020

Vielleicht lässt sich da ja was über die commit-number machen ???

die beiden Newnigma2 Pakete nach dem alten git commit Stand hätte ich sogar hier rumliegen, Stand 2021-05-30

flash-scripts_1.1+git10+81ff8d40bb-r0.0_armhf.deb
flash-scripts_1.1+git10+81ff8d40bb-r0.0_mipsel.deb


d.h. die könnte man am feed tauschen oder einfach manuell nach dem flashen nach /tmp schieben und in der konsole drüberbüglen
Zur Not könnte ich auch ein flash-scripts_1.1+git10+81ff8d40bb-r0.1_*.deb packen damit es ein Verions upgrade gibt, falls sich die -r0.0 nicht drüberbüglen lässt

Da sollte besser automatisch beim Imagebauen passieren.
Ich glaube nicht, dass sie bei jeden Image-/Feed-Update die Files/Pakete jedes Mal händisch tauschen

Mit dem Paket kann man es ja auch nur nachträglich nach dem Flashen korrigieren.
Im Image selbst müssten ja vermutlich auch die alten flash-Scripte in /usr/sbin enthalten sein.

ja, ich meinte als workaround bis der feed aktualisiert wurde

oder alternativ das .deb entpacken und als flash-scripts_mipsesl/armhf.tar.gz zur Verfügungung stellen

dann brauchts nur einen tar Befehl zum Überschreiben der scripte ohne die Paket Versionsnummer zu ändern

die Installation des Paketes flash-scripts_1.1+git10+81ff8d40bb-r0.0_*.deb wurde nur funktionieren wenn man zuvor das alte Paket deinstalliert, weil ein downgrade nicht druchlaufen würde
allerdings würde der paketmanager dann sofort ein update nach dem check anzeigen und wieder die korrupte neuere Version drüberbügleln.

Wie das am feed bzw. im image aussieht müssen sich die nn2 devs ansehen - aber sie werden sicher eine Lösung finden. So tragisch finde ich das jetzt auch wieder nicht - aber ich bin nicht der Maßstab ...

Ja, man kann nur froh sein, dass nichts Schlimmeres passiert ist.
Man hätte sich dabei ja auch die Box in einen Zustand versetzen können, mit dem die meisten User gnadenlos überfordert sind.
Aber zum Glück startet die Box ja nach dem Flashen wenigstens.

Wobei ich nicht gedacht hätte, dass beim Flashen über den RescueLoader die Scripte aus dem Image bzw. aus dem Flash verwendet werden.
Die sollten doch eigentlich nur in der Recovery-Partition liegen, die beim Flashen doch nicht verändert wird, oder ?
Oder zieht man die aktuellen Flash-Files mit einem rescue-Update per Telnet auf die Box ??
Das habe ich lieber noch nicht probiert.

die Box startet zwar und funktioniert solange der gleiche kernel erneut geflasht werden soll - z.b ein backup flashen. Dann ist es eigentlich egal, weil der kernel im image bereits im Flash installiert ist. Die Fehlermeldung beim flashen irritiert zwar, kann aber vermutlich ignoriert werden.

Wenn man von einem Open* Image zu Newnigma2 wechselt sieht die Sache schon anders aus. Danach wird die Box nicht sauber laufen, wenn man den kernel nicht manuel im loader nachinstalliert.

Beim update-rescue wird nur der rescue loader aktualisiert, aber nicht das Image bzw. die scripte darin.

Das beim Flashen die flash-scripts aus dem Image genommen werden, macht bei näherer Betrachtung auch Sinn. Wenn jemand den laoder nie aktuallisiert hat, passt womöglich das flash-script im loader nicht mehr zum kernel im image, weil DP etwas geändert hat. Dann lieber das flash-script aus dem Image nehmen - das passt dann auch zum Image das geflasht werden soll.