Fatal failed to download "rescue-image-dm920.bin" - dreamboxupdate.com liefert defekte binaries?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Fatal failed to download "rescue-image-dm920.bin" - dreamboxupdate.com liefert defekte binaries?

      N'Abend,

      nachdem der Webserver dreamboxupdate.com wieder erreichbar ist wollte ich den Rescue Loader meiner dm920 via Konsole mit "update-rescue -v" aktualisieren und bekam den folgenden Fehler (s.u.). Wollte dann verstehe was schief läuft und habe die folgenden Dateien (s.u.) geladen mit dem Hintergedanken diese auf Ungereimtheiten zu untersuchen. Dabei ist mir aufgefallen, dass sich die Dateien unterscheiden und so steht der Verdacht dass dreamboxupdate.com korrupte Binaries ausliefert. Insofern wäre das vermutlich arg tödlich für die Box das händisch draufzuspielen. Kann das mal jemand verifizieren?

      Spoiler anzeigen


      Zusatzfrage:
      Ich möchte den Rescue-Loader mit "flash-rescue" manuell schreiben. Wie kann ich denn anhand der sig-datei prüfen, ob das manuell geladene Binary unbeschädigt ist?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Alex2018 ()

    • DP Feed alt -> dreamboxupdate.com/download/re…se/rescue-image-dm920.bin

      DP Feed neu -> dreamboxupdate.com/opendreambo….14-r0-dm920-20200715.bin


      Oder verwechsle ich da gerade etwas?
      Was ist da jetzt eigentlich der Unterschied?
      Das NN2 hat ja auch selber rescue-images auf dem Feed

      Das update-rescue script enthält noch folgendes ...
      Spoiler anzeigen

      #!/bin/sh
      #
      # Copyright (C) 2016 Dream Property GmbH
      #


      source librecovery


      URI="http://dreamboxupdate.com/download/recovery/${MACHINE}/release/rescue-image-${MACHINE}.bin"


      usage()
      {
      echo "Usage: ${0} [-fhqtv] [<URI>]"
      exit "${1}"
      }


      FORCE="false"
      while getopts fhqtv opt; do
      case "${opt}" in
      f)
      FORCE=":"
      ;;
      esac
      std_opt "${opt}"
      done


      shift $((${OPTIND} - 1))
      [ "$#" -le 1 ] || usage 1
      URI="${1:-${URI}}"


      ${FORCE} || ! is_initrd || abort "Do not run this command from rescue mode!"


      create_workspace
      create_keyring_for_uri "${URI}"


      BASE_URI="$(dirname ${URI})"
      FILENAME="$(basename ${URI})"


      fetch_signed "${BASE_URI}" "${FILENAME}"
      info "Writing rescue image to flash"
      xtrap flash-rescue "${FILENAME}"
      info "Done."

      Wo es zwar noch etwas zum downloaden gibt, aber nicht mehr die aktuelle Adresse ist.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Hilfsbereit ()

    • @Alex2018
      Das Problem liegt am automatischen https-Forwarding des neu aufgesetzten dreamboxupdate.com-Servers.

      Da die Files (u.a. auch die Signatur) im update-rescue-Script per curl geladen werden, und dort im Script ein http-Pfad für das rescue-image.bin angegeben ist, schlägt der Download wegen der automatischen Umschaltung auf https dann fehl.
      Vermutlich aktzeptiert curl keine url-Weiterleitung auf https.
      Die url für das Signaturfile wird intern anhand der url vom rescue-image generiert.

      Du kannst mal versuchen, in der Datei update-rescue im Pfad /usr/sbin/ ganz oben in Zeile 8 den Link zum rescue-image-....bin auf https umzustellen. Dann sollte es eigentlich wieder funktionieren.

      so sieht die Zeile 8 zur url in der Datei update-rescue derzeit aus:
      URI="http://dreamboxupdate.com/download/recovery/${MACHINE}/release/rescue-image-${MACHINE}.bin"

      so sollte die Zeile 8 geändert werden (nur aus http ein https machen):
      URI="https://dreamboxupdate.com/download/recovery/${MACHINE}/release/rescue-image-${MACHINE}.bin"
      Gruß Sven (aka Dreamy)

      DM920 mit unstable OE2.5 DP
      One und Two mit OE2.6 DP AIO

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Sven H ()

    • Es gibt noch das andere Problem, dass im OE2.5-Zweig ein Fehler besteht, der dafür sorgt, dass dort die flash-scripts für die One/Two/Seven als Paket auf dem Feed für die OE2.5-Boxen angeboten werden.
      Möglicherweise meinst du das mit der Aussage zu gutemine.

      Aber solange beim update-rescue auf der dm920 kein Fehler wie "Unsupported machine!" kommt, scheinen noch die richtigen Scripte auf der Box zu sein.
      Gruß Sven (aka Dreamy)

      DM920 mit unstable OE2.5 DP
      One und Two mit OE2.6 DP AIO

    • ich glaube auch, dass es am ungültigen ceritficate des webservers liegt
      wenn man das file nur mit wget holt bekommt man einen Zertifikatsfehler

      das rescue image kann man sich ja auch von opendreambox.com vom image feed im Browser holen - oder mit wget mit der Option "--no-check-certificate", sofern man der Webseite vertraut - und dann mit flash-rescue manuell installieren, wie im OE2.2 als es noch kein update-rescue gab

      die lettzten rescue-loader bin files liegen meist auf dem unstable image feeds der jeweiligen Box, aber das sieht man auch am release Datum der rescue bin files am unstable und stabel image feed.

      z.B. dm920, das letzte rescue bin file einfach in /data mit wget downloaden und dann manuell mit flash-rescue installieren/updaten

      cd /data
      wget --no-check-certificate https://dreamboxupdate.com/opendreambox/2.5/unstable/images/dm920/zImage-rescue-3.14-r0-dm920-20201201.bin
      flash-rescue zImage-rescue-3.14-r0-dm920-20201201.bin


      Der download des loaders und des sig files erfolgt in der /usr/sbin/librecovery mit curl, wenn man das update-rescue ausführt. Wenn jedoch das Zertifkat abgelaufen ist, schlägt aber auch der download mit curl fehl - auch wenn die URI in /usr/sbin/update-rescue angepasst wurde.

      Alternativ müsste man auch noch die /usr/sbin/librecovery anpassen, damit der loader und das sig file mit update-rescue (ohne Zertifikatsfehler) heruntergeladen werden können

      das müsste man in der librecovery an 2 Stellen ändern auf

      curl --insecure
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Bei mir kommt damit auf der 920 kein Fehler:

      curl -q "https://dreamboxupdate.com/download/recovery/dm920/release/rescue-image-dm920.bin.sig" -o "rescue-image-dm920.bin.sig"
      curl -q "https://dreamboxupdate.com/download/recovery/dm920/release/rescue-image-dm920.bin" -o "rescue-image-dm920.bin"

      Beide Files werden so ohne Probleme geladen.
      Und genau diese Zeilen verwendet auch das Script (nur eben noch mit http, weshalb es mit curl nicht geht).
      Bei curl gäbe es noch den Parameter -L, wo das redirect von http auf https zugelassen wird, aber das müsste man dann in der librecovery ergänzen.
      Gruß Sven (aka Dreamy)

      DM920 mit unstable OE2.5 DP
      One und Two mit OE2.6 DP AIO

    • hm, bei mir hat das auf der dm7080 nicht geklappt - zumindest nach Änderung von http auf https im update-rescue script und Ausführen von update-rescue -v
      das script holt ich auch noch die files mit wget, wenn hash curl fehlschlägt
      wenn man in der librecovery 'curl' nicht auf 'curl --insecure' ändert, schlägt der download auch fehl


      Ich habe das mal auf der dm7080 getestet. Mit diesen 3 Terminal commands kann man das update-rescue wieder "reparieren"

      Dafür müssen die flash-scripts /usr/sbin/librecovery und /usr/sbin/update-rescue editiert werden. Wenn das jemand testen will, sicherheitshalber die beiden original Dateien sichern! Der workaround sollte mit allen OE2.5 (u. OE2.6) Boxen funkionieren.

      Aber ACHTUNG im OE2.6!!
      Mit diesem patch kann man sich den letzten offiziellen rescue-loader #104 auf die Box holen.
      Wenn jemand bereits den inoffiziellen rescueloader #106 oder höher von @gutemine installiert hat macht damit ein downgrade. Wenn man die one oder two bereits auf GPT umgestellt hat, ist das KEINE gute Idee! Dann muss man sich das rescue-image von den gutemine feeds ziehen und manuell installieren! Ein update-rescue -v ist aktuell auch dann nicht zu empfehlen, auch wenn DP die Zertifikate erneuern und die flash-scripte anpassen sollte, wenn man einen inoffiziellen rescue-loader #106 oder höher installiert UND auf GPT umgestellt hat.






      Zuerst die scripte sichern:

      cp -a /usr/sbin/update-rescue /data/.recovery/
      cp -a /usr/sbin/librecovery /data/.recovery/


      Scripte anpassen

      im update-rescue script 'http' auf 'https' ändern
      sed -i 's/http/https/g' /usr/sbin/update-rescue

      im Funktions script librecovery 'wget' auf 'wget --no-check-certificate' ändern
      sed -i 's/wget/wget --no-check-certificate/g' /usr/sbin/librecovery


      und 'curl' auf 'curl --insecure' ändern
      sed -i 's/curl/curl --insecure/g' /usr/sbin/librecovery



      sieht dann etwa so aus

      repair update-rescue -v

      Quellcode

      1. root@dm7080:~# update-rescue -v
      2. [*] Downloading 'https://dreamboxupdate.com/download/recovery/dm7080/release/rescue-image-dm7080.bin.sig'
      3. % Total % Received % Xferd Average Speed Time Time Time Current
      4. Dload Upload Total Spent Left Speed
      5. 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
      6. curl: (60) SSL certificate problem: unable to get local issuer certificate
      7. More details here: https://curl.haxx.se/docs/sslcerts.html
      9. curl performs SSL certificate verification by default, using a "bundle"
      10. of Certificate Authority (CA) public keys (CA certs). If the default
      11. bundle file isn't adequate, you can specify an alternate file
      12. using the --cacert option.
      13. If this HTTPS server uses a certificate signed by a CA represented in
      14. the bundle, the certificate verification probably failed due to a
      15. problem with the certificate (it might be expired, or the name might
      16. not match the domain name in the URL).
      17. If you'd like to turn off curl's verification of the certificate, use
      18. the -k (or --insecure) option.
      19. Fatal: Failed to obtain signature 'rescue-image-dm7080.bin.sig'
      20. root@dm7080:~# cp -a /usr/sbin/update-rescue /data/.recovery/
      21. root@dm7080:~# cp -a /usr/sbin/librecovery /data/.recovery/
      22. root@dm7080:~# sed -i 's/http/https/g' /usr/sbin/update-rescue
      23. root@dm7080:~# sed -i 's/wget/wget --no-check-certificate/g' /usr/sbin/librecovery
      24. root@dm7080:~# sed -i 's/curl/curl --insecure/g' /usr/sbin/librecovery
      25. root@dm7080:~# update-rescue -v
      26. [*] Downloading 'https://dreamboxupdate.com/download/recovery/dm7080/release/rescue-image-dm7080.bin.sig'
      27. [*] Downloading 'https://dreamboxupdate.com/download/recovery/dm7080/release/rescue-image-dm7080.bin'
      28. [*] Verifying signature of 'rescue-image-dm7080.bin'
      29. gpgv: Signature made Mo 02 Dez 2019 22:49:47 CET using RSA key ID D6CF56E7
      30. gpgv: Good signature from "Dreambox DM7080 Recovery <recovery@dm7080.com>"
      31. [*] Writing rescue image to flash
      32. Manufacturer ID: c2
      33. Memory type : 20
      34. Memory density : 18
      35. read id ok
      36. comparing 2745 sectors...
      37. nothing to do
      38. [*] Done.
      39. root@dm7080:~#
      Alles anzeigen


      Alles wieder rückgängig machen

      cp -a /data/.recovery/update-rescue /usr/sbin/
      cp -a /data/.recovery/librecovery /usr/sbin/
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$

      Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Sven H schrieb:

      @Alex2018
      Das Problem liegt am automatischen https-Forwarding des neu aufgesetzten dreamboxupdate.com-Servers.

      Da die Files (u.a. auch die Signatur) im update-rescue-Script per curl geladen werden, und dort im Script ein http-Pfad für das rescue-image.bin angegeben ist, schlägt der Download wegen der automatischen Umschaltung auf https dann fehl.
      Vermutlich aktzeptiert curl keine url-Weiterleitung auf https.
      Die url für das Signaturfile wird intern anhand der url vom rescue-image generiert.

      Du kannst mal versuchen, in der Datei update-rescue im Pfad /usr/sbin/ ganz oben in Zeile 8 den Link zum rescue-image-....bin auf https umzustellen. Dann sollte es eigentlich wieder funktionieren.

      so sieht die Zeile 8 zur url in der Datei update-rescue derzeit aus:
      URI="http://dreamboxupdate.com/download/recovery/${MACHINE}/release/rescue-image-${MACHINE}.bin"

      so sollte die Zeile 8 geändert werden (nur aus http ein https machen):
      URI="https://dreamboxupdate.com/download/recovery/${MACHINE}/release/rescue-image-${MACHINE}.bin"
      Moin
      auf der 920 klappt es so bei mir auch.
      Gruß
      Rum

    • Fred Bogus Trumper schrieb:

      ich glaube auch, dass es am ungültigen ceritficate des webservers liegt
      wenn man das file nur mit wget holt bekommt man einen Zertifikatsfehler...
      welches ca-certificates-Paket hast du auf der 7080?

      Auf meiner Two: 20211017
      Auf meiner dm920: 20230408

      Vielleicht sind deine lokalen Zertifikate zu alt ??
      Da gab es irgendwann mal ein Problem damit.
      Würde aber meinen, dass es damals ein Update über den DP-Feed gab.
      Und neuere kommen glaub ich vom MP-Feed.
      Gruß Sven (aka Dreamy)

      DM920 mit unstable OE2.5 DP
      One und Two mit OE2.6 DP AIO

    • gut, daran könnte es liegen - daran hatte ich gestern nicht mehr gedacht - war schon spät

      Das Image auf der dm7080hd hängt an einem "frozen" local snapshot feed (Enigma2) Stand 2019.05.30, also outdated

      Quellcode

      1. root@dm7080:~# dpkg -l|grep ca-certificate
      2. ii ca-certificates 20160104-r0.1 all Common CA certificates
      3. root@dm7080:~#
      aber die ca-certificates kann man sich ja vom aktuellen feed nachziehen



      zumindest wissen wir jetzt schon die Lösung für derartige zukünfige Probleme wenn es kein updates mehr gibt :D
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Fred Bogus Trumper ()

    • Fred Bogus Trumper schrieb:

      Das Image auf der dm7080hd hängt an einem "frozen" local snapshot feed (Enigma2) Stand 2019.05.30, also outdated
      N'Abend,
      und ich dachte schon, ich bin ich verrückt mit einem lokalen Mirror zu fahren. Same here ... :D

      Zurück zum Topic:
      Die Vermutung das die von dreamboxupdate gelieferten Binaries defekt weil unterschiedlich sind, wurden in der Fehlersuche bisher nicht berücksichtigt. Wenn ich beide sig-Dateien runterlade ist eine kompletter Müll, während die zweite sich sauber mit einem Texteditor öffnen lässt und eine PGP Signatur beinhaltet. Das ist doch irgendwie komisch (screenshot unten)? Daher meine Frage, wie kann ich denn das Binary mit der sig-Datei auf Validität prüfen? Ich möchte mir ungern mein Gerät schrotten nur weil ich auf gut Glück eine defektes Image in den Flash schreibe.

      Die zweite Baustelle, dass rein theoretisch die Rescue Binaries auch hier auf dem Feed (s.u) liegen, hab ich dabei außen vor gelassen.
      feed.newnigma2.to/daily/rescue/

      Spoiler anzeigen