Thanks Thanks:  0
Seite 4 von 4 ErsteErste ... 234
Ergebnis 31 bis 37 von 37
  1. #31
    Avatar von arn354
    Registriert seit
    06.04.2013
    Beiträge
    2.655
    Total Downloaded
    147,3 KB
    Total Downloaded
    147,3 KB
    ReceiverDankeAktivitäten
    Zitat Zitat von HD8000S Beitrag anzeigen
    Auch wenn ich inhaltlich nicht immer folgen konnte: Heute morgen wollte ich "mal eben" das openATV-eigene Fullbackup
    anwerfen, damit ich nicht bei jedem Problem mit nachfolgendem Neu-Flashen wieder von vorne anfangen muß.

    Das Ergebnis: Greenscreen und Reboot. Das Image ist vom 20.01.2014.
    GS ist seit 3 tagen gefixed - https://github.com/openatv/enigma2/c...551d6b60faacd8
    Grüßle


    •   Alt Advertising

       

  2. #32
    Mitglied
    Registriert seit
    18.10.2013
    Ort
    Niederbayern
    Beiträge
    36
    Total Downloaded
    35,99 MB
    Total Downloaded
    35,99 MB
    ReceiverDankeAktivitäten
    Box 1:
    GI Xpeed LX2
     
     
    Box 2:
    GM990 Spark Reloaded
     
     
    Update gemacht? Mit aktuellem Image dürfte kein GS mehr auftauchen.

    Gesendet von meinem XT890

  3. #33
    Mitglied
    Registriert seit
    18.01.2014
    Beiträge
    51
    Total Downloaded
    0
    Total Downloaded
    0
    ReceiverDankeAktivitäten
    Box 1:
    Gigablue HD Quad
     
     
    Box 2:
    Edision Optimuss OS1
     
     
    Danke für Info!

    Bleibt nur die Frage, ob das Flashen des Images an sich jetzt risikolos vonstatten geht.
    Das lief die letzten Tage wohl auch einiges nicht wirklich rund. Aber das ist ein anderes Thema....

  4. #34
    Senior Mitglied
    Registriert seit
    06.04.2013
    Beiträge
    168
    Total Downloaded
    5,92 MB
    Total Downloaded
    5,92 MB
    ReceiverDankeAktivitäten
    Box 1:
    Xtrend ET-10000
     
     
    Box 2:
    Gigablue Quad
     
     
    Box 3:
    Edison Optimuss OS2+
     
     
    Box 4:
    Octagon SF4008
     
     
    Also mit aktuellen Image von OpenMips funktioniert Image-Backup mit Softwaremanager. Bringt zwar Bad Block Fehler aber Backup wird bis zum Ende ausgeführt und kann auch wiederhergestellt werden. Theoretisch, wenn das evtl. nicht die feine Lösung ist, wäre das auch mit openATV möglich?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Fullbackup geht nicht mehr?-p1070773.jpg   Fullbackup geht nicht mehr?-p1070774.jpg  

    Fullbackup geht nicht mehr?-p1070777.jpg   Fullbackup geht nicht mehr?-p1070770.jpg  

    Geändert von trunax (26.01.2014 um 11:42 Uhr)

  5. #35
    Avatar von koivo
    Registriert seit
    06.04.2013
    Ort
    Malediven
    Beiträge
    133
    Total Downloaded
    11,47 MB
    Total Downloaded
    11,47 MB
    ReceiverDankeAktivitäten
    Box 1:
    Mut@nt HD51 mit openHDF 6.2
     
     
    Box 2:
    DM900 mit openHDF 6.2
     
     
    Box 3:
    SF4008 mit openHDF 6.2
     
     
    Jetzt wartet doch ab. Das wird alles kommen.

  6. #36
    Mitglied
    Registriert seit
    18.01.2014
    Beiträge
    51
    Total Downloaded
    0
    Total Downloaded
    0
    ReceiverDankeAktivitäten
    Box 1:
    Gigablue HD Quad
     
     
    Box 2:
    Edision Optimuss OS1
     
     

  7. #37
    Mitglied
    Registriert seit
    26.12.2013
    Beiträge
    57
    Total Downloaded
    45,11 MB
    Total Downloaded
    45,11 MB
    ReceiverDankeAktivitäten
    Der Greenscreen mag gefix sein, trotzdem funktioniert das Backup bei mir nicht. Habe auch einen Bad block im Kernelbereich:
    Code:
    EBI CS1: setting up NAND flash (primary)
    brcmnand.0: heuristics exception detected, Samsung K9F4G08UD
    brcmnand brcmnand.0: 512MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, Ha
    mming ECC
    Bad block table found at page 262080, version 0x01
    Bad block table found at page 262016, version 0x01
    nand_read_bbt: bad block at 0x000003540000
    nand_read_bbt: bad block at 0x00000eb60000
    nand_read_bbt: bad block at 0x00001fbe0000
    Creating 3 MTD partitions on "brcmnand.0":
    0x000000000000-0x00001f800000 : "rootfs"
    0x000000000000-0x00001f800000 : "rootfs(redundant)"
    0x00001f800000-0x00001fc00000 : "kernel"
    Man kann nun natürlich versuchen mit sowas wie "nanddump -a --bb=dumpbad -f vmlinux.gz /dev/mtd2" die bad blocks zu überspringen, aber es kommt dann zumindest ein anderer Kernel raus als der den man ursprünglich geflashed hat. Ich habe hier um genau zu sein 3 Quads insgesamt und kanns daher auch mit einer testen welche keine BadBlocks im Kernelbereich hat. Wenn man die Dumps vergleicht (mit dem genannten dumpbad), so ist der Unterschied tatsächlich gar nicht groß. Es ist dann so, dass bei der defekten Quad ein Stück von 8192 Bytes zwischen Position 003e0000 und 003e2000 mit Hex00 gefüllt ist. Vergleicht man das mit dem ursprünglichen Kernel ist das wohl genau das Ende des Kernels. Danach kommen dann FFs. Komisch ist das schon etwas, denn die Blockgröße ist ja eigtl. 128KB und wenn der Block ungenutzt wäre/komplett defekt, dann dürften innerhalb der 128KB nur dieselben Daten stehen und nicht 00en und FFen gemischt.
    Die Box hat ja eigtl. mit 512MB Flash mehr als genug Reserven und sollte bad blocks doch einfach markieren und nicht mehr verwenden? Ich frag mich irgendwie auch wie der Kernel dann fehlerfrei geladen werden kann, denn er wird ja offenbar auch im gzip-Format ins Flash geschrieben und eigtl. müsste der dann ja beim Entpacken auf Fehler laufen (Gzip ist nunmal Gzip und das mag einfach keine fehlenden Daten) und sofort ne KernelPanic bringen. Es könnte natürlich auch sein, dass das nanddump-Utility die BadBlocks nicht korrekt handhabt und an der falschen Stelle sucht (also den ursprünglichen kaputten Block dumpt anstatt den tatsächlich verwendeten Reserveblock) bzw. der Kernel die Blocks falsch unter /dev/mtd2 bereitstellt.
    Geändert von Chuscha (07.02.2014 um 05:46 Uhr)


Seite 4 von 4 ErsteErste ... 234

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Diese Website benutzt Cookies
Wir benutzen Cookies um Sitzungsinformationen zu speichern. Dies erleichtert es uns z.B. Dich an Deine Login zu erinnern, Einstellungen der Webseite zu speichern, Inhalte und Werbung zu personalisieren, Social Media Funktionen anzubieten und unser Datenaufkommen zu analysieren. Wir teilen diese Informationen ebenfalls mit unseren Social Media-, Werbe- und Analysepartnern.
     
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:02 Uhr.
Powered by vBulletin® Version 4.2.5 (Deutsch)
Copyright ©2017 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.
Resources saved on this page: MySQL 11,11%
Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)
vBulletin Skin By: PurevB.com