Thema: Fullbackup geht nicht mehr?

Zitat von HD8000S

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

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?

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.