Interner Speicher verschwunden 6490 7.0

[Flarflar]

Hi habe eine gebrauchte 6490 gekauft 7.0. Leider kann ich den internen Speicher im NAS nicht aktivieren. Steht auf deaktiviert und der Haken vorne ist ausgegraut. Anlage eines neuen NAS Benutzers bringt nichts. In der Übersicht steht speicher NAS 0 genutzt und 0 frei. Danke für die Hilfe

 

[stoney]

Verrate uns zuerst um welche Artikelnummer (2000 xxxx) es sich handelt.

Zudem wäre der erste Abschnitt der Suppordaten interessant (einmalige Werte wie MAC Adresse usw. anonymisieren)

Die Werkseinstellungen wurden bereits geladen?

Screenshot helfen auch oft ungemein.

 

[Flarflar]

Eine 2000 2691 . Merkwürdig ist auch, dass beim Einstecken des Netzsteckers die rote Lampe nicht kurz aufleuchtet. Bereits zurückgesetzt , brachte nichts. Datei anbei

 

[Flarflar]

Noch ergänzend . USB Stick wird erkannt . Anrufbeantworter verlangt nach einem USB Stick. Es sieht für mich ,als Laie so aus, als hätte man den internen Speicher herausoperiert, falls das überhaupt möglich ist.

 

[Shirocco88]

Die "fritznasdb" kann nicht initialisiert werden:
ERROR: db init failed second time - codes: 8, 10

Auszug support FRITZ.Box 6490 Cable 141.07.00_01.01.00_0103.txt:

rootfs / rootfs rw 0 0
/dev/root / squashfs ro,relatime 0 0
proc /proc proc rw,relatime 0 0
tmpfs /var tmpfs rw,relatime 0 0
tmpfs /dev tmpfs rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
no-scratch /var/remote tmpfs rw,relatime 0 0
usbfs /proc/bus/usb usbfs rw,relatime 0 0
tmpfs /usr/www/avm/dvb/m3u tmpfs rw,relatime 0 0
##### END SECTION mounts
##### BEGIN SECTION avmdb Log avmdb
avmdb-Log
------
2000-01-01 01:02:27.894 - lavmdb ERR: [avmdb_init_client:668]: luascaninfo: maindb not found (8), media_dir: /var/media/ftp
2000-01-01 01:02:27.894 - luascaninfo: starting fnasdb (1)
2000-01-01 01:02:28.516 - fnasdb: [main:634]: fnasdb started (w/o_indexation: 1, autoindex: 0
2000-01-01 01:02:28.533 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:28.547 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:29.590 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:29.590 - fnasdb ERR: [main:671]: init failed, trying again (9,10), mediadir: /var/media/ftp
2000-01-01 01:02:29.590 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:29.590 - fnasdb ERR: [main:675]: init failed again (9,10)
2000-01-01 01:02:29.592 - fnasdb: [main:886]: fnasdb finished
2000-01-01 01:02:34.311 - lavmdb ERR: [avmdb_init_client:668]: luascaninfo: maindb not found (8), media_dir: /var/media/ftp
2000-01-01 01:02:34.311 - luascaninfo: starting fnasdb (1)
2000-01-01 01:02:34.855 - fnasdb: [main:634]: fnasdb started (w/o_indexation: 1, autoindex: 0
2000-01-01 01:02:34.870 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:34.880 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:35.899 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:35.899 - fnasdb ERR: [main:671]: init failed, trying again (9,10), mediadir: /var/media/ftp
2000-01-01 01:02:35.899 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:35.899 - fnasdb ERR: [main:675]: init failed again (9,10)
2000-01-01 01:02:35.901 - fnasdb: [main:886]: fnasdb finished
2000-01-01 01:02:37.473 - lavmdb ERR: [avmdb_init_client:668]: luascaninfo: maindb not found (8), media_dir: /var/media/ftp
2000-01-01 01:02:37.473 - luascaninfo: starting fnasdb (1)
2000-01-01 01:02:37.926 - fnasdb: [main:634]: fnasdb started (w/o_indexation: 1, autoindex: 0
2000-01-01 01:02:37.948 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:37.958 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:38.979 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:38.980 - fnasdb ERR: [main:671]: init failed, trying again (9,10), mediadir: /var/media/ftp
2000-01-01 01:02:38.980 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:38.980 - fnasdb ERR: [main:675]: init failed again (9,10)
2000-01-01 01:02:38.981 - fnasdb: [main:886]: fnasdb finished
2000-01-01 01:02:47.077 - lavmdb ERR: [avmdb_init_client:668]: luascaninfo: maindb not found (8), media_dir: /var/media/ftp
2000-01-01 01:02:47.077 - luascaninfo: starting fnasdb (1)
2000-01-01 01:02:47.590 - fnasdb: [main:634]: fnasdb started (w/o_indexation: 1, autoindex: 0
2000-01-01 01:02:47.607 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:47.616 - lavmdb: [avmdb_are_files_in_rootdir_supported:534]: avmdb_are_files_in_rootdir_supported: always return 1
2000-01-01 01:02:48.641 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:48.641 - fnasdb ERR: [main:671]: init failed, trying again (9,10), mediadir: /var/media/ftp
2000-01-01 01:02:48.641 - lavmdb ERR: [avmdb_init_server:213]: fnasdb: open mediadir failed: /var/media/ftp
2000-01-01 01:02:48.641 - fnasdb ERR: [main:675]: init failed again (9,10)
2000-01-01 01:02:48.642 - fnasdb: [main:886]: fnasdb finished
##### END SECTION avmdb
##### BEGIN SECTION nas_db Fritznasdb
database not available (codes 8, 10), starting fritznasdb...
fritznasdb started
ERROR: db init failed second time - codes: 8, 10
##### END SECTION nas_db



[    0.783164] [puma6_partition_add] New device: mmcblk0p9
[    0.783311] [puma6_partition_add] UUID: 781d0c3a-9d6d-4052-8e2c-617afda38fe1
[    0.783523] [puma6_blockdev_add] blockdev: /dev/mmcblk0p9 logical: media



<3>[    0.787362] [puma6_partition_add] New device: mmcblk0p9
<3>[    0.787511] [puma6_partition_add] UUID: 781d0c3a-9d6d-4052-8e2c-617afda38fe1
<3>[    0.787723] [puma6_blockdev_add] blockdev: /dev/mmcblk0p9 logical: media


<7>[    1.780000] PM: Adding info for No Bus:mmcblk0p9
<3>[    1.780000] [puma6_partition_add] New device: mmcblk0p9
<3>[    1.780000] [puma6_partition_add] UUID: 781d0c3a-9d6d-4052-8e2c-617afda38fe1
<3>[    1.780000] [puma6_blockdev_add] blockdev: /dev/mmcblk0p9 logical: media

 

[Flarflar]

Weil kein interner Speicher zur Verfügung steht ? Wo ist er nur hin ? Danke für eure Mühe.

 

[PeterPawn]

Der Speicher ist durchaus noch da:

[    0.783164] [puma6_partition_add] New device: mmcblk0p9
[    0.783311] [puma6_partition_add] UUID: 781d0c3a-9d6d-4052-8e2c-617afda38fe1
[    0.783523] [puma6_blockdev_add] blockdev: /dev/mmcblk0p9 logical: media

, nur ist offenbar das Dateisystem darin im Eimer:

[   13.724299] [1]EXT4-fs (mmcblk0p9): VFS: Can't find ext4 filesystem
[   13.749307] [1]EXT4-fs (mmcblk0p9): VFS: Can't find ext4 filesystem

und ohne passende Rahmenbedingungen wird das auch nicht neu formatiert:

if [ -n "${mtd_nand}" ] && [ -n "${Recover_was_here}" ] ; then
## erase (formatting) due to preceding recover
nand_erasestring="mkfs -t ext4 ${mtd_nand}"
echo "[ext4/Recover] Internal Memory erasing with cmd: ${nand_erasestring}"
if ${nand_erasestring} ; then
echo "[ext4/Recover] Internal Memory erasing done"
else
echo "[ext4/Recover] Internal Memory erasing failed"
fi
fi

Bei einer Version 07.00 in der Box sollte auch ein "recovered=2" nicht dazu führen, daß ggf. per Download installierte Zertifikate mit gelöscht werden und so würde ich es hier zumindest noch einmal mit dem Zusatz "recovered=2" in "firmware_info" versuchen, was man problemlos über den Bootloader im Environment setzen kann. Zwar wird das theoretisch auch von "setfactorydefaults" verwendet:

## proceed if nvram is present AND DocsisCalDefaults are available
if [ -n "${setf_mtd_nvram}" ] && [ -n "${setf_mountpoint_nvram}" ] && [ -d "${setf_mountpoint_nvram}" ] && [ "${setf_DocsisCalDefaults_found}" = "yes" ]; then
## intentionally kept simple: just detect config-space/nvram) an set the need of 'factorydefault'
## firmware_info setzen (damit wir nach dem reboot das nachholen können) [factorydef: recovered=3]
echo "[$$]+ + + INFO(`uname -m`): nvram erasing scheduled for next bootup" > /dev/console
fw_info=`grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment`
## take care on preventing multiple entrys ',recovered=*'
fw_info=`echo ${fw_info} | sed -e "s/,recovered=[0-9]\+//g"`
echo "$fw_info,recovered=3" >$CONFIG_ENVIRONMENT_PATH/environment
fi

und das soll ja bereits versucht worden sein, aber vielleicht wurden oben ja auch die Standard-Kalibrierungsdaten nicht gefunden und deshalb gar kein "recovered" gesetzt.

EDIT: Ach so ... man braucht dann auch wieder die Support-Daten von dem Start mit "recovered=2" - weil eventuelle Fehler beim Formatieren dann nur darin auftauchen werden (in der "dmesg"-Ausgabe ziemlich am Ende).

 

[Flarflar]

Das heisst? Was muss ich machen? Vielen Dank im voraus. Neuinstallieren mit 7.0 hat auch nicht geändert. Muss ich irgendwelche Befehle über adam2 eingeben?

 

[stoney]

Muss ich irgendwelche Befehle über adam2 eingeben?

Ja

 quote SETENV firmware_info 141.07.00,recovered=2

//edit geändert nach Hinweis von @PeterPawn für die Korrektur des Flüchtigkeitsfehlers

 

[PeterPawn]

Komma, kein Semikolon.

 

[Flarflar]

Werde ich heute Abend testen. Bin richtig gespannt. Den setfactorydefaults hatte ich im Fritz Menue auf Werkseinstellungen zurücksetzen gemacht. War das so ok?

 

[Flarflar]

hat leider nichts gebracht. Kann ich wohl die Box trotzdem bei UM anmelden? Komisch ist ja auch, dass die rote Info Lampe beim flashen nicht blinkt. Scheinbar jede Menge durcheinander in der Box

 

[Flarflar]

... ich habe mir gerade die Platine angeschaut. Die rote Diode ist abgerissen. Das ist mir aber egal. Der Fehler im internen Speicher finde

 

[PeterPawn]

Shell-Zugang einbauen, "mkfs" von Hand aufrufen und schauen, was das Problem sein soll. Wenn es nur irgendwelche kaputten Blöcke sind, kann man mit einer Änderung der GPT und einer "Verschiebung" der Partition ja vielleicht doch noch etwas machen ... auf alle Fälle würde ich hier aber ohne Shell nicht mehr weitermachen.

Das fehlende "Recover_was_here" auf dem ATOM-Core ist offenbar normal, weil das Environment für den CGI-Aufruf etwas ausgedünnt wird ... jedenfalls sieht man das "Recover_was_here=2" auf dem ARM-Core ja deutlich (da ist es ein "normales" Shell-Environment) und damit ist auch "verbrieft", daß es beim Start gesetzt war. Leider kann man in der Kernel-Ausgabe nicht sehen, wann das "mkfs" aufgerufen wird und welche Probleme es hat - man kommt also um den Shell-Zugriff (zum manuellen Start des "mkfs") oder die serielle Console (zur Beobachtung der AVM-Aktionen) nicht herum, wobei AVM bei der 07.00 ja wieder auf "stumm" geschaltet hat. Vielleicht eignet sich daher auch die 06.87 besser für weitere Versuche, wenn man die serielle Schnittstelle benutzen will/kann.

 

[Flarflar]

Jetzt wird es richtig krank. Ich habe auf 6.87 gefasht. Habe scheinbar etwas falsch gemacht Boot und dann alle Lampen aus. Egal noch einmal 7.0 drauf uns siehe da der Speicher ist wieder da. Aber zu früh gefreut . Neues Problem . Nach ca. 15 Sek verliert die Box die Verbindung zur Weboberfläche. Grrrr. Schnell die Werkseinstellungen aufgerufen. Aber das Problem bleibt. Windows und Linux das gleiche Problem.

 

[jebeyer]

Eine 2000 2691

Also keine Einzelhandels-Version (2000 2778), sondern eine von VF/KD

 

[elo22]

Also keine Einzelhandels-Version (2000 2778), sondern eine von VF/KD

Also Hehlerware.
Duck und wech

Luzz

 

[Flarflar]

Das Teil hatte wahrscheinlich einen Hardwarefehler und ruht bereits im Fritzhimmel auf der Deponie. :-(

 

[PeterPawn]

Also Hehlerware.

Die stammte bestimmt eher aus einem Raubmord, bei dem das Opfer zuvor noch vergewaltigt wurde. Was liegt nach so einem Verbrechen näher, als die 6490 aus der Wohnung des Opfers mitzunehmen, um damit auch noch Raubkopien anbieten zu können?

Das Teil hatte wahrscheinlich einen Hardwarefehler und ruht bereits im Fritzhimmel auf der Deponie.

Schlimmer Fehler ... 15-20 EUR hätte ich dafür (bei den beschriebenen Symptomen) glatt noch gezahlt. Solange der Bootloader so einer Box nicht auch noch defekt ist, kann man die fast immer wieder zum Leben erwecken und auch die Netzteile der 6490 sind nicht ganz "unbegehrt", weil sie - im Gegensatz zu vielen anderen - die Stifte so angeordnet haben, daß man damit in einer "geraden" Steckerleiste tatsächlich nur einen Steckplatz blockiert:

 

[Flarflar]

.. da stellt sich für mich jetzt Frage. Ist es eigentlich legal diese ehemaligen Providerboxen zu kaufen bzw. zu verkaufen. Gibt es hierzu verlässliche Aussagen?